Saltar al contenido principal
Un agente que puede alcanzar la red puede convertirse en una tubería de datos. Instrucciones inyectadas le dicen que reúna secretos, filas o PII con las herramientas que ya posee y las haga POST a un host atacante — o que sondee servicios internos (SSRF). El agente nunca “decide” exfiltrar; ejecuta lo que le parece, a él, una instrucción legítima. Esta receta cablea tres controles que cierran el bucle de extremo a extremo — una lista de permitidos de egress que bloquea a dónde pueden ir las llamadas salientes, el guardrail Secrets Blocker que detiene las credenciales antes de que alcancen siquiera un modelo, y un saneador de argumentos que elimina secretos de las llamadas a herramienta que un modelo sí emite. Todo ello vive en el gateway, así que lo configuras una vez en la consola sin ningún cambio en el código de tu agente. Para la anatomía completa del ataque, lee Exfiltración de datos sobre la red; esta página son los pasos de construcción.
Todo aquí se vincula a tu espacio de trabajo y se configura desde la consola. Tu agente sigue llamando a https://api.orcarouter.ai/v1/... con la misma clave sk-orca-... — solo cambia la política en el gateway. Las acciones de configuración necesitan los roles indicados por paso; las llamadas de relay usan la clave con alcance. El firewall ve el egress solo para destinos enrutados a través del gateway (la ruta de despacho MCP o el hook de evaluación) — enruta tus llamadas a herramienta con destino a la red a través de él y quedan gobernadas.

​
1. Las tres capas que previenen la exfiltración de datos de IA

Cada capa captura el ataque en un punto diferente del ciclo de vida de la solicitud. Apila las tres — son independientes y complementarias.

Credenciales en el prompt

Un secreto pegado en (o arrastrado a) la solicitud se captura en la etapa de entrada por el guardrail Secrets Blocker — antes de que ningún modelo lo vea.

Secretos en argumentos de herramienta

Un modelo que emite una llamada a herramienta que lleva una credencial se limpia con una regla de firewall sanitize, que redacta el argumento coincidente.

Destino saliente

El paso de red real está acotado por una lista de permitidos de egress — solo pasan los hosts enumerados; todo lo demás se deniega.
Esta receta usa ambos planos: Guardrails para el texto en la solicitud, el Firewall para las acciones y la red. Ver guardrails vs firewall para dónde está la línea.

​
2. Detén credenciales en el prompt — el guardrail Secrets Blocker

Lo primero a asegurar es la credencial misma. El guardrail Secrets & API-Key Blocker se ejecuta en la etapa de entrada y escanea la solicitud en busca de patrones de credenciales — claves de acceso estilo AWS, claves de OpenAI, JWTs y tokens similares — antes de que la solicitud salga del gateway. Ante una coincidencia la solicitud se bloquea: la credencial nunca alcanza un modelo y nunca aterriza en una llamada a herramienta. En la consola, abre Guardrails → New guardrail (el rol Developer; las lecturas y el sandbox de Test están abiertos a cualquier miembro), nómbralo exfil-shield y aplica el preset Secrets & API-Key Blocker desde la biblioteca de plantillas (categoría secrets). El preset siembra tres reglas de bloqueo regex en la etapa input, una por forma de credencial — claves de acceso AWS, claves estilo OpenAI y tokens de GitHub: 
[
  { "type": "regex", "stage": "input", "action": "block", "pattern": "AKIA[0-9A-Z]{16}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "sk-[A-Za-z0-9]{20,}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "ghp_[A-Za-z0-9]{36}" }
]
Para extender la cobertura, añade una regla pii sobre las entidades integradas — el conjunto detector cubre email, phone, credit_card, ssn, ip, iban, mac_address, api_key_openai, aws_access_key, jwt y bitcoin_address. Elige mask (redactar a una etiqueta tipada como [EMAIL]) o block por entidad vía entity_actions. El enmascarado en la etapa de entrada está en vivo; reescribe la solicitud antes de que el modelo la vea.
Una solicitud bloqueada devuelve HTTP 400 guardrail_blocked, no cuesta cuota (un bloqueo en la etapa de entrada se dispara antes de la medición) y se marca skip-retry. Demuéstralo en la pestaña Test — pega una clave AWS de muestra, elige la etapa input y confirma el veredicto — antes de adjuntar una clave.

​
3. Sanea secretos de los argumentos de llamadas a herramienta

Un guardrail criba el prompt; no ve las llamadas a herramienta que un modelo emite. Cuando el modelo produce un tool_call cuyos argumentos llevan una credencial, una regla de firewall sanitize lo captura. Sanitize redacta las subcadenas coincidentes de los argumentos de la llamada a herramienta y reenvía la llamada limpia — la herramienta se ejecuta, pero con el secreto eliminado. En Firewall → Policies → New policy (rol Developer), nómbrala exfil-firewall y añade una regla sanitize en la superficie response — los tool_calls que el modelo emite en su respuesta: 
{
  "priority": 10,
  "label": "Redact secrets from tool args",
  "stage": "response",
  "tool_name_glob": "*",
  "verdict": "sanitize",
  "sanitize": {
    "presets": ["aws_access_key", "openai_key"],
    "custom": ["sk-[A-Za-z0-9]{20,}"]
  }
}
Sanitize redacta los argumentos de la llamada a herramienta solamente — nunca el contenido que una herramienta devuelve. Es una defensa sobre la forma de la llamada saliente, no sobre los resultados de herramienta entrantes. En la superficie inbound (donde aún no hay argumentos en tiempo de llamada) un veredicto sanitize escala a un deny. Ver el lenguaje de coincidencia completo en Reglas del firewall.

​
4. Bloquea destinos salientes — la lista de permitidos de egress

La defensa más duradera es el límite de red mismo: enumera los hosts que tus agentes están legítimamente autorizados a alcanzar y deniega todo lo demás. Una regla de egress usa stage: egress y el campo egress; el veredicto establece la polaridad — allow pasa los destinos listados y un deny catch-all de menor prioridad bloquea el resto. Añade estas reglas a la misma política exfil-firewall: 
[
  {
    "priority": 10,
    "label": "Allow known API endpoints",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "allow",
    "egress": {
      "allow": ["api.openai.com", "api.anthropic.com", "api.orcarouter.ai"]
    }
  },
  {
    "priority": 20,
    "label": "Deny all other outbound destinations",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny"
  }
]
Las entradas coinciden como un CIDR, un literal de IP o un nombre de host sin distinción de mayúsculas. Para detener SSRF hacia servicios internos sin una lista de permitidos explícita, autora tu propia regla de denegación de egress que liste el endpoint de cloud metadata (169.254.169.254) y los rangos privados RFC-1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Una llamada denegada devuelve HTTP 400 firewall_blocked.
Ningún preset incluye reglas de egress CIDR — autoras las entradas de allow y deny de host/CIDR tú mismo. El nivel de autonomía tight es la ruta rápida adyacente: deniega los nombres de herramienta con forma de fetch (http_fetch, web_search, fetch_url, request) por completo, eliminando la capacidad de red antes de que un destino se evalúe siquiera. Úsalo cuando tu agente no necesita esas herramientas en absoluto.

​
5. Adjunta una sola clave con alcance

Una política solo aplica sobre claves que resuelven a ella. Dale al agente su propia clave, con alcance al mínimo que necesita — nunca tu clave de toda la cuenta. En API Keys → New key (rol Developer):
Elige exfil-shield del desplegable Guardrail (establece guardrail_id) y exfil-firewall del desplegable Firewall policy (establece firewall_policy_id). Ambas vinculaciones viven en la clave en el gateway. Una adjunción explícita de guardrail nunca hace fallback silencioso — deshabilitarla es el interruptor de apagado. Una política de firewall deshabilitada, en cambio, hace fallback a la política por defecto del espacio de trabajo.
Establece credit_limit_usd a un techo razonable (0 = ilimitado) para que una clave comprometida no pueda drenar cuota, y allow_ips a las IPs de egress de tu backend si el agente llama desde un servidor fijo. Establece un expired_time para claves temporales (-1 = nunca expira).
La clave se enmascara en pantalla tras la creación — cópiala una vez. Tu agente ahora ejecuta cada solicitud a través de exfil-shield y cada llamada a herramienta a través de exfil-firewall sin que el código sepa que la aplicación está ocurriendo.

​
6. Lanza con modo shadow, luego vigila

Si aún no conoces cada host que tu agente alcanza legítimamente, no apliques a ciegas — observa primero. Ver modos de aplicación para la ruta completa observe → shadow → enforce.
1

Shadow de las reglas de egress

Establece shadow_mode: true en exfil-firewall. Cada veredicto de aplicación se degrada a audit y se registra como [shadow] would deny con el destino. No se bloquea tráfico mientras el modo shadow está activado.
2

Vigila los feeds

Firewall → Events / Runs (Developer+) muestra cada llamada a herramienta y destino de egress que tu agente tocó y qué se habría denegado. Guardrails → Matches (cualquier Member) muestra cada secreto que el guardrail de entrada capturó. Afina la lista allow de egress hasta que solo los hosts alcanzables por atacantes serían denegados.
3

Aplica

Apaga shadow_mode. La siguiente solicitud queda gobernada — credenciales bloqueadas en el prompt, secretos eliminados de los argumentos de herramienta, llamadas salientes confinadas a tu lista de permitidos. Sin cambio de aplicación.
El feed de Matches registra la subcadena coincidente solo cuando Log raw content está activado para el guardrail (apagado por defecto — la postura conservadora de privacidad). Marca un falso positivo (Admin) para afinar la política. Cada cambio de guardrail escribe una fila de historial de versiones que puedes diff y revertir; los cambios de política de firewall se registran en el rastro de auditoría.

​
7. Cobertura de un vistazo

Paso de exfiltraciónCapa que lo detiene
La credencial entra en la solicitudGuardrail Secrets Blocker (input)
El modelo emite una llamada a herramienta que lleva un secretoRegla de firewall sanitize (superficie response)
La herramienta marca un host atacanteRegla de egress allow / deny
El agente alcanza cloud metadata o RFC-1918Regla de denegación de egress que lista esos CIDRs
Herramienta con forma de fetch ofrecida al modeloNivel de autonomía tight (deny de nombre de herramienta)

​
8. Dónde ir a continuación

Referencia de reglas del firewall

El lenguaje de coincidencia completo — listas de egress, CIDRs, saneadores y todos los veredictos.

Amenaza de exfiltración de datos

La anatomía del ataque contra la que esta receta defiende, de extremo a extremo.

Endurecer un agente MCP

Gobierna cada tools/call que un agente despacha a través de un servidor MCP.

Registro seguro de PII

Mantén los datos sensibles fuera de tus registros de solicitudes y el feed de Matches.