Um artigo publicado em 19 de abril de 2026 por Davi Ottenheimer afirma que o uso de gateways para agentes locais de inteligência artificial pode representar um retrocesso em segurança, ao comparar esse modelo à arquitetura permissiva do MS-DOS. De acordo com informações do Flying Penguin, o autor analisa o tutorial da NVIDIA para configurar o OpenClaw e o NemoClaw em ambiente local e contrapõe essa proposta à arquitetura do projeto Wirken, desenvolvido por ele.
O texto parte de uma crítica histórica ao MS-DOS, descrito como um sistema em que programas podiam acessar o kernel, interceptar interrupções e gravar em disco sem barreiras efetivas. Para o autor, a popularidade desse modelo não eliminava seus riscos. A partir dessa lembrança, ele sustenta que alguns gateways de agentes de IA estariam repetindo uma lógica semelhante ao concentrar permissões amplas em um único processo e em um único token de acesso.
Por que o autor compara OpenClaw e gateways de IA ao MS-DOS?
A comparação é usada para argumentar que mecanismos de contenção aplicados ao redor de todo o agente podem não resolver o problema de base. Segundo o artigo, o desafio seria proteger sistemas que, na prática, dependem de permissões amplas para funcionar. Nesse raciocínio, o autor diz que não basta criar um invólucro ou uma camada externa de proteção, mas sim adotar uma arquitetura com separações menores e mais rígidas entre processos, identidades e ferramentas.
Na avaliação apresentada, gateways de agentes podem “entregar” ao modelo ferramentas de execução de comandos e operar com um único token, o que concentraria risco operacional. O texto afirma que a NVIDIA percebeu esse cenário e publicou um tutorial considerado cuidadoso para implantar um agente auto-hospedado no DGX Spark, com controle sobre o ambiente de execução e integração com o Telegram.
O que o tutorial da NVIDIA propõe?
O artigo resume várias etapas do tutorial analisado. Entre elas, estão a configuração do runtime de contêineres, a alteração do endereço de escuta do Ollama para 0.0.0.0, o emparelhamento do bot do Telegram com envio de código pelo chat e a aprovação de conexões de saída bloqueadas por meio de uma interface de texto no host. Para o autor, essas etapas tentam resolver problemas reais de segurança, mas decorrem de uma arquitetura em que o sandbox envolve o agente inteiro.
Na descrição do texto, o OpenClaw e o NemoClaw seguem um fluxo em que a política de rede é aplicada no limite do namespace de rede, enquanto a interface web exige mecanismos adicionais de acesso remoto, como encaminhamento de porta no host e túnel SSH. O autor vê esse arranjo como mais complexo porque a interface do agente fica encapsulada em um ambiente isolado.
Como o autor diz que a arquitetura do Wirken difere dessa abordagem?
Ao comparar as duas propostas, Ottenheimer afirma que o Wirken reduz fronteiras em vez de cercar todo o agente com uma única camada de contenção. Segundo ele, cada canal opera em processo separado, com identidade própria em Ed25519, enquanto o cofre de segredos roda fora do processo principal. A inferência permaneceria em loopback, e a execução de shell ocorreria dentro de um contêiner endurecido configurado no nível da ferramenta.
O texto também detalha que 16 prefixos de comandos considerados de alto risco exigem aprovação em todas as execuções, enquanto outros são autorizados no primeiro uso e permanecem memorizados por 30 dias. Na comparação apresentada pelo autor, isso desloca a aplicação de política para a camada de despacho da ferramenta, em vez de depender apenas do isolamento de rede do agente como um todo.
- Ollama mantido em 127.0.0.1 no caso do Wirken
- Execução de shell em contêiner com restrições reforçadas
- Comandos de maior risco sujeitos a aprovação recorrente
- Registro de auditoria encadeado por hash na sessão de webchat
Quais evidências o artigo apresenta para sustentar essa crítica?
Na parte final, o autor reproduz trechos de logs de auditoria do Wirken 0.7.5 para mostrar como permissões negadas e execuções autorizadas ficam registradas. Um exemplo citado é a negativa a um comando curl, classificado como ação de nível alto, antes mesmo de chegar ao sandbox. Outro exemplo mostra a execução de um comando sh em ambiente endurecido, com resposta do kernel indicando sistema de arquivos somente leitura em tentativa de gravação fora da área permitida.
Read-only file system
Para o autor, esse tipo de evidência indicaria que as garantias arquiteturais podem ser verificadas por registros de auditoria encadeados. O artigo, porém, é uma análise opinativa e comparativa do próprio desenvolvedor sobre seu projeto e sobre o tutorial da NVIDIA. Não há, no texto original, testes independentes, validação externa ou dados adicionais que confirmem superioridade objetiva de uma abordagem sobre a outra.
