A quinta engenharia: como impedir que agentes de IA em Python façam o que não devem

Um agente de IA com acesso ao seu git pode fazer push de código que ninguém aprovou. Basta ler um texto com a instrução certa.

No artigo do Felipão sobre a live com o Oswaldo, ficam claras quatro engenharias para fazer um time de agentes de IA produzir. Concordo com todas. Mas, operando um pipeline com agentes no meu projeto pessoal, aprendi que falta uma: a engenharia que garante que o time não faça o que não deve. Chamo de engenharia de autoridade.

Neste artigo:

1. Um bug de 1988 que voltou
2. Por que agentes de IA são o alvo perfeito
3. Por que pedir confirmação ao modelo não resolve
4. A defesa em código, testada em Python
5. Como aplico isso no meu dia a dia

Um bug de 1988 que voltou

Em 1988, Norm Hardy descreveu um problema real da Tymshare. Um compilador tinha permissão para gravar num arquivo de cobrança do sistema. Um usuário pediu que o compilador salvasse o resultado com o nome desse arquivo, e o compilador obedeceu, sobrescrevendo a cobrança. O usuário não tinha permissão para isso, mas o compilador tinha, e foi usado como intermediário.

Hardy chamou isso de Confused Deputy, o "representante confuso": um programa com autoridade legítima é enganado para usá-la em nome de quem não deveria ter esse poder.

Por que agentes de IA são o alvo perfeito

Um agente de IA recebe permissões (ler arquivos, rodar comandos, mexer no git) e instruções em linguagem natural. Qualquer texto que ele lê pode virar instrução: um README, um comentário, um e-mail. É o prompt injection, primeiro item do OWASP Top 10 para aplicações com LLM (LLM01).

O OWASP lista outros dois riscos diretamente ligados a isso:

• LLM05, tratamento inadequado de saída: confiar no que o modelo gera e executar sem validação.
• LLM06, agência excessiva: dar ao agente mais permissões, funções ou autonomia do que a tarefa exige.

Juntos, os três descrevem exatamente o Confused Deputy de Hardy, agora com linguagem natural no lugar do nome de arquivo.

Por que pedir confirmação ao modelo não resolve

A defesa mais comum é escrever no prompt: "nunca faça push" ou "confirme antes de ações perigosas". O problema é que a regra e o ataque moram no mesmo lugar, o texto que o modelo lê. Se uma injeção consegue convencer o modelo a agir, também consegue convencê-lo de que a ação está autorizada. Pedir para o modelo checar a si mesmo é pedir para o representante confuso perceber que está confuso.

A defesa em código, testada em Python

A solução que Hardy apontou em 1988 continua valendo: a autoridade precisa viajar junto com o pedido e ser verificada fora do julgamento de quem executa. Em agentes, isso significa colocar entre o modelo e a ação um portão em código determinístico, que não lê intenção, só verifica regras.

Montei um estudo em Python que reproduz o ataque e testa a defesa com capabilities: o agente só executa ações cuja permissão foi explicitamente concedida para aquela tarefa.

O resultado do demo cabe em quatro linhas, comparando o caso clássico de 1970 com um pipeline de agentes de 2026:

• Compilador clássico, vulnerável (licença ampla sobre os arquivos): EXPLOITED
• Compilador clássico, mitigado (token de capability por arquivo): BLOCKED
• Pipeline de agente de IA, vulnerável (autoridade ambiente da aplicação): EXPLOITED
• Pipeline de agente de IA, mitigado (token de sessão com escopo): BLOCKED

O padrão é o mesmo nas duas épocas: quando a autoridade é ambiente, o ataque passa; quando ela é uma capability com escopo, o ataque para.

O demo também testa a defesa que mais vejo por aí: perguntar ao próprio modelo se a ação é permitida. No Módulo 4, essa autoverificação respondeu "True" e liberou uma ação maliciosa. Só a barreira determinística bloqueou, porque a ação estava fora do escopo da capability.

Defesa que nunca foi atacada pelo próprio autor ainda não foi testada.

Como aplico isso no meu dia a dia

1. O executor não tem permissão de git. Staging, commit e push são só meus, por comando que eu reviso.
2. A regra não fica só no prompt. Um hook em código bloqueia a ação antes de ela acontecer.
3. A checagem humana fica onde a ação é irreversível, não só na especificação.

Conclusão

As quatro engenharias fazem o time de agentes entregar. A quinta garante que ele não entregue o que ninguém autorizou. Produtividade sem autoridade verificada em código é só um representante confuso mais rápido.

Repositório com o ataque e a defesa: github.com/Pablit0rg/confused-deputy-demo

Referências

• Hardy, N. The Confused Deputy (or why capabilities might have been invented). ACM SIGOPS Operating Systems Review, 1988.
• OWASP. Top 10 for LLM Applications 2025 (LLM01, LLM05, LLM06). genai.owasp.org/llm-top-10

Sobre o autor

Sou Pablo, desenvolvedor autodidata focado em Python, IA e segurança de agentes. O ataque e a defesa deste artigo estão testados e documentados no repositório acima. Se você trabalha com agentes de IA, me chame pra conversar.

GitHub: github.com/Pablit0rg