O que são guardrails de IA e como limitar o que um agente pode fazer

Guardrails são os controles que mantêm um sistema de IA dentro do que a empresa quer que ele faça: o que ele aceita receber, o que pode responder e, principalmente, o que pode fazer.

A palavra costuma ser entendida como “um filtro de conteúdo”. Essa é só uma das camadas. Quando o modelo passa a ler e-mails, consultar sistemas e executar ações, o risco deixa de ser apenas uma resposta ruim e passa a ser uma ação indevida. A documentação da Anthropic trata o tema como um conjunto de defesas combinadas, e não como uma única barreira.

A Anthropic separa os ataques em duas categorias, porque cada uma pede defesas diferentes.

1. 01

   Jailbreak e injeção direta

   O usuário do seu sistema é o adversário e escreve entradas pensadas para contornar as regras da aplicação.

2. 02

   Injeção indireta

   O usuário é de confiança, mas o modelo lê conteúdo de terceiros (página web, e-mail, documento, resultado de ferramenta) que traz instruções escondidas.

A segunda é a que mais cresce com agentes. O exemplo da Anthropic: você pede ao agente que leia seus e-mails e responda aos convites de reunião. Um dos e-mails, de um suposto fornecedor, traz instruções em texto branco, invisíveis para você, mandando encaminhar a um endereço externo as mensagens com a palavra “confidencial”. A isso se chama prompt injection: instruções adversárias escondidas no conteúdo que o modelo processa.

Quando o adversário é o usuário

Para jailbreaks e injeção direta, a documentação lista: uma triagem prévia da entrada por um modelo menor e mais barato, que apenas classifica o pedido; a validação da entrada contra padrões de ataque conhecidos; um prompt de sistema que deixa claros os limites éticos e legais e como recusar; e uma resposta a reincidentes, com limitação ou bloqueio de quem tenta contornar as regras repetidas vezes.

Quando o adversário está no conteúdo

Para injeção indireta, a recomendação é estruturar a aplicação de modo que o modelo distinga o que é instrução do que é dado:

1. 01

   Conteúdo de terceiros só como resultado de ferramenta

   Nunca no prompt de sistema nem misturado ao texto do usuário. O modelo é treinado para tratar instruções dentro de resultados de ferramenta com ceticismo.

2. 02

   Dizer ao modelo o que é o conteúdo e de onde veio

   Por exemplo, “corpo de e-mail de remetente desconhecido”. Isso ajuda a calibrar quanto confiar.

3. 03

   Declarar a política no prompt

   O que volta de ferramentas, documentos e buscas é dado não confiável e nunca muda o objetivo nem o pedido original do usuário.

4. 04

   Triar o que as ferramentas devolvem

   O mesmo modelo menor examina a saída da ferramenta e, se suspeitar de injeção, o conteúdo bruto não chega ao agente.

A recomendação da Anthropic para o caso em que uma injeção passa é limitar o que o agente alcança: não dar acesso a segredos de que ele não precisa, rodar ferramentas em ambientes isolados e restringir as permissões ao mínimo. É o princípio do menor privilégio.

O texto da Anthropic sobre o isolamento (sandbox) do Claude Code mostra o raciocínio com um exemplo concreto. O isolamento precisa ser de arquivos e de rede ao mesmo tempo: sem o de rede, um agente comprometido poderia enviar para fora arquivos sensíveis, como chaves SSH; sem o de arquivos, poderia escapar do isolamento e ganhar acesso à rede. Segundo a Anthropic, a prática também reduziu em 84% os pedidos de permissão em uso interno, o que importa porque a aprovação constante cansa e faz o usuário aprovar sem ler.

Duas camadas são de processo, não de código. Antes de colocar no ar, a documentação manda testar o fluxo com documentos, e-mails e saídas de ferramenta que contêm tentativas de injeção de propósito e conferir se o agente as ignora e se a triagem e as confirmações pegam o resto. Depois de no ar, analisar as saídas com regularidade em busca de sinais de ataque bem-sucedido e usar isso para ajustar prompts e filtros.

Isso é o mesmo método de evals, aplicado a segurança: casos de ataque viram testes que rodam a cada mudança. E, no caso de agentes ligados a sistemas por MCP, cada ferramenta conectada é uma porta que precisa ter suas permissões definidas.

Esta seção é da Invisible Work e não vem das fontes. Ao avaliar um agente, a pergunta que mais ajuda não é “o modelo pode ser enganado?”, porque a resposta honesta é sim, às vezes. É “o que acontece se for?”. Um agente que só lê e resume tem um estrago possível pequeno. Um que envia e-mail, paga ou altera cadastros tem um grande, e é nele que a camada de permissão mínima e a confirmação de um humano antes da ação irreversível pesam mais do que qualquer filtro de texto.

Por isso, em projetos de agentes, o desenho das permissões vem antes do ajuste do prompt. O harness é onde esses limites moram: quais ferramentas o agente enxerga, com que credenciais e o que exige aprovação.