Agentes de IA ampliam a superfície de ataque: APIs, permissões e uma POC segura

Um chatbot recebe texto e devolve texto. Um agente de IA pode receber uma solicitação, consultar documentos, chamar APIs, decidir qual ferramenta usar e alterar um sistema em nome de alguém. Essa diferença muda o modelo de ameaça. O risco já não termina numa resposta incorreta: ele alcança cada dado, credencial e operação disponível durante a execução.

Quando o chat vira um plano de controle

A arquitetura típica conecta o modelo a um orquestrador, memória, mecanismo de busca, APIs internas e serviços de terceiros. Cada conexão adiciona uma fronteira de confiança. Uma instrução chega pelo usuário, mas também pode vir de um e-mail, documento recuperado, resposta de API ou mensagem de outro agente. Se o modelo consegue transformar esse conteúdo em chamada de ferramenta, qualquer entrada não confiável pode tentar influenciar uma ação privilegiada.

Permissão excessiva transforma erro em impacto

A OWASP descreve agência excessiva a partir de três raízes: funcionalidade, permissão e autonomia em excesso. Um agente criado para resumir chamados não precisa editar usuários, executar consultas arbitrárias nem enviar mensagens. Ainda assim, a integração costuma reutilizar uma conta de serviço ampla porque é mais rápida para a POC. Nesse desenho, o modelo não quebra a autorização. Ele apenas usa uma credencial que já recebeu autorização demais.

• Exponha ao agente apenas as ferramentas necessárias para o caso de uso, sem shell ou cliente HTTP genérico quando uma função específica resolve
• Separe leitura, criação, alteração e exclusão em operações distintas, com escopos próprios
• Execute cada ação no contexto do usuário ou de uma identidade dedicada à função, nunca com uma conta administrativa compartilhada
• Exija aprovação independente para ações destrutivas, financeiras, administrativas ou visíveis externamente
• Aplique limite de chamadas, tempo, custo, profundidade de cadeia e volume por sessão

Segredo no contexto continua sendo segredo exposto

Chaves de API, tokens OAuth e credenciais de banco não deveriam aparecer no prompt, na memória, no retorno de ferramenta ou no log bruto do agente. O modelo precisa receber o resultado de uma operação autorizada, não o segredo que autoriza a operação. Um gateway de ferramentas pode buscar a credencial num cofre, chamar o serviço e devolver apenas os campos permitidos. Tokens curtos, escopos mínimos e rotação reduzem o tempo e o alcance de um vazamento.

A mesma regra vale para dados de negócio. Antes de montar o contexto, a aplicação precisa aplicar autorização por usuário e por objeto, classificação, minimização e mascaramento. Recuperar um documento por similaridade não prova que o solicitante pode lê-lo. Se o filtro de autorização acontece depois da busca, o dado de outra área ou de outro cliente pode já ter entrado no contexto e reaparecer na resposta ou numa chamada externa.

Entrada e saída precisam de contratos separados

Toda entrada externa deve ser tratada como dado não confiável, inclusive respostas de APIs consideradas parceiras. Validar tamanho, tipo, formato e origem reduz ambiguidades, mas não resolve prompt injection sozinho. A decisão importante é arquitetural: conteúdo recuperado não pode ampliar permissões, habilitar ferramenta ou remover uma aprovação exigida pela política.

A saída do modelo também é entrada de outro componente. SQL, HTML, caminho de arquivo, destinatário de e-mail e argumentos de ferramenta precisam passar por schema, allowlist, encoding e autorização antes do uso. A OWASP chama esse problema de Improper Output Handling. Confiar na fluência da resposta como se fosse validação permite que uma saída manipulada alcance um interpretador ou uma API privilegiada.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "tool": { "const": "crm.read_contact" },
    "contact_id": {
      "type": "string",
      "pattern": "^[a-z0-9-]{1,64}$"
    }
  },
  "required": ["tool", "contact_id"],
  "additionalProperties": false
}

Integração de terceiro é parte da cadeia de ataque

Plugin, conector, servidor MCP, modelo, base vetorial e API SaaS fazem parte da cadeia de suprimento do agente. O NIST AI 600-1 recomenda inventariar terceiros com acesso ao conteúdo da organização, avaliar riscos de fornecedores, manter monitoramento e preparar resposta a incidentes. Na prática, não basta perguntar se o fornecedor criptografa dados. É preciso saber quais dados recebe, onde ficam, por quanto tempo são retidos, quem consegue chamar a integração e o que acontece quando ela falha ou é comprometida.

• Mantenha inventário de modelos, ferramentas, APIs, fontes de dados e responsáveis por cada integração
• Fixe versões e valide origem, assinatura e mudanças de conectores quando o ecossistema oferecer esses controles
• Defina timeout, retry limitado, circuit breaker e comportamento seguro para resposta ausente ou malformada
• Remova ferramentas de experimento que deixaram de ser necessárias e revogue as credenciais correspondentes
• Planeje como desativar o conector e preservar evidências sem depender do próprio fornecedor afetado

Sem rastreabilidade, não existe investigação confiável

Registrar apenas a conversa não basta. Uma investigação precisa reconstruir qual versão do agente estava ativa, quem iniciou a sessão, qual identidade foi usada, quais fontes entraram no contexto, que ferramenta foi solicitada, quais parâmetros foram normalizados, qual política decidiu, quem aprovou e qual foi o resultado. O log deve preservar correlação e integridade sem guardar tokens ou dados sensíveis desnecessários.

• Identificador de sessão, usuário, agente, modelo, prompt de sistema e versão da política
• Fonte e classificação dos dados recuperados, com conteúdo sensível mascarado
• Ferramenta, alvo, parâmetros normalizados, decisão de autorização e identificador da aprovação
• Resultado, erro, latência, quantidade de tentativas e acionamento de limites ou circuit breaker
• Alertas para ferramenta incomum, negações repetidas, aumento de privilégio e volume fora do padrão esperado

Critérios práticos para uma POC segura

Uma POC serve para reduzir incerteza, não para herdar silenciosamente controles de produção. Ela pode operar com dados sintéticos, ambiente isolado e escopo estreito. Antes de conectar dados reais ou liberar usuários, definimos critérios verificáveis de entrada e saída. A própria OWASP recomenda testes estruturados antes da produção e depois de mudanças relevantes em prompts, ferramentas, memória, recuperação, políticas ou fornecedor do modelo.

• Caso de uso, usuários, dados, ferramentas e ações permitidas estão documentados
• Dados sintéticos ou minimizados substituem informação sensível sempre que possível
• Cada credencial é dedicada, curta, revogável e restrita ao recurso necessário
• Saídas estruturadas falham fechadas quando não passam no schema ou na autorização
• Ações de alto impacto exigem aprovação vinculada ao alvo e aos parâmetros exatos
• Prompt injection direta e indireta, abuso de ferramenta, escalada de privilégio, exfiltração e envenenamento de memória têm casos de teste repetíveis
• Limites interrompem loops, repetição, consumo e cadeias de ferramentas fora do esperado
• Logs permitem reconstruir a decisão sem expor segredos
• Existe responsável por interromper a POC, revogar acessos e tratar incidentes

O pentest começa nas fronteiras, não no prompt

Avaliar apenas se o modelo recusa um jailbreak deixa a maior parte da superfície sem teste. Um pentest de agente precisa atravessar a aplicação, as APIs, o mecanismo de autorização, a memória, as ferramentas e os serviços de terceiros. Testamos se uma entrada controlada consegue mudar a decisão e, principalmente, se os controles fora do modelo impedem que essa decisão vire acesso, alteração ou saída de dado indevida.

Para uma empresa decidindo se a POC pode avançar, a pergunta útil não é se o agente parece inteligente. É se o sistema continua seguro quando o modelo erra, é manipulado ou recebe uma resposta malformada. Esse é o ponto em que uma revisão de arquitetura e um pentest orientado a abuso produzem evidência para a decisão de produção. Referências técnicas consultadas: OWASP Top 10 for LLM Applications 2025, OWASP AI Agent Security Cheat Sheet e NIST AI 600-1.