ENPT
Agendar demonstração

Insights · Segurança

Segurança em agentes de IA para código: o limite fica fora do agente, e cada decisão deixa rastro

Publicado em

Um agente de código lê arquivos, roda comandos e chama ferramentas por conta própria. Na nossa leitura, o limite que vale é o que o agente não consegue desligar, e cada decisão de permitir ou negar deixa rastro. É isso que torna a operação auditável e melhorável.

As referências, de setembro de 2026, são textos da NVIDIA sobre o próprio produto e um artigo de opinião no blog da Thoughtworks: fonte de desenho, não recomendação de produto. Citações em tradução nossa.

O limite fica fora do processo do agente

Em 28 de setembro de 2026, a NVIDIA anunciou a disponibilidade ampla do OpenShell, um runtime de código aberto para agentes de IA. Segundo o comunicado, as empresas precisam de "um limite que possa ser imposto fora do modelo e do harness do agente" (ali, harness é o software do agente).

A página do OpenShell resume a regra. "Nada é permitido por padrão." A aplicação da política "acontece fora do processo do agente, onde não pode ser desligada por prompt nem contornada". E "cada liberação e cada negação é auditável".

O blog técnico da NVIDIA, na mesma data, detalha o pedido bloqueado: a negação fica registrada para revisão de um operador ou de um agente aprovador. Com o recurso de propostas ligado, o agente pode pedir uma regra nova, de escopo estreito; a proposta fica pendente de revisão humana por padrão, e o agente não pode aprovar o próprio pedido.

Na nossa leitura, a regra vale além do produto: limite que mora só no prompt depende de o agente cooperar; limite aplicado de fora, não.

Guias, sensores e portões humanos

Em 29 de setembro de 2026, um artigo no blog da Thoughtworks, assinado por Jaya Simha Reddy Nandyala e Prabina Pani (o blog avisa que é opinião dos autores), descreveu um padrão para agentes de código com duas camadas de controle, separadas por portões humanos seletivos:

  • Guias, antes da ação. Restringem e orientam o agente antes que ele aja, por exemplo com ferramentas de menor privilégio (um agente de verificação que só lê). Pedir no prompt que o agente não faça o que não está autorizado é, nas palavras dos autores, "inerentemente frágil".
  • Sensores, depois da ação. Testes unitários, linters, checagem de tipos e regras de arquitetura conferem o que o agente produziu, em vez da autoavaliação dele.
  • Portões humanos seletivos, entre as duas. Uma pessoa confirma só onde o estrago possível é grande ou a decisão é irreversível: escopo em vários repositórios, migração de schema, mudança em API pública.

Segundo os autores, o desenho evita dois erros: o agente solto e a fadiga de revisão de quem precisa aprovar cada chamada trivial de ferramenta. Para a Ithaca, aprovar cada chamada repete o problema da aprovação que vira carimbo (só aprove o que você sabe explicar): quem aprova tudo deixa de ler o que aprova. Na execução, o portão humano só protege se for raro o bastante para ser lido; a leitura do código que entra em produção é outra etapa e continua.

O que entra na trilha

Uma trilha de sessão útil guarda pedido, passos, modelo, custo, resultado e autoria (o que registrar em cada sessão). Com limites aplicados de fora, vale somar dois itens: o que o agente pediu além do permitido e o que foi negado.

Na nossa leitura, um pedido negado de novo e de novo pode indicar um limite apertado demais ou um agente saindo do escopo; nos dois casos, quem decide é uma pessoa do time.

Checklist para o CTO

Antes de dar mais autonomia aos agentes de código:

  • O que o agente pode ler e mudar sem pedir, e o que exige uma pessoa antes?
  • O limite é aplicado no prompt ou fora do agente?
  • Onde ficam registradas as decisões de permitir e negar, e quem as lê?
  • O agente consegue aprovar o próprio pedido de permissão? A resposta precisa ser não.
  • Quem revê a política, e quando?

Onde a Ithaca entra

A Ithaca opera uma plataforma de desenvolvimento agentic no nível 4 de autonomia: agentes de código executam, e pessoas do time leem o que entra em produção. Como descrevemos em harness engineering, o time define o que os agentes fazem sem aprovação prévia e o que exige aprovação humana antes de executar, e cada sessão fica registrada. Supervisão humana e rastreabilidade são a regra. O desenho das seções acima vem das fontes citadas; não é a ficha técnica da plataforma.

Isso não é risco zero. Como diz a página de harness engineering, uma falha continua possível; o que muda é o tamanho do estrago e a facilidade de achar a causa na sessão.

Quer agentes de código com limites definidos pelo seu time e cada sessão registrada? Agendar demonstração

Perguntas frequentes

Guardrail e sandbox são a mesma coisa?

Não. Guardrail (ai agent guardrails, em inglês) é qualquer limite posto ao agente, do prompt a uma política aplicada de fora. Sandbox (coding agent sandbox) é um desses limites: segundo a página do OpenShell, isola um processo numa tarefa delimitada, enquanto agentes autônomos precisam de governança ao longo do tempo, com credenciais, política e registro.

Limites aplicados fora do agente substituem a revisão de código?

Não. Eles controlam o que o agente pode fazer enquanto trabalha; a revisão confere o que ele produziu. Na plataforma da Ithaca, código que entra em produção passa por leitura humana.

E a rede e o firewall da empresa?

Continuam valendo. Segundo a página do OpenShell, ele não substitui as ferramentas de identidade, observabilidade e segurança da empresa; nele, cada agente roda num sandbox sem acesso direto à rede, e um supervisor confere cada pedido de rede contra a política. A plataforma da Ithaca, por sua vez, é implantada no ambiente da empresa, em conta de nuvem controlada por ela ou em data center.

Leia também

Fontes

Agendar demonstração

Comece pelo que está travado.

O projeto novo parado no backlog ou o sistema antigo que virou um fardo. A demonstração mostra os agentes trabalhando do pedido ao deploy, e a implantação começa pela parte que seu time escolher.

Veja a plataforma funcionando

Só isso. Sem cadastro, sem newsletter.

Como usamos seus dados: Política de privacidade.