Seu agente de IA tem chave do banco de dados. Quem mais tem?
Agentes com function calling e MCP transformaram o chatbot em um usuário privilegiado do seu sistema. Os cinco padrões de abuso que encontramos em pentests de agentes e como reduzir o raio de explosão.
De chatbot a usuário privilegiado
Em 2024 o risco de um chatbot era dizer algo errado. Em 2026 o risco é fazer algo errado. Agentes conectados por function calling, MCP (Model Context Protocol) ou integrações diretas consultam CRM, abrem tickets, emitem reembolsos, executam SQL e chamam APIs internas. O modelo virou um usuário do sistema — muitas vezes com uma service account que tem mais permissão do que qualquer humano.
O OWASP Top 10 para LLM chama isso de Excessive Agency (LLM06) e Insecure Output Handling (LLM02). Na prática, é o que mais gera achado crítico nos nossos testes de agentes.
Os cinco padrões que encontramos
1. A tool confia no modelo
A função get_invoice(customer_id) recebe o ID que o modelo decidiu passar. Se o modelo pode ser convencido (por prompt injection direta ou por um documento envenenado) a passar o ID de outro cliente, a tool obedece. É BOLA/IDOR com um intermediário que fala português. A correção é a mesma das APIs: autorização na tool, com a identidade do usuário autenticado — nunca com um parâmetro escolhido pelo modelo.
2. Uma credencial para tudo
O agente roda com uma única API key ou service account que enxerga todos os tenants. Qualquer injeção bem-sucedida vira acesso total. Vimos agentes de suporte com permissão de escrita no banco de produção "porque uma tool precisava atualizar status".
3. Encadeamento de tools
Isoladas, read_file e send_email são inofensivas. Juntas, são exfiltração. O atacante não precisa de uma tool perigosa; precisa de duas tools benignas e um prompt que as encadeie. Testar tool por tool não encontra isso — é preciso testar combinações.
4. Ações sem confirmação humana
Reembolsar, apagar, transferir, publicar. Quando o agente executa ações irreversíveis sem um passo de aprovação, um único documento malicioso na base de conhecimento vira um incidente financeiro. O padrão seguro é human-in-the-loop para qualquer ação destrutiva ou que movimente valor, com limite por transação e por período.
5. Saída do modelo tratada como confiável
O modelo devolve markdown, HTML ou JSON que o frontend renderiza ou que outro sistema executa. Sem sanitização, é XSS ou injeção de comando com um passo a mais. O caso clássico: o agente gera um link com dados do contexto na URL e o próprio cliente da aplicação faz a requisição que exfiltra.
Como reduzir o raio de explosão
- Menor privilégio por tool, com a identidade do usuário final propagada (não uma conta do agente).
- Allowlist de tools por contexto: o agente de suporte não precisa de
run_sql. - Separação estrutural entre instruções e dados recuperados, e marcação explícita de conteúdo não confiável.
- Confirmação humana para ações irreversíveis; limites de valor e de taxa.
- Logs de cada chamada de tool com entrada, saída e o trecho de contexto que a motivou — sem isso não há investigação possível.
- Testes de segurança do sistema completo antes de cada expansão de permissões do agente.
Como a Pentest Machine testa isso
No AI/LLM Pentest mapeamos cada tool, credencial e integração do agente, testamos injeção direta e indireta, encadeamentos e escalação de privilégio, e entregamos PoC reproduzível com o impacto real — o registro exposto, o e-mail enviado, o reembolso emitido em ambiente de teste. Se o seu agente já tem acesso a dados de clientes, ele já é parte da sua superfície de ataque.