Saltar al contenido principal
Conectaste un servidor MCP, y ahora quieres que el gateway despoje un secreto filtrado de una llamada a herramienta antes de que llegue al servidor real — y que impida que lo que esa herramienta devuelve cuele una credencial (o una carga útil de inyección) de vuelta al modelo. Esos son dos trabajos diferentes, manejados por dos controles diferentes, y la versión honesta importa: si asumes que una perilla cubre ambos, entregarás una brecha. Esta página es la guía enfocada de sanitize mcp output en OrcaRouter — qué redacta realmente el veredicto sanitize del firewall, qué no, y qué control gobierna el contenido que una herramienta devuelve.
El veredicto sanitize redacta los argumentos de la llamada a herramienta, nunca el resultado que una herramienta devuelve. Reescribe lo que tu agente envía a una herramienta. Para gobernar lo que una herramienta devuelve, usas un guardrail de etapa de salida sobre la respuesta del modelo — ver §3.

​
1. Qué significa “sanitize” en la superficie mcp

Cuando un agente llama a una herramienta a través del gateway MCP, cada tools/call se evalúa en la superficie mcp antes del despacho. Una regla coincidente puede llevar uno de los veredictos de firewall autorables — allow, audit, deny, sanitize, pending_approval o cap_cost. El veredicto sanitize es el que redacta:
  • Ejecuta un conjunto de detectores de forma de secreto sobre los argumentos de la llamada (el JSON que el modelo pasó a la herramienta).
  • Cada coincidencia se reemplaza con un token canónico como [redacted:openai_key], y los argumentos reescritos son lo que se reenvía al servidor.
  • La herramienta igual se ejecuta — sanitize es un veredicto no bloqueante, de dejar pasar. El agente no falla; simplemente nunca le entrega el secreto en bruto a la herramienta.
Los detectores integrados cubren formas de secreto bien conocidas (claves de acceso AWS, claves API estilo sk-, tokens Bearer, SSN de EE. UU., números de tarjeta válidos por Luhn, email), y una regla puede añadir regexes personalizados cuyas coincidencias se renderizan como [redacted:custom].
En la superficie inbound — el tools[] anunciado que una solicitud declara, antes de que se llame a ninguna herramienta — no hay argumentos en tiempo de llamada que redactar, así que un veredicto sanitize ahí falla cerrado y escala a deny. Sanitize es significativo solo donde hay una carga útil de argumentos en vivo que reescribir: las superficies mcp y response.

​
2. Una regla concreta

Digamos que quieres que cualquier llamada a herramienta cuyos argumentos contengan una clave estilo OpenAI se reenvíe con la clave depurada, en vez de bloqueada. Autora una regla en la superficie mcp con un veredicto sanitize, configurada para detectar esa forma de secreto. Haz esto desde la consola (Firewall → política → reglas); la escritura requiere Developer+. La regla, conceptualmente:
CampoValor
Superficiemcp
tool_name_glob* (o acota a un servidor, p. ej. github.*)
Veredictosanitize
Presets de sanitizelos detectores de secreto a habilitar
En tiempo de llamada, una carga útil de argumentos como: 
{ "note": "use key sk-AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH for the upstream" }
se reenvía al servidor como: 
{ "note": "use key [redacted:openai_key] for the upstream" }
La llamada tiene éxito; el secreto nunca llega al servidor. El evento de firewall registra el veredicto sanitize, la superficie y la regla coincidente.
Recurre a sanitize cuando una herramienta legítimamente necesita la mayor parte de un argumento pero un secreto ocasionalmente viaja en el texto libre. Cuando toda la llamada es peligrosa, usa deny (o pending_approval) en su lugar — ver Lista de permitidos de herramientas MCP.

​
3. Los resultados de herramienta son no confiables — gobiérnalos en la respuesta del modelo

Aquí está la parte que la mayoría de las configuraciones de “sanear la salida” hacen mal. El veredicto sanitize toca solo los argumentos. El resultado de una herramienta — el texto o JSON que un servidor MCP devuelve — nunca se reescribe por un veredicto de firewall. OrcaRouter trata el contenido del resultado de herramienta como entrada no confiable al modelo. Un servidor MCP comprometido o envenenado puede devolver un secreto, un registro de PII o una carga útil de inyección de prompts disfrazada de datos. El control para ese contenido es un guardrail en la etapa output — la respuesta del modelo, evaluada después de que el modelo ha incorporado el resultado de la herramienta.
Adjunta un guardrail con el preset Secrets & API-Key Blocker (categoría secrets). Bloquea credenciales estilo AWS / OpenAI / GitHub; empárejalo con Private Keys & Cloud Tokens para claves PEM, tokens Slack/Stripe, claves Google y JWTs. Un bloqueo de etapa de salida devuelve guardrail_blocked (HTTP 400) y reembolsa la cuota de la solicitud.
El preset PII Shield enmascara entidades tipadas — [EMAIL], [SSN], [CREDIT_CARD], … — renderizando los valores coincidentes como etiquetas. El enmascaramiento de etapa de entrada está en vivo en cada solicitud (streaming o no): enmascara la solicitud antes de que el modelo la vea. El enmascaramiento de etapa de salida reescribe la respuesta del modelo solo en respuestas no streaming; la reescritura en banda de una respuesta streaming está en la hoja de ruta, así que una regla de máscara aún no redacta una respuesta en streaming.
Un resultado envenenado puede llevar texto estilo “ignora las instrucciones anteriores”. El preset de seguridad Prompt-Injection Basics (palabra clave/regex) más una regla llm_judge que puntúa la intención de inyección son los controles aquí. Ver Envenenamiento de herramientas MCP y Inyección de prompts.
Cumplimiento de salida y streaming. El bloqueo de etapa de salida se aplica tanto en respuestas streaming como no streaming — en un stream, un bloqueo corta el stream cuando coincide y emite un aviso de bloqueo genérico. El enmascaramiento de etapa de salida aplica solo a respuestas no streaming; la reescritura en banda de una respuesta streaming está en la hoja de ruta, así que una regla de máscara aún no redacta una respuesta en streaming.

​
4. Dónde vive cada control

Un mapa compacto de las dos superficies, así cableas la perilla correcta al riesgo correcto:
Quieres gobernar…ControlDónde
Secretos en los argumentos de una llamada a herramientaVeredicto sanitize del firewall (superficie mcp)Reglas del firewall
Secretos / PII / inyección en el resultado de una herramientaGuardrail en la etapa outputGuardrails
No intentes hacer que sanitize cubra los resultados de herramienta — no puede verlos. Y no asumas que un guardrail de etapa input atrapará lo que una herramienta devuelve a mitad de conversación; el contenido del resultado de herramienta se gobierna en la respuesta del modelo, que es la etapa output.

​
5. Adjuntar y observar

Ambos controles tienen alcance de espacio de trabajo, nombre y orden, y ambos se adjuntan de las mismas dos maneras:
  • Por clave — establece firewall_policy_id (para la regla de sanitize) y guardrail_id (para la política de salida) en la clave que usa el agente.
  • Valor por defecto de espacio de trabajo — marca una política / guardrail como el valor por defecto del espacio de trabajo así cada clave lo hereda.
Configura todo esto desde la consola con tu token de sesión/acceso (las rutas de gestión usan UserAuth, no la clave de relay). Las escrituras de firewall requieren Developer+; las escrituras de guardrail requieren Developer+. Una vez en vivo, las coincidencias de sanitize aparecen como eventos de firewall (veredicto, superficie, regla coincidente), y las coincidencias de guardrail aparecen en el feed de coincidencias de guardrail. Los dos tienen diferentes compuertas de lectura: el feed de eventos de firewall requiere Developer+, mientras que el feed de coincidencias de guardrail es legible por cualquier miembro del espacio de trabajo. Por defecto una coincidencia registra su tipo, acción y etapa pero no el contenido coincidente en bruto; activa Log raw content solo cuando necesites la subcadena para triaje.

​
6. Dónde ir a continuación

Lista de permitidos de herramientas MCP

Deniega por defecto un servidor y permite solo las herramientas que has revisado.

Reglas del firewall

El DSL completo de reglas — veredictos, globs, args-match, config de sanitize.

Guardrails

Políticas de contenido, presets, entidades de PII y cumplimiento de etapa de salida.

Envenenamiento de herramientas MCP

La amenaza que hace que los resultados de herramienta sean no confiables en primer lugar.
¿Nuevo en la división entre estas dos capas? Lee Guardrails vs. firewall, luego Exfiltración de datos para el camino de fuga que sanitize y los guardrails de salida cierran juntos.