Todo tutorial de OpenClaw e n8n que li chega à mesma instrução: aponte um nó HTTP Request para http://127.0.0.1:18789 e pronto. O problema é que o endereço não é uma API.
É um agente segurando um shell em qualquer máquina que ele esteja rodando.
Uma integração NemoClaw n8n roda em ambas as direções e mantém as duas dentro do sandbox. n8n chama o gateway OpenClaw através de loopback quando uma etapa precisa de julgamento; OpenClaw chama um webhook n8n quando precisa de execução multi-etapa determinística, e o runtime OpenShell da NVIDIA fica por baixo, decidindo qual dessas chamadas é permitido deixar a caixa.
A fiação é quase idêntica à versão simples.
O que uma integração NemoClaw n8n realmente é
NemoClaw é um sandbox Docker com um mecanismo de política e um proxy de inferência, envolvido em uma instalação OpenClaw padrão. De acordo com a documentação NemoClaw da NVIDIA, o instalador é um único comando:
curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash
Isso inicia o instalador da última versão conhecida e um assistente de integração. O assistente pergunta qual runtime de agente você quer (OpenClaw é o padrão), qual provedor de inferência rotear, se deseja configurar um canal de mensagens, e qual tier de política aplicar. Essas respostas decidem a maioria do que vem depois.
Dentro do sandbox, o agente tem acesso leitura-escrita a /sandbox, /tmp, /dev/null, e /dev/pts. Tudo mais que precisa é montado somente leitura, incluindo /usr, /lib, /etc, e /var/log. A aplicação usa Landlock, o Módulo de Segurança Linux, em base de melhor esforço, então você quer um kernel 5.13 ou mais novo para que se aplique. Ubuntu 22.04 e posterior qualificam.
Nada disso é novo, exatamente. É o mesmo princípio que usei na GreenHat Webs quando montei o pipeline de deployment: desenvolvedores tinham acesso total a dev, acesso limitado a staging, e nenhum acesso a produção. Erros de deployment caíram pela metade, e não porque alguém ficou mais cuidadoso. O caminho que poderia causar danos deixou de ser alcançável por acidente.
Direção um: n8n chama o agente em sandbox
n8n alcança o agente da mesma forma que sempre fez, através de loopback, porque NemoClaw vincula o gateway a 127.0.0.1 por padrão. A configuração relevante é NEMOCLAW_GATEWAY_BIND_ADDRESS=127.0.0.1, e a documentação é inequívoca sobre deixá-la lá.
Se n8n roda no mesmo host, é simples. Adicione um nó HTTP Request, aponte para o gateway na porta 18789, e armazene o token do gateway como uma credencial Header Auth no n8n em vez de colá-lo no nó. Use esta direção para os passos que precisam de um modelo para decidir algo: classificar um email de suporte de entrada, julgar se uma descrição de produto se desviou da marca, decidir se um pedido de reembolso é genuíno, resumir uma thread de ticket em uma disposição de uma linha.
Se n8n roda em outro lugar, resista à solução óbvia. Religar o gateway a 0.0.0.0 é como você termina como uma das instâncias expostas que aparecem em varreduras internet-wide. Use um encaminhamento SSH local em vez disso:
ssh -N -L 18789:127.0.0.1:18789 user@agent-host
Há uma segunda pegadinha que vale a pena conhecer antes de passar uma tarde nela. O auxiliar de auto-pair do NemoClaw apenas aprova dispositivos cujo ID do cliente é cli, openclaw-cli, ou openclaw-control-ui. n8n não é nenhum desses, então autentica-se com o token do gateway em vez de parear como um novo dispositivo. Qualquer outra coisa é rejeitada e registrada. Separadamente, o escopo operator.admin nunca é aprovado automaticamente, o que significa uma ação de agente como criar um trabalho cron para e aguarda você executar openclaw devices approve <requestId> manualmente.
Direção dois: OpenClaw chama um webhook n8n
Esta é a direção que quebra na primeira execução, e quebra por design. NemoClaw aplica uma política de rede deny-by-default, então o sandbox pode apenas alcançar endpoints que são explicitamente permitidos. A política baseline vem com cinco grupos de endpoint: API de inferência da NVIDIA, ClawHub, API do OpenClaw, docs do OpenClaw, e o registro npm.
Sua instância n8n não está nessa lista. Nem GitHub, o que surpreende as pessoas.
Quando o agente tenta fazer POST para seu webhook, OpenShell bloqueia a conexão e registra a tentativa. Você o vê na TUI:
openshell term
De lá você pode aprovar a solicitação para a sessão em execução. Para torná-la permanente, adicione o endpoint à política ativa:
openshell policy update <sandbox-name> \
--add-endpoint n8n.example.com:443:read-write:rest:enforce
O campo de modo de acesso controla se o sandbox obtém GET apenas ou GET mais os métodos de escrita. Um gatilho de webhook precisa dos métodos de escrita. Para revisar o que você realmente concedeu, exporte a política atual e leia-a:
nemoclaw <sandbox-name> policy get > current-policy.yaml
Para uma mudança permanente que sobreviva a uma reconstrução, edite nemoclaw-blueprint/policies/openclaw-sandbox.yaml e execute nemoclaw onboard novamente. Edições ativas feitas com openshell policy set bruto não são reexecutadas quando o sandbox é recriado, o que é uma forma perfeita de perder uma configuração funcional e não entender por quê.
Use esta direção para tudo que o agente não deve estar improvisando: atualizar um registro de CRM, postar no Slack, criar um evento de calendário, escrever uma linha em uma planilha. O agente decide que algo deve acontecer. n8n decide como. Esta é a mesma divisão que uso no pipeline SEO n8n, onde o modelo propõe e o workflow executa, e é a razão pela qual esse pipeline não precisou de rollback.
O tier Personal desfaz o ponto inteiro
O assistente de integração do NemoClaw oferece quatro tiers de política, e um deles silenciosamente o retornará para aonde você começou.
Restricted começa a partir da baseline e não adiciona nada. Balanced, o padrão, adiciona ferramentas de desenvolvimento e um provedor de busca web. Open adiciona plataformas de mensagens e APIs de produtividade. Personal aplica um preset chamado personal-open-internet, que permite que todo binário no sandbox abra conexões TCP para qualquer host alcançável nas portas 80 e 443.
Leia a descrição da própria NVIDIA desse tier cuidadosamente. A regra não inspeciona o hostname, método, path, ou body. Não há prompt de aprovação do operador, porque a conexão já foi permitida. A documentação afirma claramente que um agente neste tier pode enviar dados de workspace ou credenciais visíveis ao sandbox para um serviço arbitrário alcançável em qualquer uma das portas.
Loopback e ranges link-local permanecem bloqueados, a faixa comum de metadata de nuvem com eles, e os controles de filesystem permanecem ativos. Essa proteção é real, e fica bem aquém do que um sistema comercial precisa. Se você está conectando um agente a dados de cliente live, execute Restricted ou Balanced e adicione endpoints deliberadamente.
Personal é um tier para um laptop.
Acertar essa decisão de tier é a maior parte do trabalho. Normalmente é aonde a consultoria de automação n8n começa: com a lista de coisas que um workflow tem permissão de tocar, escrita antes de alguém abrir o canvas.
O que o sandbox para, e o que não faz
Confinamento resolve o problema do host. O agente não pode reescrever seus binários de sistema, não pode modificar /etc para redirecionar DNS ou trocar o armazenamento de confiança TLS, não pode persistir fora de /sandbox e /tmp, e não pode alcançar um serviço que você nunca permitiu. NemoClaw também roda um scanner de secret de memória que intercepta escritas de chaves de API e tokens na memória persistente antes deles baterem disco, e a CLI redige padrões de credenciais da saída.
O que não resolve é a permissão que você concedeu propositalmente.
Se você adiciona o endpoint REST da sua loja à política com acesso de escrita para que o agente possa atualizar inventário, o agente também pode deletar produtos. O sandbox continha o raio de explosão ao redor do seu sistema operacional. Não fez nada sobre o raio de explosão dentro da sua allowlist. Essa distinção é a lição inteira de o que acontece quando um agente de IA tem as credenciais de produção, e nenhum runtime remove a necessidade de uma porta de aprovação humana na frente de ações irreversíveis.
Então como você deveria dividir o trabalho?
Quatro regras que se mantiveram:
- Uma etapa de julgamento dentro de um fluxo determinístico pertence a n8n, chamando o gateway através de loopback para aquele nó.
- Execução determinística multi-etapa pertence a um webhook n8n que o agente dispara, nunca nas chamadas de ferramenta do agente.
- Tier Restricted ou Balanced para qualquer coisa tocando sistemas de negócio, com endpoints adicionados um por vez.
- Todo endpoint na política é uma permissão com seu nome nela. Revise o YAML exportado como reveria um pull request.
Se você ainda está decidindo se este trabalho precisa de um agente, a comparação entre n8n, OpenClaw, e agentes Claude tem a árvore de decisão completa, incluindo o custo por execução.
Então, quando seu agente faz algo caro às três da manhã, quem aprovou o endpoint que usou?
Se você está fiando um agente em sistemas que seguram dados de cliente reais e quer o modelo de permissão revisado antes do primeiro webhook ir live, esse é exatamente o tipo de trabalho que faço. Comece com consultoria de automação n8n, ou me diga o que você está construindo.