Zero Trust para Agentes de IA: Como Conceder Acesso Seguro a Ferramentas, Dados e Ações para LLMs

Os agentes de IA evoluíram além dos chatbots, agora capazes de ler documentos, chamar APIs, analisar logs e executar tarefas complexas. Essa autonomia aumenta a utilidade, mas também redefine o risco, tornando a segurança desses agentes uma prioridade.

A ideia central do Zero Trust para esses sistemas é simples: um agente não deve ser confiável por padrão, mesmo que opere dentro da empresa ou em nome de um usuário legítimo. Sua identificação, permissões, chamadas de ferramentas, memória e ações devem ser verificadas, assumindo que uma eventual comprometimento é inevitável. Este artigo, inspirado em um PDF da Anthropic, explora os princípios do Zero Trust aplicáveis a qualquer agente de LLM, desde assistentes jurídicos e agentes de SOC até sistemas RAG e assistentes internos.

O que são Agentes de IA e Zero Trust?

Um agente de IA é um sistema LLM que recebe um objetivo, planeja etapas e chama ferramentas externas, como sistemas de arquivos, navegadores, bancos de dados, APIs corporativas, e-mails, SIEMs, CRMs, ERPs ou sistemas de tickets. Diferente de um chatbot que gera respostas, um agente pode alterar o estado de sistemas externos. Exemplos de uso incluem análise jurídica, automação de operações, e cibersegurança, como triagem de alertas e preparação de relatórios de incidentes.

Zero Trust é uma abordagem arquitetural que não confia automaticamente em redes, usuários, serviços ou agentes. A NIST SP 800-207 descreve o Zero Trust como uma mudança de um perímetro de rede estático para uma verificação contínua de usuários, dispositivos, aplicativos, dados e recursos. Para agentes de IA, isso é crucial devido à sua autonomia e capacidade de interagir com ferramentas externas. Um agente deve ter uma identidade separada, permissões limitadas e rastreamento completo de ações.

Por que Agentes Exigem um Modelo de Segurança Separado?

Aplicativos tradicionais executam lógica predefinida, enquanto agentes interpretam objetivos, selecionam ferramentas e podem manter o contexto entre sessões. Isso torna as ACLs tradicionais e contas de serviço compartilhadas inadequadas para rastreabilidade. Um agente deve ser tratado como um participante independente do sistema, com sua própria identificação, credenciais, políticas de acesso e telemetria.

Principais Ataques a Sistemas de Agentes

• Prompt Injection: Ataques diretos através de entrada do usuário ou indiretos, com instruções maliciosas em documentos ou páginas web, levando o agente a executar comandos indesejados.
• Tool Poisoning: Alteração de descrições, esquemas ou metadados de ferramentas, levando o agente a usar ferramentas comprometidas, resultando em vazamento de dados ou ações maliciosas.
• Tool Chaining: Combinação de ações individuais permitidas em uma sequência perigosa, como ler dados do CRM e enviá-los por e-mail.
• Privilege Abuse: Delegação de tarefas a agentes com mais privilégios do que o necessário, ou um agente de baixa permissão enviando instruções a um agente de alta permissão.
• Memory e RAG Poisoning: Inserção de instruções maliciosas na memória de longo prazo, contexto ou sistemas RAG, levando o agente a usar dados contaminados em sessões futuras.
• Supply Chain: Ataques através de modelos, conjuntos de dados, servidores MCP, bibliotecas de código aberto, imagens Docker, plugins e outras dependências do agente.

Teste de Design: Ataque Impossível ou Apenas Inconveniente?

Filtros de segurança devem tornar os ataques impossíveis ou extremamente difíceis, em vez de apenas demorados. Barreiras mais robustas incluem:

• Tokens de curta duração em vez de chaves de API estáticas.
• Identidade criptograficamente verificável em vez de nomes de agentes em texto simples.
• Deny-by-default em vez de acesso amplo com proibições subsequentes.
• Credenciais vinculadas ao hardware para cargas de trabalho sensíveis.
• Ausência de caminho de rede em vez de um caminho "difícil de acessar".
• Permissões separadas para cada ferramenta em vez de uma conta de serviço compartilhada.

Baseline Mínimo de um Agente Seguro

• Identificação Única: Cada agente deve ter um identificador próprio, vinculado a material criptográfico.
• Credenciais de Curta Duração: Use tokens de um provedor de identidade com tempo de vida limitado e renovação automática.
• Negação por Padrão e Princípio do Menor Privilégio: Permissões mínimas e acesso restrito.
• Isolamento do Ambiente de Execução: Sandbox, contêineres, microVMs ou outros ambientes restritos.
• Log de Chamadas de Ferramentas: Registrar quem chamou a ferramenta, com quais parâmetros, qual identificador, qual resultado e se houve aprovação humana.
• Reversão de Configurações: Prompts, lista de ferramentas permitidas e configurações do agente devem ser versionadas.

Ferramentas, Dados, Memória e Observabilidade

• Ferramentas: Use uma allowlist específica para cada função, valide os parâmetros das chamadas de ferramentas e implemente a aprovação humana para ações de alto risco.
• Memória: Isole a memória entre usuários, especifique a fonte de cada elemento, use TTLs para contexto temporário e faça verificações de integridade. Em sistemas RAG, separe o contexto confiável do não confiável.
• Observabilidade: Inclua ID de solicitação, identificador do agente e do usuário, logs de ferramentas, rastreamentos para processos multi-agente, registros de aprovações humanas e um log de segurança imutável. Monitore o tempo de detecção e a cobertura das investigações.

Como Implementar em Etapas

1. Descreva o caso de uso.
2. Atribua uma identidade separada e remova contas de serviço compartilhadas.
3. Crie uma allowlist de ferramentas e use deny-by-default.
4. Divida as permissões.
5. Isole o tempo de execução.
6. Configure a telemetria.
7. Proteja a memória e o RAG.
8. Verifique a cadeia de suprimentos.
9. Realize testes de mesa.
10. Meça a velocidade de detecção.

Agentes de Defesa e SOAR Agentic

Agentes de defesa podem enriquecer alertas, coletar evidências e preparar rascunhos de conclusões. Comece com triagem read-only antes da fila de alertas. A automação deve focar na coleta de dados, correlação e preparação de artefatos de investigação, deixando decisões para humanos.

Lista de Verificação Final

Zero Trust para agentes de IA é sobre design: cada ação é verificada, as permissões são limitadas, cada ferramenta tem limites de execução e as investigações podem ser conduzidas com base em fatos. Se um agente não puder causar grandes danos, mesmo após uma injeção de prompt, envenenamento de contexto ou vazamento de um token, você está no caminho certo. Se a segurança depende da esperança de que o modelo "entenda corretamente", o agente recebeu muita confiança.