Saltar al contenido principal
Cuando un agente llama a una herramienta, los argumentos que pasa son tan arriesgados como el prompt que los produjo — una clave sk-… soltada en un campo command, el SSN de un cliente pegado en un body, un token interno en una cabecera de solicitud. El veredicto sanitize del firewall captura ese material en los argumentos de la llamada a herramienta, lo reemplaza con un token de redacción tipado y reenvía la llamada limpia — así que la acción aún se ejecuta, pero el secreto nunca sale del gateway.
“Sanear la salida de herramienta” significa los argumentos de la llamada, no el resultado de la herramienta. La gente busca sanitize tool output esperando que el firewall limpie lo que una herramienta devuelve. El veredicto sanitize no toca los resultados de herramienta — redacta los argumentos que tu agente envía a una llamada a herramienta. Si necesitas examinar el texto que una herramienta o modelo devuelve, ese es un trabajo de etapa de salida de los Guardrails, no una regla de sanitize del firewall.
Este es un veredicto en el lenguaje de coincidencia del firewall. Para el conjunto completo ver Veredictos y la referencia de reglas; esta página es la guía enfocada a autorar y razonar sobre sanitize.

​
1. Qué hace sanitize — y qué nunca toca

Una regla con verdict: sanitize ejecuta un motor de redacción sobre los argumentos de la llamada a herramienta antes de que la llamada se despache. Cada coincidencia se reemplaza con un token canónico y la llamada procede con los argumentos limpios — la herramienta aún se ejecuta, solo sin el secreto en bruto en ella.

Redacta

Los argumentos JSON de un tool_call emitido por el modelo o un tools/call MCP — command, body, headers, cualquier campo string donde aterrizó un secreto o PII.

Nunca redacta

El contenido que una herramienta devuelve, el prompt, el texto de respuesta del modelo. Sanitize es un redactor solo de argumentos. El examen de texto es asunto de un Guardrail.
El redactor reemplaza cada coincidencia con un token tipado: una coincidencia de preset se convierte en [redacted:<preset>] (p. ej. [redacted:openai_key]), y una coincidencia de patrón personalizado se convierte en [redacted:custom]. La forma del argumento se preserva — solo la subcadena sensible cambia — así que una herramienta que espera JSON válido aún recibe JSON válido.

​
2. Los presets de detector integrados

Una regla de sanitize nombra uno o más presets (formas conocidas de secreto/PII) y/o patrones custom de regex. Los presets integrados:
PresetCaptura
aws_access_keyId de clave de acceso de AWS (AKIA… / ASIA… + 16 caracteres)
aws_secret_keyUn secreto AWS de 40 caracteres (consciente de fronteras)
openai_keysk- + ≥32 caracteres
anthropic_keysk-ant- + ≥40 caracteres
bearer_tokenBearer + un token de ≥16 caracteres (palabra clave conservada)
emailUna dirección de correo electrónico
ssn_usUn SSN de EE. UU. en forma 3-2-4
credit_cardUna serie de 13–19 dígitos que pasa una verificación de Luhn
Una regla de sanitize debe declarar al menos un preset o patrón personalizado — un saneador vacío se rechaza cuando guardas la regla. Una coincidencia de credit_card se verifica adicionalmente con Luhn, así que un número de la misma longitud que no es una tarjeta válida se deja intacto en vez de sobre-redactado.

​
3. Un ejemplo concreto

Autora esto en el editor de reglas de la consola. El ejemplo redacta una clave de OpenAI y cualquier correo electrónico de los argumentos de cualquier llamada a herramienta http.* que tu agente emite, luego reenvía la llamada limpia: 
{
  "label": "strip secrets from http tool args",
  "stage": "response",
  "tool_name_glob": "http.*",
  "verdict": "sanitize",
  "sanitize_json": "{\"presets\":[\"openai_key\",\"email\"],\"custom\":[]}"
}
Si el modelo emite una llamada como: 
{ "name": "http.post", "arguments": { "url": "…", "body": "key=sk-AAAA…BBBB user=jo@acme.com" } }
el gateway la reenvía con el body reescrito a key=[redacted:openai_key] user=[redacted:email] — la solicitud aún se ejecuta, el secreto y la dirección nunca salen del gateway.
Fija la regla a la etapa response (tool_calls emitidos por el modelo) o deja la etapa vacía para cubrir también la superficie mcp. Esas son las superficies que llevan argumentos en tiempo de llamada, que es lo que sanitize redacta.

​
4. En la superficie inbound, sanitize escala a deny

La superficie inbound evalúa las herramientas que un agente anuncia en una solicitud — definiciones de herramienta, que llevan aún ningún argumento en tiempo de llamada. No hay nada que redactar ahí, así que un veredicto sanitize en la superficie inbound escala a un deny (falla cerrado): la solicitud se bloquea con firewall_blocked en vez de reenviarse sin redactar.
No autores una regla de sanitize esperando que limpie un anuncio de herramienta inbound — lo bloqueará. Si quieres que una definición de herramienta desaparezca de la solicitud, usa un deny explícito. Reserva sanitize para las superficies response y mcp, donde existen argumentos reales.

​
5. Sanitize vs. las otras formas de manejar un secreto

Tres capas pueden actuar sobre un secreto que un agente está a punto de filtrar — elige por qué y dónde:
Quita el secreto de los argumentos de una llamada a herramienta y aún ejecuta la llamada. Úsalo cuando la acción es legítima pero el agente puso algo sensible en un campo. Solo capa de argumentos.
Detiene la llamada por completo. Úsalo cuando la acción en sí es peligrosa, no solo un argumento. Esto también es en lo que sanitize se convierte en la superficie inbound. Ver bloquear herramientas.
Los guardrails de Secrets Blocker y PII examinan el texto de una solicitud o respuesta (incluido, en la etapa de salida, el contenido generado por el modelo). Esa es la capa para “lo que una herramienta o modelo devuelve” — lo que sanitize no hace.
Prueba antes de aplicar. Sanitize reescribe los argumentos de una llamada en vivo en las superficies response y mcp. Autora tus reglas de sanitize bajo modo shadow primero y observa el feed de eventos para confirmar que coinciden con lo que esperas antes de que un argumento sea realmente reescrito.

​
6. Dónde aparece sanitize en tu rastro

Como cada veredicto, una evaluación de sanitize se registra como un evento del firewall — filtrable por veredicto, superficie, herramienta y ejecución en el registro de eventos y agregado en analítica. En modo shadow un veredicto sanitize (como cada veredicto de aplicación) se degrada a audit y la razón se prefija con [shadow] would …, así que puedes medir el impacto antes de que un argumento sea realmente reescrito.

​
Dónde ir a continuación

Todos los veredictos

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

Validar argumentos

Coincide una llamada por lo que está en sus argumentos — la gramática de cláusulas JSONPath.

Bloquear herramientas

Cuando la acción en sí es el problema, deniega toda la llamada.

Firewall + Guardrails

Examina el texto que una herramienta o modelo devuelve — la capa que sanitize no cubre.
Para las amenazas que sanitize ayuda a contener, ver exfiltración de datos y llamadas a herramienta peligrosas. Para la gramática de reglas completa detrás del veredicto, ver la referencia de reglas del firewall.