Saltar al contenido principal
Los secretos terminan donde no pertenecen. Un desarrollador pega un archivo .env en un prompt para “ayudar a depurar”. Un documento recuperado lleva una clave API incrustada. Un modelo, al que se le pide “muestra la config”, devuelve una clave de acceso de AWS directamente al cliente. Un agente construye una llamada a herramienta con un token vivo horneado en los argumentos. Cada una de estas es una ruta para que una credencial escape — hacia los logs de un proveedor upstream, hacia una transcripción de cliente, o hacia una herramienta de terceros. Esta página cubre cómo los Guardrails y el Agent Firewall de OrcaRouter te permiten defenderte de la fuga de secretos en el llm — sin cambiar el código de tu aplicación.
La detección ocurre en el gateway, delante de cada clave vinculada — así que una única política cubre cada proveedor, cada modelo y cada agente sin un cambio de SDK.

1. Dónde se filtran los secretos

Una credencial puede escapar en tres puntos distintos de una solicitud:
La credencial está en la solicitud antes de que el modelo se ejecute — una clave pegada, un fragmento .env, un token dentro de un chunk de RAG recuperado. Sin verificar, llega al proveedor upstream y puede aterrizar en sus logs. Detenla con el guardrail de entrada Secrets Blocker (§2).
El modelo emite un secreto de vuelta a tu cliente — regurgita una clave de su contexto, o alucina una cadena con forma de credencial. Captúralo con una regla de secretos de salida (§3).
Tu agente construye una llamada a herramienta con un token en los argumentos. El veredicto sanitize del Firewall redacta las subcadenas coincidentes de los argumentos antes de que la llamada se despache (§4).
Las dos primeras son verificaciones de contenido (Guardrails); la tercera es una verificación de acción (Firewall). Apila las tres para defensa en profundidad.

2. Secrets Blocker — detén credenciales en el prompt

El Secrets Blocker es un preset de guardrail bajo la categoría secrets que se ejecuta en la etapa input. Escanea la solicitud en busca de formas de credencial — claves de acceso de AWS, claves estilo OpenAI y tokens de GitHub — y bloquea la llamada antes de que salga del gateway. La credencial nunca llega a un modelo. Autóralo una vez en la consola, adjunta una clave, y cada solicitud a través de esa clave es examinada:
1

Crea el guardrail

En la consola, abre /console/guardrails, haz clic en New guardrail y aplica el preset Secrets & API-Key Blocker de la categoría secrets. Siembra un guardrail con reglas de bloqueo de etapa de entrada para las formas de credencial comunes — edita libremente desde ahí.
2

Adjunta una clave

Abre /console/token, edita una clave API y elige el guardrail del desplegable Guardrail — o establécelo como el valor por defecto del espacio de trabajo para que cada clave no adjunta lo herede.
3

Envía una solicitud

Llama al gateway exactamente como antes con esa clave sk-orca-...:
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "why is AKIAIOSFODNN7EXAMPLE rejected"}
    ]
  }'
La forma de clave de AWS dispara el guardrail y la solicitud se rechaza con HTTP 400 guardrail_blocked. La clave nunca llega al modelo.
Una solicitud bloqueada no cuesta cuota — un bloqueo de etapa de entrada se dispara antes del metering — y se marca como skip-retry, así que reejecutar el mismo prompt simplemente vuelve a bloquear en vez de quemar un canal de fallback.
¿Necesitas cobertura más amplia? La categoría secrets también entrega un preset Private Keys & Cloud Tokens que bloquea claves privadas PEM, tokens de Slack y Stripe, claves API de Google y JWTs. Aplica ambos — un guardrail puede contener cualquier número de reglas. Para capturar JWTs y formas de credencial como entidades tipadas (con etiquetas [JWT] / [AWS_ACCESS_KEY]), una regla pii que cubra jwt, aws_access_key y api_key_openai es la alternativa basada en entidades; ver la referencia de Guardrails.
El nivel de autonomía tight del Firewall activa el guardrail Secrets Blocker como parte de su postura, junto con PII Shield y denegaciones de shell destructivo. Si quieres un interruptor en vez de autorar reglas a mano, esa es la ruta rápida. La verificación de credencial en sí siempre es el guardrail — no el escáner de argumentos del firewall.

3. Bloquea secretos en la salida del modelo

Un secreto también puede salir en la respuesta — el modelo devuelve una clave de su contexto o emite una cadena con forma de credencial. Añade una regla en la etapa output para examinar la respuesta del modelo antes de que regrese al cliente. La categoría secrets entrega un preset Code Secret in Output para exactamente esto: reglas de bloqueo de etapa de salida para claves privadas PEM, claves de acceso de AWS y tokens secretos estilo OpenAI.
{
  "type": "regex",
  "stage": "output",
  "action": "block",
  "pattern": "AKIA[0-9A-Z]{16}"
}
El block de salida se aplica tanto en respuestas sin streaming como con streaming — en un stream, un escáner corta la respuesta en pleno vuelo antes de que cualquier contenido bloqueado llegue al cliente. Un bloqueo de salida reembolsa la cuota pre-consumida.
El enmascarado de salida (reemplazar una coincidencia con una etiqueta tipada en vez de rechazar la respuesta completa) actualmente aplica solo a respuestas sin streaming. Para credenciales en la salida, la acción block es la elección fiable en tráfico con streaming. Demuestra tu combinación de etapa/stream en la pestaña Test del guardrail antes de depender de ella.

4. Sanea secretos de los argumentos de llamadas a herramienta

Cuando tu agente construye una llamada a herramienta, una credencial puede viajar en los argumentos. El veredicto sanitize del Firewall redacta las subcadenas coincidentes de los argumentos de la llamada a herramienta y reenvía la llamada limpia — en las superficies response y mcp, donde hay argumentos en tiempo de llamada que reescribir. Una regla sanitize nombra qué detectores redactar en su configuración sanitize_json — un conjunto de presets integrados más regexes custom opcionales. El material coincidente se reemplaza con [redacted:<preset>] (las coincidencias custom con [redacted:custom]):
{
  "priority": 10,
  "label": "Redact AWS keys from tool args",
  "stage": "response",
  "tool_name_glob": "*",
  "verdict": "sanitize",
  "sanitize_json": {
    "presets": ["aws_access_key", "aws_secret_key", "openai_key", "anthropic_key", "bearer_token"],
    "custom": []
  }
}
Los presets con forma de secreto disponibles para un saneador son aws_access_key, aws_secret_key, openai_key, anthropic_key y bearer_token (más email, ssn_us y credit_card para PII). Una regla sanitize debe nombrar al menos un preset o patrón custom — un saneador vacío se rechaza al guardar.
Sanitize redacta argumentos, no resultados. Limpia los argumentos de una llamada a herramienta que tu agente autoró; no depura el contenido que una herramienta devuelve. Y en la superficie inbound — donde aún no hay argumentos en tiempo de llamada — sanitize escala a un deny. Ver la referencia de reglas del firewall para el lenguaje de coincidencia.
El guardrail Secrets Blocker (§2) sigue siendo tu defensa primaria para credenciales en el cuerpo de la solicitud — el saneador del firewall es el complemento a nivel de acción para secretos que aparecen específicamente dentro de los argumentos de llamadas a herramienta.

5. Apilar las tres defensas

Dónde está el secretoCapa que lo detieneAcción
En el promptSecrets Blocker (guardrail de entrada)block
En la respuesta del modeloRegla de secretos de salida (guardrail de salida)block
En un argumento de llamada a herramientaSaneador del Firewallsanitize
Lanza cualquier regla nueva en modo shadow (firewall) o con la acción flag (guardrail) primero. Observa el feed de eventos / Matches para confirmar que se dispara en credenciales reales y no en parecidos benignos, luego cambia a la acción de aplicación.

6. Observa qué se disparó

Cada regla de guardrail que se dispara registra una coincidencia — tipo de regla, acción, etapa y una cadena de detalle — al feed de Matches del espacio de trabajo (GET /api/guardrail/match, Member). La subcadena coincidente se registra solo cuando “Log raw content” está activado, que está apagado por defecto — la postura conservadora de privacidad, para que el feed de Matches no se convierta él mismo en un lugar donde se acumulen secretos. Déjalo apagado para reglas de credenciales a menos que específicamente necesites la subcadena para triaje. Las decisiones de sanitize del firewall aterrizan en el feed de Events del Firewall (GET /api/workspace/firewall/events, Developer+), con secretos y blobs de reglas nunca registrados.

7. Adónde ir a continuación

Referencia de Guardrails

Tipos de regla, entidades de PII, presets, el sandbox de test y el arnés de eval por completo.

Referencia de reglas del Firewall

El lenguaje de coincidencia — globs de herramienta, cláusulas de argumentos y saneadores.

Exposición de PII

La amenaza de contenido hermana: datos personales en prompts y respuestas.

Exfiltración de datos

Cuando una credencial filtrada se convierte en la carga útil de una llamada de exfiltración saliente.

Guardrails vs Firewall

Qué plano detiene qué clase de fuga, y cómo se componen.

Línea base de agentes seguros

La postura de inicio que activa estas defensas juntas.