Um agente de IA não é perigoso porque escreve textos convincentes. Ele se torna perigoso quando texto não confiável consegue influenciar ações: chamadas de API, edições de arquivos, consultas em banco, atualização de tickets, comandos de shell ou mensagens enviadas para outros sistemas. Segurança de agentes começa separando o que o modelo pode ler do que o sistema pode executar.
Prompt injection muitas vezes é descrito como um problema de texto: uma instrução maliciosa escondida em uma mensagem, página, email, documento, issue de repositório ou chunk recuperado por RAG. Em sistemas com agentes, porém, o risco real está na execução. O ataque importa porque o modelo pode transformar contexto manipulado em uma chamada de ferramenta.
A página da OWASP sobre prompt injection trata o tema como uma vulnerabilidade que mira o comportamento de LLMs. Para quem constrói backend, o próximo passo é perguntar qual fronteira do sistema recebe a saída do modelo. Se a resposta for "uma ferramenta com permissões", prompt injection deixa de ser só comportamento do modelo e vira problema de autorização e controle de fluxo.
O trabalho do NIST em 2026 sobre segurança de agentes de IA destaca riscos de agentes interagindo com dados adversariais, incluindo prompt injection indireto. Em um texto sobre red teaming, o NIST descreveu sequestro de agentes como um risco crescente quando agentes processam fontes externas como emails, sites e repositórios de código. É exatamente nesses lugares que agentes de engenharia trabalham.
Segurança de aplicações clássica assume que código controla a execução. Sistemas agentic adicionam um planejador probabilístico entre o usuário e a ação. Esse planejador pode ser útil, mas não deve virar a camada de enforcement. O enforcement precisa acontecer em código determinístico: políticas, schemas, allowlists, aprovações, sandboxing e logs.
A primeira regra de design é quarentena de contexto. Instruções de sistema, políticas de desenvolvedor, intenção do usuário, conteúdo recuperado, saídas de ferramentas e documentos externos não têm o mesmo peso. Eles devem ser representados como classes diferentes de dados e passar por caminhos de controle diferentes.
Uma arquitetura segura trata conteúdo não confiável como evidência, não como autoridade. O agente pode resumir, citar e usar esse conteúdo para propor um plano. Ele não deve permitir que esse conteúdo redefina política, conceda permissões, escolha credenciais ou elimine aprovações.
Prompt injection é um caminho para abuso de ferramentas, mas não é o único. Um agente também pode usar ferramentas de forma indevida por objetivos ambíguos, permissões amplas demais, retrieval ruim, schemas fracos, validação ausente ou um modelo que otimiza conclusão de tarefa sem respeitar fronteiras operacionais.
O OWASP MCP Top 10 destaca riscos diretamente ligados a ferramentas de agentes, incluindo command injection e prompt injection por payloads contextuais. Isso importa porque servidores MCP e adaptadores de ferramentas costumam ficar perto de sistemas poderosos: arquivos, navegadores, bancos, CI, APIs cloud e painéis administrativos.
Agentes não deveriam receber uma capacidade genérica de "executar comando" ou "chamar API" a menos que o ambiente esteja fortemente isolado e o raio de impacto seja pequeno de propósito. Ferramentas de produção devem ser estreitas: criar issue em rascunho, ler status de deploy, buscar fatura por ID, resumir logs do serviço X ou abrir pull request sem direito de merge.
Essa é a diferença entre expor uma cozinha inteira e expor um botão. O agente não precisa da cozinha toda para cada tarefa. Ele precisa de uma operação segura, com entradas tipadas, políticas e saída previsível.
| Ameaça | Sinal de exemplo | Controle backend |
|---|---|---|
| Prompt injection indireto | Documento externo manda o agente ignorar instruções anteriores. | Quarentena de contexto, scanner de prompt injection e proibição de mudar política via conteúdo recuperado. |
| Agência excessiva | Agente pode enviar emails, editar arquivos e fazer deploy com um token amplo. | Escopos em formato de tarefa, allowlists de ferramentas e aprovações. |
| Manipulação de saída da ferramenta | Resultado da ferramenta contém instruções para guiar a próxima ação. | Schemas rígidos de saída, escaping, rótulos de confiança e validação secundária. |
| Exfiltração de dados | Agente tenta enviar segredos para uma URL externa ou mensagem. | Checagens DLP, controle de egress, mascaramento e allowlists de destino. |
| Bypass de política | Agente chama uma API direta em vez do gateway aprovado. | Segmentação de rede, credenciais centralizadas e acesso default-deny. |
Eu construiria um gateway de segurança de agentes na frente de toda ferramenta privilegiada. O gateway receberia chamadas propostas, validaria o schema de entrada, classificaria risco, checaria política, aplicaria allowlists de destino, exigiria aprovação quando necessário, executaria a ação com credencial escopada e gravaria um evento de auditoria imutável.
Para um stack pequeno e realista, eu usaria Cloudflare Workers no gateway, FastAPI para ferramentas internas de maior risco, Supabase/Postgres para políticas e auditoria, e uma fila para aprovações humanas. Cada ferramenta teria schema, nível de risco, recursos permitidos, destinos permitidos e nível máximo de autonomia.
Prevenção não pega tudo. Sistemas com agentes precisam de detecção: ações bloqueadas repetidas, sequências incomuns de ferramentas, acesso repentino a recursos sensíveis, chamadas disparadas por conteúdo não confiável e saídas contendo segredos ou destinos externos. Isso deve virar métrica e alerta, não só log que alguém talvez leia depois.
Os melhores dashboards tratam atividade de agente como operação de produção: volume de ações, tentativas bloqueadas, fila de aprovação, latência de ferramentas, chamadas de alto risco, principais fontes externas e negações recentes de política. Se um agente pode agir, ele precisa ser observável.
Não peça ao modelo para ser a fronteira de segurança. Peça a sistemas determinísticos para serem essa fronteira. O modelo pode propor, explicar, resumir e rascunhar. O plano de controle decide o que pode executar.
Artigo sobre segurança de agentes de IA cobrindo prompt injection, prompt injection indireto, abuso de ferramentas, agência excessiva, segurança MCP, quarentena de contexto, gateways de ferramentas, validação de schema, aprovação humana, controles de egress, logs de auditoria e detecção em sistemas agentic.