Saltar para o conteúdo principal
Quando um agente chama uma ferramenta, os argumentos que ele passa são tão arriscados quanto o prompt que os produziu — uma chave sk-… largada num campo command, um SSN de cliente colado num body, um token interno num header de requisição. O veredito sanitize do firewall captura esse material nos argumentos da chamada de ferramenta, substitui-o por um token de redação tipado e encaminha a chamada limpa — então a ação ainda roda, mas o segredo nunca sai do gateway.
“Sanitize tool output” significa os argumentos da chamada, não o resultado da ferramenta. As pessoas buscam por sanitize tool output esperando que o firewall limpe o que uma ferramenta retorna. O veredito sanitize não toca nos resultados de ferramenta — ele redige os argumentos que seu agente envia para uma chamada de ferramenta. Se você precisa filtrar o texto que uma ferramenta ou modelo retorna, esse é um trabalho de stage de saída dos Guardrails, não uma regra de sanitize do firewall.
Este é um veredito na linguagem de correspondência do firewall. Para o conjunto completo veja Vereditos e a referência de regras; esta página é o guia focado em criar e raciocinar sobre o sanitize.

​
1. O que o sanitize faz — e o que ele nunca toca

Uma regra com verdict: sanitize roda um motor de redação sobre os argumentos da chamada de ferramenta antes de a chamada ser despachada. Cada correspondência é substituída por um token canônico e a chamada prossegue com os argumentos limpos — a ferramenta ainda executa, apenas sem o segredo cru nela.

Redige

Os argumentos JSON de um tool_call emitido pelo modelo ou um tools/call MCP — command, body, headers, qualquer campo string onde um segredo ou PII aterrissou.

Nunca redige

O conteúdo que uma ferramenta retorna, o prompt, o texto de resposta do modelo. O sanitize é um redator apenas-de-argumentos. A filtragem de texto é uma preocupação de Guardrail.
O redator substitui cada correspondência por um token tipado: uma correspondência de preset vira [redacted:<preset>] (ex.: [redacted:openai_key]), e uma correspondência de padrão customizado vira [redacted:custom]. A forma do argumento é preservada — apenas a substring sensível muda — então uma ferramenta que espera JSON válido ainda recebe JSON válido.

​
2. Os presets de detector embutidos

Uma regra de sanitize nomeia um ou mais presets (formas conhecidas de segredo/PII) e/ou padrões custom de regex. Os presets embutidos:
PresetCaptura
aws_access_keyAWS access key id (AKIA… / ASIA… + 16 chars)
aws_secret_keyUm secret AWS de 40 chars (boundary-aware)
openai_keysk- + ≥32 chars
anthropic_keysk-ant- + ≥40 chars
bearer_tokenBearer + um token de ≥16 chars (keyword mantida)
emailUm endereço de email
ssn_usUm SSN dos EUA na forma 3-2-4
credit_cardUma sequência de 13–19 dígitos que passa uma verificação Luhn
Uma regra de sanitize deve declarar ao menos um preset ou padrão custom — um sanitizer vazio é rejeitado quando você salva a regra. Uma correspondência credit_card é adicionalmente verificada por Luhn, então um número de mesmo comprimento que não é um cartão válido fica intocado em vez de super-redigido.

​
3. Um exemplo concreto

Crie isto no editor de regras do console. O exemplo redige uma chave OpenAI e qualquer email dos argumentos de qualquer chamada de ferramenta http.* que seu agente emite, depois encaminha a chamada limpa: 
{
  "label": "strip secrets from http tool args",
  "stage": "response",
  "tool_name_glob": "http.*",
  "verdict": "sanitize",
  "sanitize_json": "{\"presets\":[\"openai_key\",\"email\"],\"custom\":[]}"
}
Se o modelo emite uma chamada como: 
{ "name": "http.post", "arguments": { "url": "…", "body": "key=sk-AAAA…BBBB user=jo@acme.com" } }
o gateway a encaminha com o body reescrito para key=[redacted:openai_key] user=[redacted:email] — a requisição ainda roda, o segredo e o endereço nunca saem do gateway.
Fixe a regra ao stage response (tool_calls emitidos pelo modelo) ou deixe o stage vazio para também cobrir a superfície mcp. Essas são as superfícies que carregam argumentos em tempo de chamada, que é o que o sanitize redige.

​
4. Na superfície inbound, o sanitize escala para deny

A superfície inbound avalia as ferramentas que um agente anuncia numa requisição — definições de ferramenta, que ainda não carregam argumentos em tempo de chamada. Não há nada para redigir ali, então um veredito sanitize na superfície inbound escala para um deny (fail-closed): a requisição é bloqueada com firewall_blocked em vez de encaminhada sem redação.
Não crie uma regra de sanitize esperando que ela limpe um anúncio de ferramenta inbound — ela vai bloqueá-lo. Se você quer uma definição de ferramenta fora da requisição, use um deny explícito. Reserve o sanitize para as superfícies response e mcp, onde argumentos reais existem.

​
5. Sanitize vs. as outras maneiras de lidar com um segredo

Três camadas podem agir sobre um segredo que um agente está prestes a vazar — escolha por o quê e onde:
Remove o segredo dos argumentos de uma chamada de ferramenta e ainda roda a chamada. Use-o quando a ação é legítima mas o agente colocou algo sensível num campo. Apenas na camada de argumento.
Para a chamada inteiramente. Use-o quando a ação em si é perigosa, não apenas um argumento. Isso é também o que o sanitize se torna na superfície inbound. Veja bloquear ferramentas.
Os guardrails Secrets Blocker e PII filtram o texto de uma requisição ou resposta (incluindo, no stage de saída, conteúdo gerado pelo modelo). Essa é a camada para “o que uma ferramenta ou modelo retorna” — a coisa que o sanitize não faz.
Teste antes de aplicar. O sanitize reescreve os argumentos de uma chamada ao vivo nas superfícies response e mcp. Crie suas regras de sanitize sob shadow mode primeiro e observe o feed de events para confirmar que elas correspondem ao que você espera antes que qualquer argumento seja de fato reescrito.

​
6. Onde o sanitize aparece no seu rastro

Como cada veredito, uma avaliação de sanitize é registrada como um evento de firewall — filtrável por veredito, superfície, ferramenta e run no log de events e consolidada em analytics. No shadow mode um veredito de sanitize (como cada veredito de enforcement) é rebaixado para audit e o motivo recebe o prefixo [shadow] would …, então você pode medir o impacto antes que qualquer argumento seja de fato reescrito.

​
Para onde ir a seguir

Todos os vereditos

allow, audit, deny, sanitize, pending_approval, cap_cost.

Validar argumentos

Corresponda a uma chamada pelo que está em seus argumentos — a gramática de cláusula JSONPath.

Bloquear ferramentas

Quando a ação em si é o problema, negue a chamada inteira.

Firewall + Guardrails

Filtre o texto que uma ferramenta ou modelo retorna — a camada que o sanitize não cobre.
Para as ameaças que o sanitize ajuda a conter, veja exfiltração de dados e chamadas de ferramenta perigosas. Para a gramática de regras completa por trás do veredito, veja a referência de regras do firewall.