Prompt injection influencia o que um modelo quer fazer. O incidente acontece quando o sistema ao redor permite que esse modelo influenciado use a autoridade de outra pessoa para ler dados, chamar tools ou alterar estado.
O NIST define prompt injection como um ataque que explora a combinação de input não confiável com um prompt criado por uma parte de maior confiança. Seu trabalho sobre sequestro de agentes mostra a consequência operacional: instruções maliciosas dentro de dados podem fazer um agente executar ações indesejadas. Uma apresentação de segurança do NIST de 2026 vai além e descreve prompt injection indireta como geralmente ligada a um problema de confused deputy.
O deputy é o agente. Ele consegue ler a caixa de entrada do usuário, consultar dados internos, chamar uma tool MCP ou aprovar um workflow porque o sistema lhe entregou credenciais. O invasor não precisa dessas credenciais diretamente. Basta influenciar o deputy que já as possui.
Classificadores, prompts estruturados, sanitização de conteúdo, treinamento do modelo e red teaming são importantes. O Google descreve uma defesa em camadas que também inclui confirmação para operações arriscadas. A Anthropic alerta explicitamente que nenhum agente de navegador é imune a prompt injection. Isso significa que o design backend deve assumir que uma instrução maliciosa ocasionalmente alcançará o loop de planejamento.
Autorização é a fronteira determinística depois dessa falha probabilística. Cada ação proposta precisa ser verificada contra o principal original, tarefa atual, recursos permitidos, destino, classe de dados, nível de efeito colateral, orçamento e expiração. O modelo pode sugerir uma ação; ele não pode conceder permissão a si mesmo.
Um usuário aprovar “ajude com meu email” não significa aprovar toda ação futura que um email instruir o agente a executar. Autorização não pode ser inferida por proximidade conversacional. Ela precisa ser avaliada novamente na fronteira da ação, com credenciais limitadas àquela ação e curtas o bastante para expirar junto com a tarefa.
O design mais útil separa leitura de dados de execução de ações. Um componente de baixo privilégio inspeciona documentos não confiáveis. Um executor privilegiado recebe uma proposta estruturada e verifica política sem herdar as instruções do documento. Ações de alto risco exigem um canal independente de aprovação que mostre alvo, efeito colateral e dados liberados.
| Camada | Controle | O que previne ou contém |
|---|---|---|
| Fronteira de input | Classificadores, sanitização, rótulos de proveniência e separação entre instrução e dado. | Reduz a chance de conteúdo hostil influenciar o modelo. |
| Identidade do agente | Identidade dedicada, principal responsável e credenciais curtas por tarefa. | Evita ações anônimas ou permanentemente privilegiadas. |
| Tool gateway | Autorização por ação, validação de argumentos e allowlists de destinos. | Bloqueia ações fora da intenção da tarefa mesmo após comprometimento do modelo. |
| Fronteira de dados | Controles de acesso por linha, tenant, campo e finalidade. | Limita o que um agente sequestrado consegue ler ou divulgar. |
| Fronteira de aprovação | Confirmação adicional para ações destrutivas, externas ou financeiras. | Impede uso silencioso de privilégios e torna efeitos colaterais visíveis. |
| Fronteira de evidências | Registra principal, proveniência do input, decisão, tool call, resultado e política. | Torna incidentes de confused deputy detectáveis e reconstruíveis. |
Eu construiria um broker de autorização na frente de cada tool de agente. O broker trocaria a sessão ampla do usuário por um capability token estreito, ligado a uma tarefa, uma tool, recursos permitidos, destinos aprovados, classe máxima de efeito colateral e expiração curta. Cada tool call seria verificada de forma independente.
O produto visual de segurança mostraria dois traces para cada ação: o trace de influência, explicando qual input do usuário, documento recuperado, memória ou output de tool moldou a proposta; e o trace de autoridade, explicando qual identidade, escopo, política e aprovação permitiu ou negou a execução.
Talvez não seja possível garantir que um agente nunca acredite em uma instrução hostil. É possível garantir que acreditar nela não seja suficiente para obter autoridade. Prompt injection se torna administrável quando influência do modelo e permissão backend são tratadas como sistemas separados.
Artigo de segurança de agentes de IA explicando prompt injection como problema de autorização do tipo confused deputy, com least privilege, capability tokens, autorização por ação, aprovação humana e traces de influência e autoridade.