Guardrails para agentes: onde travar antes de ele agir

De 52 falhas de segurança documentadas em agentes de IA, 40 seriam totalmente evitáveis por camadas do harness. Três quartos.

Nenhuma delas precisava de um modelo melhor. Precisava de uma trava que já sabemos construir e que quase ninguém constrói.

O mesmo levantamento traz o motivo provável: pesquisa sobre alinhamento em tempo de treino supera pesquisa sobre harness em tempo de execução por 8 a 12 vezes. A camada mais barata do sistema é a menos estudada.

Este post trata de onde colocar a trava, e de por que a recomendação mais comum — um classificador que avalia se a ação parece perigosa — resolve menos do que promete.

Um guardrail é um controle que limita o que o agente consegue fazer, e que funciona sem depender de o modelo concordar. Essa última parte é a definição inteira: instrução no prompt cobre o caso em que o modelo obedece; guardrail cobre o resto.

Os controles se dividem em duas famílias.

Preventivos agem antes da execução: lista de ferramentas disponíveis, sanitização de entrada, portões de permissão, classificadores de injeção. Detectivos agem durante ou depois: rastreamento de execução, detecção de anomalia, perfil de comportamento, classificação de saída.

Na prática, existem quatro pontos onde a trava pode entrar:

1. Antes da chamada, decidindo se aquela ferramenta sequer aparece para o agente.
2. Na fronteira da ferramenta, validando parâmetro e efeito antes de executar.
3. Na saída, filtrando o que volta para o contexto ou para o usuário.
4. No portão de entrega, recusando o "pronto" sem prova de que ficou pronto.

O quarto é o mais raro e o mais barato, e volto a ele adiante. Os quatro juntos formam a camada de guardrails do harness.

<!-- [UNIQUE INSIGHT] -->

Aqui está a distinção que muda o desenho da camada, e ela vem de um trabalho de 11 de agosto de 2026: "Agent Safety Should Be a Runtime Contract", de Albus W. Ng, Yi Han, Jusheng Zhang e Wenhao Wang (arXiv 2608.11274, acesso em 27/08/2026).

Os autores separam duas famílias de mecanismo:

Mecanismo por classificador avalia propriedade semântica. Ele lê o comando, o contexto em volta, e decide se aquilo parece perigoso. Como depende de discriminação aprendida, herda a mesma fragilidade do alinhamento do modelo.

Mecanismo estrutural impõe invariante independentemente do comportamento do modelo. Sandbox, cota de recurso, menor privilégio por padrão. Não depende de acurácia de classificação, porque não classifica nada.

A consequência é prática. Um classificador precisa julgar se rm -rf build/ é aceitável, e a resposta depende do que veio antes na conversa. Uma trava estrutural não julga: ela sabe que a exclusão recursiva não tem desfazer, e trata todas igual.

O cluster já mostrou essa mesma linha falhar do outro lado. No post sobre por que prompt injection não tem correção definitiva, doze defesas publicadas — várias delas classificadores — foram contornadas acima de 90% por atacantes adaptativos. O mecanismo é o mesmo aqui: o que se decide por interpretação pode ser argumentado.

Vale ser justo com o classificador, porque ele tem lugar. Ele reduz volume de tentativa trivial, impõe custo ao atacante e gera registro do que foi barrado. O que ele não entrega é garantia. Guardrail de conteúdo e guardrail de execução resolvem problemas diferentes, e confundir os dois é o erro que este post tenta desfazer.

Há um detalhe do desenho da categoria que reforça isso. As seis famílias de falha que os guardrails de conteúdo costumam cobrir são detecção de jailbreak e injeção, vazamento de dado pessoal, toxicidade, política de tópico, alucinação e validação de formato. Cinco são semânticas. Só a validação de formato é puramente mecânica.

Toda trava cobra pedágio de quem está trabalhando direito, e esse custo raramente entra na conta.

Em abril de 2026, um grupo da Beijing Caizhi Tech avaliou quatro guardrails comerciais contra 1.018 entradas reanotadas por humanos, amostradas de oito conjuntos públicos (arXiv 2604.24826, acesso em 27/08/2026).

A conclusão dos próprios autores: mesmo o guardrail com melhor desempenho ainda bloqueia por engano cerca de 10% do tráfego benigno.

O dano do falso positivo não para no atrito. Ele treina a pessoa. Guardrail que interrompe demais faz o operador aprovar sem ler, e aí a trava virou teatro — que é o risco ASI09 da lista da OWASP, a exploração da confiança entre humano e agente.

Daí o julgamento explícito deste post: trava sem medição de falso positivo é dívida. Antes de escolher um guardrail comercial, pegue tráfego real do seu agente, passe pelas opções que está considerando e conte o que foi barrado sem motivo. A tabela acima serve para orientar a lista curta, e não para substituir esse teste.

Quase todo material sobre o tema termina nas mesmas duas frases. As duas têm modo de falha documentado.

Lista branca de comandos

A ideia é intuitiva: o agente só executa o que está na lista. O problema é que a lista aprova o nome do comando, e o efeito depende do ambiente em que ele roda.

O CVE-2026-22708, no Cursor, mostrou isso em produção. Em modo automático com lista branca ativa, comandos embutidos do shell como export e declare rodavam sem constar na lista, porque o avaliador confiava neles. Bastava um texto qualquer que chegasse ao agente para mudar variáveis de ambiente em silêncio, e o comando aprovado passava a executar outra coisa. Contei o caso inteiro no post sobre os dez riscos da OWASP.

O que fazer no lugar: ambiente descartável. Num contêiner sem credencial e sem rede, o efeito de qualquer comando fica contido, independentemente de o nome dele estar numa lista. E tirar a ferramenta do alcance resolve mais do que descrevê-la como perigosa.

Aprovação humana para tudo que é sensível

Funciona até a vigésima aprovação idêntica. Depois disso, o operador aprova sem ler, e o dado do falso positivo explica por quê: uma trava que interrompe com frequência é uma trava que ensina a ignorar.

O que fazer no lugar: pedir menos vezes e mostrar mais quando pedir. Aprovação que exibe o comando exato, o que ele altera e se dá para desfazer vale por dez confirmações genéricas. Para quem usa Claude Code, permissões e auto mode trata da configuração dessa fronteira.

Substitua "isso parece perigoso?" por três perguntas que têm resposta objetiva.

Dá para desfazer? É o critério dominante. Ação reversível pode errar.

Qual o alcance? Fica na máquina, atinge o repositório, ou sai para o mundo e chega em outras pessoas?

Custa dinheiro? Chamada paga, recurso provisionado, cota consumida.

A regra que sai da tabela é curta: o que não dá para desfazer não é opção do agente. Não é uma instrução pedindo cuidado, nem uma confirmação que ele possa interpretar. É ausência da ferramenta, ou aprovação humana obrigatória.

Repare que a coluna da reversibilidade não pergunta nada sobre intenção. É por isso que ela funciona: não há como argumentar com um --force.

Uma nota sobre a linha da cota. Limite de gasto é guardrail estrutural, e quase ninguém configura. O laço que repete uma chamada barata é o padrão que mais surpreende na fatura, pelo mecanismo descrito em quanto custa cada padrão de uso.

As três travas estruturais mais baratas

Sandbox soa caro. Na versão mínima, não é. As três travas abaixo cabem numa tarde e cobrem a maior parte do estrago possível.

1. Contêiner sem credencial. O agente roda dentro de um contêiner. O repositório entra montado; o resto do disco não existe para ele. Variáveis de ambiente com segredo ficam de fora. O ganho é grande e imediato: rm -rf continua possível e deixa de importar, porque o que ele apaga é descartável.

2. Credencial de escopo mínimo e vida curta. O agente ganha conta própria, com acesso apenas ao que a tarefa precisa. Token que expira em horas vale mais que token permanente com escopo amplo. Esta é a trava que teria evitado o caso do Vertex AI, em que uma conta de serviço com privilégio excessivo permitiu roubo de credencial.

3. Teto de gasto. Um limite duro na conta da API, configurado no provedor e não no código. Custa cinco minutos. É a única trava desta lista que protege contra um erro seu, e não contra um ataque: o laço que repete uma chamada barata não tem má intenção.

Nenhuma das três depende do modelo entender nada. É esse o ponto delas.

Se você só puder fazer uma, faça a terceira. É a mais rápida e a que evita o prejuízo mais comum.

O controle mais barato desta lista é também o mais raro. Dos 12 sistemas públicos de agente auditados no trabalho de agosto, apenas 2 exigem prova de que a ação segura aconteceu antes de aceitar a entrega.

A ideia é direta: o agente não declara que terminou. Ele apresenta evidência de que terminou, e o portão confere.

Numa auditoria de 32 casos de falsa conclusão, o que teria resolvido eram gates de evidência de quatro tipos: execução de teste, captura de log, diff de arquivo e citação da fonte.

A diferença em relação à camada anterior é sutil e importante. O loop de verificação roda o teste. O gate de evidência se recusa a aceitar a entrega sem o resultado do teste anexado. Um produz o sinal; o outro torna o sinal obrigatório.

Sem o gate, o agente que pulou a verificação e o agente que passou nela entregam a mesma frase: "pronto". Com o gate, um dos dois não consegue entregar.

Na prática, isso costuma ser mais simples do que parece. O portão exige que a entrega inclua a saída do comando de verificação, com o código de retorno. Nada de resumo, nada de "os testes passaram" escrito em prosa. A saída bruta, ou não passa. Quando a evidência precisa ser colada, o agente não tem como afirmar que rodou algo que não rodou.

<!-- [PERSONAL EXPERIENCE] -->

O que existe hoje na operação que publica este blog: confirmação humana para ação irreversível, nada de push sem autorização explícita, nenhuma publicação sem o checklist de dezesseis itens, e permissões declaradas por ferramenta.

O que não existe, dito com todas as letras: não há sandbox. O agente roda com acesso de escrita ao repositório inteiro, sem contêiner e sem cota de recurso.

A trava que me protege hoje é a da primeira coluna da tabela: quase tudo que ele toca está sob git, e dá para desfazer. Isso é uma escolha consciente e não uma arquitetura. Num repositório com segredo em arquivo, com deploy automático no push ou com acesso a banco de produção, esse desenho falharia — e falharia rápido.

Sobre o gate de evidência, a mudança é recente e nasceu de um prejuízo. Um bug num campo de título passou pelo tsc, pelos dezenove testes e pelo next build sem um aviso, e só apareceu quando abri o HTML gerado e contei os caracteres. Antes disso, eu aceitava "pronto" acompanhado de "build passou". Agora a entrega precisa vir com o número de caracteres do título renderizado. É um gate de evidência com outro nome, e ele existe porque eu já tinha sido enganado por uma entrega que passou em tudo.

Guardrail é a camada mais fácil de fingir. Ela existe no diagrama, ninguém testa, e todo mundo assume que está protegido. Quatro números resolvem isso.

Bloqueios revertidos à mão. Toda vez que alguém contorna a trava para seguir trabalhando, isso é falso positivo com outro nome. Se o número sobe, a trava está no lugar errado. Se ninguém nunca contorna, provavelmente ela não está barrando nada.

Tempo entre o pedido de aprovação e o clique. É o indicador de fadiga, e é brutal de honesto. Aprovação concedida em dois segundos não foi lida. Quando a mediana cai, a trava virou formalidade.

Ações irreversíveis executadas sem passar por gate. Esta deveria ser zero. Medir exige registro do que foi executado, e é a pergunta que revela travas que existiam só no documento.

Entregas aceitas sem evidência anexada. Se o portão de entrega existe, esse número tende a zero sozinho. Se não existe, ele é 100% e ninguém tinha reparado.

Os dois primeiros medem atrito. Os dois últimos medem cobertura. Uma camada saudável mantém os dois primeiros baixos sem zerar, e os dois últimos em zero.

Nada disso precisa de ferramenta nova. Precisa de log, que é o assunto da próxima camada.

O que são guardrails de IA?

São controles que limitam o que um sistema de IA consegue fazer, e que funcionam sem depender de o modelo cooperar. Dividem-se em preventivos, que agem antes da execução — lista de ferramentas, portões de permissão, sandbox —, e detectivos, que agem durante ou depois, como rastreamento de execução e classificação de saída. A diferença para uma instrução no prompt é que a instrução cobre o caso em que o modelo obedece, e o guardrail cobre o resto.

Qual a diferença entre guardrail e permissão?

Permissão é uma das formas de guardrail, e trata de quem pode fazer o quê. O conceito de guardrail é mais amplo e inclui limites que não têm relação com identidade: cota de gasto, sandbox de execução, validação de formato na saída, portão de entrega que exige evidência. Na prática, permissão responde "esse agente tem direito?" e o guardrail estrutural responde "essa ação é aceitável, venha de quem vier?".

Preciso de aprovação humana para tudo?

Não, e tentar isso costuma piorar a segurança. Aprovação frequente treina o operador a aprovar sem ler, que é o risco ASI09 da lista da OWASP. O critério útil é a reversibilidade: ação que dá para desfazer não precisa de aprovação, e ação irreversível precisa sempre. Menos interrupções, com mais informação em cada uma, protege mais do que confirmar tudo.

Guardrail atrapalha o trabalho do agente?

Atrapalha, e isso é mensurável. Na avaliação de quatro guardrails comerciais publicada em abril de 2026, nenhum passou de 90,4% de tráfego legítimo aprovado, o que significa que ao menos um em cada dez pedidos benignos era barrado. Por isso a recomendação é medir falso positivo com tráfego real antes de adotar, e preferir travas estruturais, que não erram em caso ambíguo porque não interpretam nada.

Preciso de sandbox mesmo num projeto pessoal?

Depende de uma pergunta só: o que existe naquela máquina que você não conseguiria refazer? Repositório sob git, com tudo commitado e enviado, é território seguro, porque a reversibilidade já está resolvida. Chave de API em arquivo de configuração, banco local sem backup, pasta de documentos e credencial de nuvem com escopo amplo não são. Se o agente alcança qualquer um desses, o contêiner deixa de ser exagero. E o teto de gasto no provedor vale em qualquer cenário, inclusive no projeto pessoal, porque protege contra erro seu e leva cinco minutos.

Vale usar Llama Guard ou NeMo Guardrails?

Vale para o que eles resolvem, que é segurança de conteúdo: moderação, política de tópico, detecção de padrão de ataque conhecido. Nenhum dos dois substitui controle de execução, porque avaliar se um texto é aceitável e impedir que uma ação irreversível aconteça são problemas diferentes. A combinação sensata usa classificador para reduzir volume e trava estrutural para garantir o que não pode acontecer.

• 40 de 52 falhas documentadas de agentes eram totalmente evitáveis por camadas do harness. A camada mais barata é a menos construída.
• Classificador decide por probabilidade e pode ser argumentado. Trava estrutural decide por fato e vale mesmo quando o modelo discorda.
• Mesmo o melhor guardrail avaliado barra cerca de 10% do tráfego legítimo. Trava sem medição de falso positivo é dívida.
• Lista branca aprova o nome do comando, e não o efeito. Ambiente descartável aprova o efeito.
• O que não dá para desfazer não é opção do agente.
• Só 2 de 12 sistemas exigem evidência antes de aceitar a entrega. É o controle mais barato que existe.

Isso fecha as quatro camadas mais próximas da execução. O próximo post do cluster trata da quinta, que é a que responde o que realmente aconteceu: observabilidade de agente. O mapa completo está no pilar sobre harness engineering.