Seu Agente de IA É um Insider Sem Crachá

Todo time de segurança já sabe lidar com um insider. Você dá à pessoa um crachá ligado a uma identidade real. Você limita o acesso ao escopo do trabalho. Você registra o que ela toca, e o registro diz quem foi. Quando algo dá errado, você consegue atribuir a ação a um humano e decidir se foi engano, falha de processo ou má-fé.

Agora olhe para o agente de IA que você colocou em produção no último trimestre. Ele roda com privilégios elevados. Não tem identidade própria estável. A memória dele vaza entre as pessoas que atende. E nada limita o estrago que uma decisão ruim pode causar. Amod Puranik, da Virtusa, colocou o enquadramento de forma direta no BankInfoSecurity: agentes de IA são os novos insiders. A diferença é que esse insider entrou sem crachá, e o seu posto de controle não tem scanner capaz de lê-lo.

Já escrevemos sobre as partes disso antes. Identidade de agente na rede. Tenancy de memória. Raio de impacto da autonomia. Este ensaio amarra esses fios em um único nó, porque o time de segurança que avalia um insider humano não avalia identidade, acesso e dados em separado. É uma avaliação só. Um agente deveria enfrentar a mesma, e hoje ele falha nos três eixos ao mesmo tempo.

Controle Um: Identidade que Você Consegue Atribuir

A primeira coisa que você pergunta sobre qualquer insider é “quem”. Para um agente, a resposta honesta hoje é “uma service account”. Isso não é uma identidade. É uma chave compartilhada.

Puranik nomeou a consequência com precisão. Quando um agente age, os logs mostram que a service account fez algo. Não mostram se a ação veio da tarefa que ele recebeu, de um erro do desenvolvedor na configuração, ou de um ator externo que o manipulou por um input envenenado. A trilha forense para na service account e não vai além. Você não consegue inferir intenção a partir de uma credencial.

Um insider humano não tem esse problema. O crachá é dele. Se apaga uma tabela, o log carrega o nome dele, e você investiga uma pessoa, não uma chave. O agente quebra a atribuição porque muitas tarefas, muitos usuários e muitos caminhos de gatilho colapsam todos na mesma credencial não-humana. Argumentamos em identidade de rede para o sandbox do agente que agentes precisam de identidade própria na camada de rede. O enquadramento de insider eleva a aposta. Identidade não é refinamento de rede. É a pré-condição da perícia. Sem ela, toda revisão de incidente termina num dar de ombros.

O controle que um time de segurança exigiria: uma identidade distinta e atestável por instância de agente, idealmente por tarefa, para que uma linha de log responda “quem” com algo mais específico que o nome de um robô que atende todo mundo.

Controle Dois: Menor Privilégio que Você Consegue Aplicar

O segundo controle de insider é escopo. Pessoas recebem o acesso que o cargo exige e nada mais. O agente inverte isso. A análise da Docker sobre falhas recentes de agentes de código descreveu o arranjo padrão sem rodeios: o agente roda como você, no seu sistema de arquivos, com as suas credenciais, e nada se interpõe entre a decisão do modelo e a execução no shell.

Leia essa frase de novo, porque ela é o problema inteiro. O agente herda o seu raio de impacto. Tudo o que você alcança, ele alcança. Tudo o que você pode destruir, ele pode destruir, na velocidade da máquina, no instante em que decidir.

O registro público do fim de 2025 até o começo de 2026 mostra o custo disso. As Coding Agent Horror Stories da Docker catalogam quatro destruições de diretório home em cerca de três meses: um usuário de macOS cujo agente rodou rm -rf na pasta home, dois incidentes distintos no GitHub registrados como issues 10077 e 12637, e um caso Cowork que apagou um arquivo de família com quinze a vinte e sete mil fotos. Quatro eventos de rm -rf ~/, não um. O padrão não é acaso. É o resultado previsível de um insider com root e sem porteiro.

Um humano com root ainda esbarra numa etapa de aprovação antes de uma operação destrutiva, ou pelo menos numa separação entre a conta que constrói e a conta que pode apagar. O agente não tem nenhuma das duas por padrão. A correção não é um system prompt melhor pedindo cuidado. Mostramos em outro lugar que a priorização de instruções dentro do modelo resolve a cerca de 40% sob profundidade realista, o que faz de uma regra em nível de prompt um cara-ou-coroa que você continua perdendo. A correção é estrutural: isolamento em nível de kernel para o agente rodar num sandbox, credenciais escopadas e com tempo limitado para ele segurar só o que a tarefa precisa, e uma porta fora do modelo em toda ação irreversível. A taxonomia detalhada está em três falhas de autonomia, três raios de impacto. A lente de insider só renomeia o problema. Isto é menor privilégio, e o agente não o tem.

Controle Três: Tenancy de Dados em que Você Pode Confiar

O terceiro controle é o que a maioria dos times sequer começou. Um insider humano numa firma multicliente é contido por uma parede: o analista da conta A não vê os dados da conta B. O agente vaza direto por essa parede, e o vazamento não é raro.

O relatório State of Memory in Agent Harness da Mem0 coloca a banda de contaminação entre usuários em 57 a 71 por cento em oito harnesses de agente, incluindo Claude Code, Codex, Copilot, OpenClaw, Hermes, Bedrock AgentCore, Windsurf e Devin. Trate esse número com cuidado. Vem de um fornecedor, foi publicado como achado direcional e não como resultado auditado, e o relatório traz uma banda agregada sem abertura por harness. Então não cite como dogma. Mas, mesmo na ponta baixa, mais da metade desses harnesses deixa a memória de um usuário sangrar para o contexto de outro, e esse é um número que um responsável por segurança não pode ignorar. As fontes independentes ao redor, a Docker sobre raio de impacto e Puranik sobre atribuição, apontam na mesma direção: os controles que contêm um humano simplesmente não existem para o agente.

O que contaminação significa na prática: um agente de consultoria atendendo dois clientes concorrentes pode trazer o preço, a estratégia ou o contexto privado de um cliente para dentro da sessão do outro. Nenhum analista humano sobreviveria a fazer isso uma vez. O agente faz mais da metade das vezes, de forma estrutural, porque a camada de memória dele foi construída para conveniência, não para tenancy. Cobrimos o mecanismo em o déficit de governança na memória dos agentes. O enquadramento de insider afia a obrigação. Isolamento por tenant na memória não é pedido de feature. É a versão digital da parede de confidencialidade que toda firma regulada já aplica entre funcionários humanos.

O controle que um time de segurança exigiria: memória particionada por tenant na camada de armazenamento, de modo que a recuperação fisicamente não consiga cruzar uma fronteira de cliente, verificada por teste, não prometida por configuração.

Faça Isto Agora

Escolha o seu agente mais usado. Rode as três perguntas de insider que um time de segurança faria num novo contratado, e anote a resposta de cada uma:

Atribuição. Quando este agente age, o log nomeia uma identidade distinta ou nomeia uma service account compartilhada? Se for conta compartilhada, você não consegue investigar um incidente. Só consegue chutar.
Escopo. Qual é a pior coisa irreversível que este agente pode fazer agora, e existe algo fora do modelo que o impeça? Se a resposta honesta for “ele roda como eu, com as minhas credenciais, sem nada no meio”, você tem um rm -rf ~/ esperando para acontecer.
Tenancy. Se este agente atende mais de um cliente ou time, a memória dele pode carregar dados através dessa fronteira? Teste. Não confie na tela de configuração.

Se você falhar em qualquer uma das três, a correção é arquitetural, não um parágrafo a mais no prompt. Isolamento de kernel dá escopo. Identidade não-humana dá atribuição. Tenancy de memória dá a parede de confidencialidade. Nenhuma das três mora num system prompt, porque o modelo é justamente o que você está tentando conter, e você não pede ao suspeito que escreva a política de segurança.

O agente já está dentro. Dê a ele um crachá que você consiga ler, um escopo que ele não consiga exceder e uma parede que ele não consiga atravessar. Isso não é refinamento de governança. É o mínimo que você já exige de todo humano que trabalha para você.

Fontes

BankInfoSecurity (ISMG), Amod Puranik, Virtusa. “AI Agents Are the New Insiders.” May 2026.
Mem0. “State of Memory in Agent Harness.” June 2026.
Docker, Ajeet Singh Raina. “Coding Agent Horror Stories: The rm -rf Incident.” June 2026.

A Victorino ajuda CTOs e líderes de segurança a tratar agentes como insiders e a construir os controles de identidade, isolamento e tenancy de memória que faltam por padrão: contato@victorino.com.br | www.victorino.com.br