O seu agente de IA tem a chave da base de dados. Quem mais a tem?

De chatbot a utilizador privilegiado

Em 2024 o risco de um chatbot era dizer algo errado. Em 2026 o risco é fazer algo errado. Agentes ligados por function calling, MCP (Model Context Protocol) ou integrações diretas consultam o CRM, abrem tickets, emitem reembolsos, executam SQL e chamam APIs internas. O modelo tornou-se um utilizador do sistema — muitas vezes com uma service account com mais permissões do que qualquer humano.

O OWASP Top 10 para LLM chama a isto Excessive Agency (LLM06) e Insecure Output Handling (LLM02). Na prática, é o que mais gera achados críticos nos nossos testes de agentes.

Os cinco padrões que encontramos

1. A tool confia no modelo

get_invoice(customer_id) recebe o ID que o modelo decidiu passar. Se o modelo puder 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 dentro da tool, ligada à identidade do utilizador autenticado — nunca a um parâmetro escolhido pelo modelo.

2. Uma credencial para tudo

O agente corre com uma única API key ou service account que vê todos os tenants. Qualquer injeção bem-sucedida torna-se acesso total. Já vimos agentes de suporte com permissão de escrita na base de dados de produção "porque uma tool precisava de atualizar um estado".

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 de um prompt que as encadeie. Testar tool a tool não encontra isto — é 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 torna-se um incidente financeiro. O padrão seguro é human-in-the-loop para qualquer ação destrutiva ou que movimente valor, com limites 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 comandos com um salto a mais. O caso clássico: o agente gera um link com dados do contexto no URL e o próprio cliente da aplicação faz o pedido que exfiltra.

Como reduzir o raio de impacto

• Menor privilégio por tool, com a identidade do utilizador 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, com 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 excerto 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 isto

No AI/LLM Pentest mapeamos cada tool, credencial e integração do agente, testamos injeção direta e indireta, encadeamentos e escalada de privilégios, e entregamos PoC reproduzível com o impacto real — o registo exposto, o e-mail enviado, o reembolso emitido em ambiente de teste. Se o seu agente já tem acesso a dados de clientes, já faz parte da sua superfície de ataque.