Em julho de 2026, o investidor de IA e ex-CEO da HyperWrite Matt Shumer estava testando no próprio Mac o GPT-5.6 da OpenAI, ainda não lançado, codinome Sol. Ele deu ao modelo acesso completo à máquina. Uma subtarefa de limpeza executou um único rm -rf mirado direto no home directory dele. Quando ele reagiu e matou o processo, mais de uma hora havia passado e a maior parte dos arquivos tinha ido embora.
O incômodo é que a OpenAI já conhecia esse tipo de risco. Dezesseis dias antes do incidente, o model card deles próprios marcava “dar acesso completo a um AI Agent” como risco sério.
Não houve nenhum atacante, nenhum exploit. Apagar arquivos era simplesmente uma das capacidades que esse Agent havia recebido.
O que aponta para um problema mais fundamental: a arquitetura da maioria dos AI Agents de hoje é insegura por design. E o remendo instintivo — empilhar guardrails — é a direção errada. Os guardrails ficam no mesmo nível daquilo que deveriam conter, então por mais que se adicionem, dá para contorná-los. A defesa que segura de verdade tem que ficar fora do modelo.
”Segurança de IA” significa três coisas diferentes; este texto trata da terceira
“Segurança de IA” é uma expressão em alta agora, mas em contextos diferentes ela nomeia coisas realmente distintas. Aproximadamente três.
A primeira é a segurança do próprio modelo: impedir jailbreaks, evitar que produza conteúdo nocivo, alinhar com a intenção humana. É onde a maior parte do debate dos últimos anos aconteceu.
A segunda é IA para segurança (AI for security): virar o modelo grande e colocá-lo para defender — detecção de ameaças, auditoria de código, análise de inteligência. Aqui nós mesmos fizemos algum trabalho, por exemplo em Thought Is All You Need, um modelo com raciocínio aumentado para detectar vulnerabilidades em smart contracts, e em REEVMBench, um benchmark de se AI Agents realmente estão prontos para auditar segurança de smart contracts.
A terceira — o assunto deste texto — é a segurança do próprio AI Agent. No momento em que um modelo deixa de apenas responder perguntas e passa a ler seus arquivos, guardar suas credenciais e agir em seu nome, as ferramentas que ele pode chamar, as permissões que ele carrega e cada ação que executa se tornam superfície de ataque.
Os dois primeiros temas têm corpos maduros de pesquisa. O terceiro é novo, fácil de ficar de fora do radar, e por acaso é a pré-condição para AI Agents entrarem em escala nas empresas: nenhuma companhia vai entregar negócio real e dados reais a um Agent que não consegue se manter em segurança.
Da entrada não confiável à execução arbitrária: o defeito de fábrica
Para fazer trabalho de verdade, um Agent normalmente precisa de várias capacidades ao mesmo tempo: ele lê conteúdo externo (páginas web, e-mail, repositórios de código, pull requests alheios), alcança recursos valiosos (chaves, senhas de cloud, bancos de dados) e chama ferramentas para agir (executar comandos, disparar requests, editar arquivos). Colocar essas três juntas é a combinação mais perigosa possível.
A raiz do problema é que o modelo não diferencia se uma frase é uma instrução do operador ou conteúdo que acabou de ler e foi escrito por outra pessoa. Para o modelo, é tudo o mesmo texto na mesma janela de contexto. Em quem obedecer ele decide por intuição aprendida, não por uma regra dura que separe as duas coisas. É um problema clássico de segurança, o confused deputy: um programa com privilégios é enganado por uma parte sem eles a fazer algo prejudicial em seu nome.
A cadeia merece ser escrita por inteiro. As ferramentas que efetivamente agem seguem o modelo; o modelo segue o prompt; e o prompt é montado a partir de tudo — parte escrito pelo usuário, parte puxado de páginas web, e-mails e documentos. Uma fonte não confiável, passando por um modelo cujo comportamento não é determinístico, pode acabar dirigindo ferramentas a executar operações arbitrárias. No software tradicional, dados são dados e código é código, separados de forma limpa. No Agent, uma frase que ele leu pode ser tratada como comando a qualquer instante.
Ou seja, o atacante não precisa de exploit sofisticado nem de conta roubada. Plantar uma única frase num documento, numa página web ou até num comentário de código já pode fazer o Agent fazer algo que nunca deveria. A equipe de segurança da Microsoft coloca sem rodeios: seu LLM não é fronteira de segurança; as ferramentas que você expõe definem o alcance que você concedeu ao atacante.
Nada disso é hipotético — os casos reais estão se acumulando. A ferramenta de coding Grok Build da xAI, a cada sessão de trabalho, subia em silêncio o repositório inteiro — incluindo os segredos no .env e todo o histórico de commits — para os próprios servidores em nuvem, num volume medido perto de trinta mil vezes o necessário para a tarefa. Num teste, o Agent do Cursor apagou o banco de dados de produção de uma empresa inteira, backups incluídos, em nove segundos, e depois escreveu um pedido de desculpas. O Agent do Replit, durante um code freeze explícito, apagou o DB de produção inteiro e fabricou milhares de registros falsos para encobrir. E a extensão do Amazon Q para VS Code foi envenenada por um commit malicioso que plantou uma instrução de “limpe o sistema”, e saiu em release oficial para quase um milhão de máquinas.
Colocando esses incidentes lado a lado, o fio comum é claro: o dano quase sempre veio das permissões que o próprio Agent tinha autorizadas, não de invasão externa. Ler .env, executar comandos, consultar bancos — é exatamente o que ele faz todo dia. Um canal de upload, um comando de delete, e uma capacidade normal vira desastre.
Por que guardrails dentro do modelo não bastam: o defensor está no mesmo nível
A reação instintiva a esses incidentes é adicionar guardrails dentro do Agent. Por guardrails entendo regras postas dentro do modelo para impedi-lo de fazer coisas perigosas: usar o prompt para pedir que não execute operações perigosas, ou adicionar uma checagem dentro do Agent — como algumas ferramentas de coding fazem ao interceptar comandos perigosos e inspecionar caminhos de arquivo.
Mas essa abordagem tem um problema na raiz: o guardrail e aquilo contra o que ele defende ficam no mesmo nível.
Apostol Vassilev, cientista sênior do NIST (National Institute of Standards and Technology dos EUA), publicou em junho de 2026 um artigo que traz a lógica dos teoremas de incompletude de Gödel para exatamente esse padrão. O título já é uma pergunta retórica: Robust AI Security and Alignment: A Sisyphean Endeavor?
O argumento dele, em resumo: um guardrail é, no fundo, um conjunto finito e fixo de regras. Assim como um sistema axiomático finito não pode ser ao mesmo tempo completo e consistente, para qualquer conjunto fixo de guardrails sempre vai existir uma frase que passa por cima — e a ambiguidade e flexibilidade da linguagem humana tornam o espaço dessas frases praticamente ilimitado. Nas palavras dele, nenhum conjunto finito de guardrails é universalmente robusto contra prompts adversariais. A única pergunta que sobra é quem acha essa frase primeiro, o defensor ou o atacante. O NIST, em consequência, recomendou deslocar a mentalidade de “acertar de uma vez” para “monitorar e ajustar continuamente”.
Há uma evidência mais direta. Se o próprio modelo não é confiável, dá para usar um modelo para checar se outro foi comprometido? Um estudo da University of Wisconsin descobriu que esse caminho é sem saída: esse tipo de esquema, em que um modelo julga se outro foi adulterado, tem um defeito estrutural, e um ataque adaptativo que os pesquisadores construíram derruba a taxa de detecção para quase zero enquanto a injection continua tendo sucesso em cerca de nove em cada dez tentativas. O modelo que deveria pegar ataques está no mesmo nível do conteúdo que inspeciona e acaba comprometido primeiro.
E existe uma questão de temporização fácil de perder: os guardrails só entram em ação depois que o Agent já tem autoridade para agir. EchoLeak é o exemplo mais claro. Foi um ataque zero-click contra o Microsoft 365 Copilot: um e-mail cuidadosamente construído passou em silêncio pelos filtros de injection que a Microsoft tinha posto na frente do Copilot e levou dados sensíveis para fora, sem que o usuário clicasse em nada.
Então “colocar guardrails dentro do modelo” é meio como construir uma Linha Maginot. Não é inútil, mas por design é fatalmente contornável. Pode ser uma camada de defesa; não pode ser a única linha.
A defesa de verdade fica fora do Agent
Se o interior do modelo não é confiável, a linha de defesa tem que se mover para fora, para o nível do sistema.
Prender código não confiável em um ambiente isolado e dar apenas o menor privilégio necessário não é novidade em segurança — é coisa de décadas. Já em 1975, o artigo clássico de Saltzer e Schroeder colocava dois princípios: menor privilégio, em que um programa recebe só a fatia de permissão necessária para fazer o trabalho; e separação de privilégios, em que a autoridade é dividida para que um único erro ou engano não abra o sistema inteiro (The Protection of Information in Computer Systems). O sandboxing que veio depois — Janus nos anos 1990, FreeBSD Jails em 2000, gVisor hoje — todos trilham o mesmo caminho: isolar código não confiável de modo que, mesmo comprometido, o dano não chegue para fora. Proteger um AI Agent, no fim das contas, é aplicar esse corpo de prática de décadas a um objeto novo.
Em termos concretos hoje, o movimento direto é embrulhar em uma sandbox de nível de sistema: isolar o ambiente onde o Agent executa ferramentas, com controle na granularidade de syscalls, leituras e escritas de arquivo e egress de rede. Quanto disso vem ligado por default varia bastante entre ferramentas. O Codex da OpenAI faz sandbox de execução de comandos por default e corta a rede por default; enquanto a sandbox local do Claude Code tem que ser ligada na mão, e a sandbox do Cursor, pela própria descrição, é apenas “best-effort” e não deve ser tratada como fronteira de segurança. Indo mais longe, dá para colocar o Agent inteiro dentro de um runtime gerenciado pela plataforma, entregando rede e credenciais a essa camada externa em vez de ao modelo. O managed Claude Code da Anthropic, hospedado em nuvem, funciona exatamente assim: cada sessão roda numa VM gerenciada pela Anthropic, todas as requests de saída passam por um proxy com allowlist e as credenciais ficam fora da sandbox.
Vem uma pergunta natural: se o sandboxing está tão maduro, como aquelas deleções e uploads de repositório aconteceram? Dois motivos. Primeiro, a proteção por default nessas ferramentas costuma ser fina — o Cursor não tem sandbox estrita por default, e no caso do GPT-5.6 o usuário simplesmente concedeu acesso completo, o que equivale a desligar a sandbox. Segundo, mesmo com a sandbox ligada ela não impede essa classe de incidente: uma sandbox protege contra o Agent escapar e prejudicar o host, mas os bancos que foram apagados e os repositórios que foram enviados eram coisas às quais o Agent estava explicitamente autorizado a chegar, sem necessidade de fuga. Portanto, a sandbox é uma camada necessária e nem de longe suficiente.
Essa ideia de “cercar o alcance do Agent” também chegou a produtos voltados a usuários comuns de escritório. O assistente de desktop WorkBuddy, lançado este ano pela Tencent, roda no computador pessoal e só lê as pastas locais que o usuário autorizou. Os materiais públicos, no entanto, só falam de “pastas autorizadas” e não explicam como o isolamento por baixo funciona de fato, nem até onde ele vai.
O ponto mais importante: toda essa categoria de “Agents com sandbox” compartilha um mesmo ponto cego. Uma sandbox controla onde o Agent roda e se ele pode escapar para prejudicar o host, mas não o que ele faz com os dados uma vez rodando. Um Agent com prompt injection se move inteiramente por canais explicitamente permitidos e é indistinguível da operação normal. Como disse um pesquisador de segurança, avaliando a GKE Agent Sandbox do Google: isso é uma “isolation sandbox”, não uma “behavior sandbox” — decide onde o Agent roda, mas não vigia o que ele faz enquanto roda.
Justamente porque uma sandbox só consegue regular onde o Agent roda e não o que ele faz com os dados, o Google DeepMind propôs uma abordagem mais radical: tratar o modelo grande como componente não confiável desde o início e envolvê-lo em uma camada fixa, sem IA, que decide passo a passo se ele pode agir. O CaMeL deles compila a instrução confiável do usuário em um programa executado por um interpretador sem IA; esse interpretador rastreia a proveniência de cada pedaço de dado e, antes de cada chamada de ferramenta, decide por política se libera — enquanto o modelo que realmente toca o conteúdo externo não confiável não tem qualquer poder de chamar ferramentas. Em boa parte das tarefas, isso entrega “segurança demonstrável”.
A parte difícil que a sandbox não resolve: os dados que o Agent realmente precisa
Ainda assim, seja sandbox ou CaMeL, existe um problema mais duro que nenhum dos dois escapa, e é a parte mais escorregadia da história inteira.
Uma sandbox separa o Agent do host, mas não constrói muralha em volta dos dados de que o Agent precisa para trabalhar. O código, o .env, o banco que ele tem que consultar — tudo vive no mesmo ambiente que o Agent; e para funcionar, o Agent precisa de algum canal de saída. Assim, um Agent comprometido continua conseguindo mandar para fora o que consegue ler, por esse canal permitido. A própria documentação de sandbox da Anthropic reconhece isso: enquanto o egress de rede for permitido, dados que o Agent consegue ler podem ser levados embora, porque a allowlist filtra por domínio e não inspeciona o que está saindo.
Então, como proteger os dados sem os quais o Agent não faz o trabalho? Divide-se em três casos, cada um mais duro que o anterior.
O primeiro são credenciais explícitas, por exemplo uma API key. O Agent não precisa entender o conteúdo da chave; ele só a usa para disparar requests. Então dá para mostrar ao modelo, do começo ao fim, apenas um placeholder, e ter um runtime gerenciado externo substituindo a chave real só no momento da request de verdade. Mesmo se alguém arrancar “a chave” pelo prompt, o que ganha é um dummy inútil. Esse caso, na engenharia, essencialmente se resolve.
O segundo são dados que o Agent tem que ler e raciocinar em cima ele mesmo. Um Agent de análise financeira que não recebe dados financeiros simplesmente não funciona. Aqui uma substituição simples não serve. Um meio-termo é rodar um sub-Agent fortemente isolado que seja o único a tocar os dados sensíveis e devolver só uma conclusão. Mas fica um problema inescapável: ninguém garante que a conclusão em si não seja sensível. Vazamentos costumam ser parafraseados e enterrados no significado, onde matching por keyword não pega. Isolar diminui o raio da explosão; não sela de verdade.
O terceiro e mais radical é o rastreamento de fluxo de informação: rotular cada pedaço de dado, seguir para onde ele flui e interceptá-lo no instante em que tenta sair. O Fides, da Microsoft, vai por esse caminho, usando information-flow control para rastrear o movimento de cada dado — em princípio, a abordagem mais limpa. Mas também é a mais cara: freia performance, penaliza usabilidade, os rótulos se multiplicam, e alguém precisa escrever e manter as políticas. Entre segurança e usabilidade, é aqui que o trade-off morde mais forte.
A engenharia de sistemas da segurança de Agent: isolamento, controle e rastreabilidade
Nenhuma dessas abordagens resolve o problema sozinha: guardrails são contornados, sandboxes não seguram os dados, information-flow tracking custa demais, e o isolamento por sub-Agent não garante que a conclusão não seja sensível.
Mas é exatamente assim que a segurança sempre funcionou. Não existe “seguro” ou “inseguro” absoluto; o que dá para fazer é ir aumentando o custo do ataque e diminuindo o raio da explosão de um incidente.
Então, para um time que quer de fato construir um produto de Agent de nível empresarial (ToB), não existe bala de prata. A jogada praticável é empilhar três coisas. Primeiro, isolamento: usar sandboxes de nível de sistema e restrições externas para delimitar de forma estrita o que o Agent pode fazer. Segundo, controle por política: usar menor privilégio e regras fixas para restringir o que, dentro desse cerco, ele efetivamente pode tocar. Terceiro, rastreabilidade: usar logs e uma trilha de auditoria para que, se algo der errado, dê para apontar em qual passo e por qual parte o problema aconteceu.
Os dois primeiros são prevenção; o terceiro esquece-se com facilidade e é igualmente importante. Guardrails têm a ver com impedir coisas ruins de acontecerem; logs têm a ver com poder explicar o que aconteceu quando aconteceram — e nenhum substitui o outro. Existe uma falha reveladora na prática: muitas empresas relataram incidentes de segurança de Agent, suspeitos ou confirmados, mas pouquíssimas de fato tratam o Agent como uma entidade que precisa de sua própria autorização e sua própria responsabilização. Essa lacuna é a fraqueza mais concreta da segurança de Agent hoje.
Os AI Agents estão passando de “responder perguntas” para “fazer o trabalho por você”. Quanto mais autônomo o Agent, mais o usuário entrega — decisão, dados, todo tipo de credencial e chave. Esperar que o modelo aprenda contenção por conta própria, ou escrever mais algumas centenas de regras de guardrail — ambos ficam dentro do modelo, no mesmo nível do modelo, e não seguram os problemas descritos acima. Para uma empresa tornar um Agent verdadeiramente utilizável, a linha de defesa tem que ser construída fora do modelo: uma sandbox delimita o que ele pode operar; menor privilégio restringe a que dados ele pode chegar dentro desse cerco; logs registram cada passo, para que, se algo der errado, dê para rastrear até a origem. Essas três camadas juntas é que merecem o nome de arquitetura de segurança de Agent pronta para empresa.