Agente de IA já deixou de ser só autocomplete bonito. Hoje ele escreve código, abre navegador, consulta warehouse, responde ticket, mexe em nuvem e em alguns casos já opera com credenciais que antes ficavam só na mão de gente do time.
O problema é que a segurança não acompanhou esse salto no mesmo ritmo. Um relatório novo do AIRQ, que avaliou 100 agentes populares, chegou numa conclusão desconfortável: só 11% combinam capacidade alta com defesa forte. O resto se divide entre setups estreitos, improvisados ou simplesmente expostos demais para o poder que receberam.
Para quem trabalha com desenvolvimento, plataforma, DevOps ou segurança aplicada ao produto, o recado é bem direto: o risco deixou de estar só no modelo. Agora ele mora no agente inteiro — permissões, conectores, ações automáticas, sandbox e saída de dados incluídos.
O dado que mais assusta não é o 11%
O número que chama o clique é esse, claro. Mas o ponto mais sério do AIRQ é outro: 98% dos agentes avaliados já reúnem a “tríade letal” descrita no relatório — acesso a dados privados, contato com conteúdo não confiável e capacidade de agir para fora.
Em português claro, isso significa que um e-mail, documento, ticket ou página maliciosa pode virar instrução. E, se esse agente também tiver acesso demais e liberdade demais, a cadeia inteira vai junto.
Não é só um problema de prompt injection em tese. É um problema de blast radius. O agente lê, interpreta, conecta e executa usando autoridade emprestada da empresa.
Ferramenta que executa sem sandbox muda tudo
Um dos achados mais úteis do relatório é quase brutal na simplicidade: execução de ferramentas explica 76% da variação de blast radius. Ou seja, antes de discutir marca, promessa de vendor ou benchmark de produtividade, a pergunta mais importante é outra:
esse agente executa ferramenta de verdade? E essa execução está isolada?
Quando a resposta é “sim, executa” e “não, não está bem isolada”, a conversa muda de nível. A partir dali, já não estamos falando de um copiloto simpático. Estamos falando de um operador probabilístico com acesso real a shell, browser, integração SaaS, pipeline, credencial ou dado sensível.
O AIRQ também bate numa ferida que o mercado adora contornar: muita defesa alegada não é verificável. Segundo a avaliação, 83% dos controles reivindicados não têm prova pública suficiente. Tem observabilidade, marketing e compliance bonito, mas pouca evidência concreta de contenção técnica de dano.
Por que isso importa tanto para devs agora
A discussão brasileira sobre IA em engenharia já começou a mudar de eixo. Um bom texto da Alura resumiu bem essa virada: o centro de gravidade saiu do ato de digitar código e foi para especificar, revisar, validar e proteger sistemas que agora produzem software em nosso nome.
É aí que esse relatório entra com força. Se o trabalho do time sobe de camada, o guardrail também sobe. Não basta mais perguntar se o agente gera código melhor. É preciso perguntar:
- com quais permissões ele opera,
- que tipo de entrada externa ele consome,
- que ação irreversível ele pode disparar,
- e o que existe entre um erro e um estrago real.
O hype gosta de vender autonomia. Operação madura pensa em contenção.
O mercado já está correndo atrás — e isso por si só já diz muito
No mesmo ciclo de notícias, a Microsoft anunciou novas camadas para proteger agentes, modelos e descoberta de vulnerabilidades: isolamento de execução, registro de agentes, observabilidade, controles de acesso, proteção contra exfiltração de dados e inspeção de modelos antes do deploy.
Esse movimento é importante por dois motivos. Primeiro, porque mostra que o problema ficou grande demais para continuar tratado como detalhe de prompt. Segundo, porque reforça a tese central do AIRQ: a vantagem durável não está só no modelo, e sim no sistema de contenção em volta dele.
Se até o mercado que quer vender agente precisa reforçar container, identidade, trilha de auditoria e proteção de dados, então nenhuma equipe deveria soltar esse tipo de ferramenta em produção como se fosse extensão inocente da IDE.
O que eu trataria como gate mínimo antes de liberar agente de verdade
- Sandbox documentado e testado: não como promessa, mas como parte verificável da execução.
- Identidade mínima por tarefa: o agente não deveria herdar acesso amplo só porque “fica mais prático”.
- Controle de saída: olhar e limitar egress é tão importante quanto filtrar entrada.
- Aprovação para ação irreversível: deletar, publicar, rodar em produção ou expor dado sensível não deveria sair no piloto automático.
- Dois scores internos: avaliar o agente como o vendor entrega e como o seu time realmente configurou.
Isso parece burocracia até o dia em que uma integração inocente vira incidente auditável no seu nome.
O resumo menos glamouroso — e mais útil
Agente de IA não é perigoso porque “a IA ficou malvada”. Ele fica perigoso quando junta poder, contexto externo, credencial e ação sem freio suficiente no meio.
O relatório do AIRQ é forte justamente porque ajuda a tirar a discussão do campo místico. Em vez de perguntar se agente é o futuro, ele pergunta algo muito mais útil: qual agente, com qual alcance, com qual defesa e com qual prova?
Para times de TI, essa provavelmente é a pergunta certa de 2026.
Fontes
- AIRQ — AI Risk Quadrant for Agent Security
- Adversa AI — AIRQ methodology and top 100
- Help Net Security — Only 11% of production agents pass the AI agent security bar
- Help Net Security — Microsoft responds to security challenges facing code, AI agents, and models
- Alura — Engenharia de software na era da IA: novo jogo, novas regras
