Agências Five Eyes afirmam que a maioria das implantações de IA agentiva já está excessivamente permissiva

Em 1º de maio de 2026, a CISA, a NSA e suas contrapartes do Reino Unido, Austrália, Canadá e Nova Zelândia publicaram o primeiro guia coordenado de segurança multigovernamental para IA agentiva: "Careful Adoption of Agentic AI Services". A mensagem central é direta — organizações de infraestrutura crítica e defesa não estão avaliando um risco futuro; elas já estão executando agentes com mais acesso do que suas próprias equipes de segurança conseguem mapear, e o guia existe porque essa lacuna deixou de ser teórica.

O que torna este documento digno de leitura atenta, mesmo que você não esteja em infraestrutura crítica, é que ele é a primeira tentativa de agências de segurança de categorizar formalmente o que pode dar errado com um agente de IA — em oposição a uma aplicação tradicional — e as categorias se alinham diretamente aos erros que a maioria das equipes que implantam agentes neste momento já está cometendo.

Cinco categorias de risco e por que elas não se reduzem a "prompt injection"

O guia divide o risco da IA agentiva em cinco categorias: privilégio, design e configuração, comportamento, estrutural e responsabilidade. É um enquadramento deliberadamente mais amplo do que o foco padrão da indústria de segurança em prompt injection e jailbreaks, e a lógica é simples — um agente com privilégios estreitos e escopo correto é muito menos perigoso mesmo quando manipulado com sucesso, porque a manipulação não tem para onde ir.

Risco de privilégio trata de agentes que mantêm acesso permanente a sistemas, dados ou ações muito além do que qualquer tarefa exige — o equivalente em IA a uma conta de serviço com privilégios de administrador de domínio porque ninguém se preocupou em limitá-la. Risco de design e configuração abrange agentes conectados a cadeias de ferramentas e fontes de dados externas sem que ninguém mapeie o que essa interconexão realmente expõe. Risco de comportamento é o agente fazer algo não intencional mesmo sem manipulação externa — uma ação emergente que ninguém programou explicitamente. Risco estrutural diz respeito às dependências em camadas que os agentes introduzem (uma ferramenta ou fonte de dados comprometida se torna um agente comprometido). Risco de responsabilidade é o mais difícil de retroadaptar: quando um agente realiza uma ação de consequências, alguém consegue reconstruir por que isso aconteceu e quem é responsável por ter ocorrido.

O problema da superfície de ataque interconectada

O guia é explícito: o principal problema de segurança da IA agentiva não é o modelo — é o número de componentes que um agente tipicamente toca. Um único agente de suporte ao cliente pode chamar uma API de CRM, uma base de conhecimento, um sistema de tickets e uma ferramenta de e-mail, cada um com suas próprias credenciais e modos de falha. O documento alerta que isso cria "uma superfície de ataque interconectada que atores maliciosos podem explorar", porque comprometer qualquer elo dessa cadeia pode comprometer as permissões efetivas do agente em todos eles.

Esse é exatamente o padrão por trás dos incidentes de segurança mais graves com agentes de IA divulgados este ano — atacantes não precisam quebrar o modelo em si quando podem comprometer uma integração de ferramenta fracamente protegida e herdar o acesso que foi concedido ao agente.

O que o guia realmente diz para você fazer

Tirando o enquadramento, o núcleo operacional são cinco regras, todas aplicáveis hoje com ferramentas existentes de identidade e acesso:

Nunca conceda aos agentes acesso amplo ou irrestrito. Se a conta de serviço de um agente pode fazer mais do que sua lista de tarefas documentada exige, essa é a lacuna que atacantes usarão — e geralmente é uma lacuna criada por conveniência durante a implantação inicial, não uma decisão deliberada.

Restrinja os agentes a tarefas de baixo risco e não sensíveis por padrão, e exija uma exceção explícita e revisada para expandir o escopo — invertendo o padrão comum de conceder acesso amplo no início e restringir depois (o que raramente acontece de fato).

Imponha o menor privilégio com autenticação por solicitação, não uma única credencial permanente que o agente mantém por toda a sua vida. Cada chamada de ferramenta deve ser autenticada e com escopo independentemente, para que uma sessão comprometida não herde acesso irrestrito.

Exija aprovação humana para ações de alto impacto — transações financeiras, exclusão de dados, alterações de controle de acesso, qualquer coisa que seja cara ou difícil de reverter. O guia trata isso como inegociável, não como algo bom de ter em implantações iniciais.

Gerencie a segurança de agentes de IA dentro dos frameworks de cibersegurança existentes, não como um programa paralelo e personalizado. Os agentes devem aparecer nos mesmos inventários de ativos, revisões de acesso e playbooks de resposta a incidentes que qualquer outro componente de sistema com credenciais e acesso à rede.

A conclusão para equipes que estão implantando agentes neste trimestre

Se você está colocando um agente de IA em produção e não consegue responder "qual é o raio máximo de explosão se a sessão deste agente for comprometida agora?", o guia das Five Eyes diz que você tem um problema de privilégio, não de modelo. Faça uma auditoria de acesso antes do próximo rollout de agente: liste todas as ferramentas, APIs e fontes de dados que o agente pode alcançar, e então pergunte se cada uma tem escopo para a permissão mais específica da tarefa, e não uma concessão ampla de nível de serviço. Esse único exercício fecha a lacuna que a maioria dos post-mortems de incidentes deste ano tem em comum.