Saltar al contenido principal
Un agente que puede alcanzar la red puede convertirse en un tubo de datos. Un atacante planta instrucciones en un documento que el agente lee — una página web, un chunk recuperado, un resultado de herramienta — y esas instrucciones dirigen al agente a hacer POST de datos sensibles a un host controlado por el atacante, o a sondear servicios internos (SSRF). El agente nunca “decide” exfiltrar; ejecuta lo que parece, para él, una instrucción legítima. Esta página cubre cómo el Agent Firewall y los Guardrails en OrcaRouter te permiten defenderte contra la exfiltración de datos de IA — sin cambiar el código de tu agente.
El firewall ve el egress solo para los destinos enrutados a través del gateway vía la ruta de despacho MCP o el hook de evaluación. Una herramienta que tu agente ejecuta completamente dentro de su propio proceso está fuera de su vista. Enruta las llamadas a herramienta vinculadas a la red de tu agente a través del gateway y estarán gobernadas.

​
1. Cómo funciona el ataque

El camino canónico a través de un agente se ejecuta en tres pasos:
  1. Inyección — el agente lee contenido no confiable que lleva instrucciones incrustadas (una página web, un documento obtenido, una nota de CRM).
  2. Recolección — las instrucciones inyectadas dicen al agente que reúna material sensible — claves API, filas de la base de datos, PII del usuario — usando herramientas que ya tiene.
  3. Exfiltración — se le dice al agente que envíe ese material a través de una herramienta con forma de fetch: http_fetch, web_search, fetch_url o request. El destino está controlado por el atacante.
SSRF tiene la misma forma redirigida hacia adentro: en vez de un host externo el agente es dirigido hacia 169.254.169.254 (metadatos de nube), un puerto interno de Redis u otro servicio privado. Ver Inyección de prompts para el paso de inyección; esta página se centra en el paso de red.

​
2. Lista de permitidos de egress — bloquea los destinos salientes

La defensa más duradera es una lista de permitidos de egress: enumera los hosts a los que tus agentes legítimamente pueden llegar y deniega todo lo demás. Una regla de egress usa stage: egress y el campo egress. El veredicto controla la polaridad — allow pasa los destinos listados; un deny catch-all de menor prioridad bloquea el resto: 
[
  {
    "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 CIDR, un literal de IP o un hostname sin distinguir mayúsculas y minúsculas. Los hostnames se resuelven con el mejor esfuerzo y se vuelven a verificar contra las entradas de IP/CIDR, así que un destino como 169.254.169.254 devuelto por DNS sigue siendo capturado por una entrada deny 10.0.0.0/8 de CIDR. Una llamada bloqueada devuelve HTTP 400 con el código de error firewall_blocked. Para denegar rangos conocidos como malos sin una lista de permitidos explícita, escribe una regla de deny de egress dirigida que liste el endpoint de metadatos de nube (169.254.169.254) y los rangos privados de RFC-1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Añade tu lista de permitidos encima con un número de prioridad menor para que las reglas de deny se evalúen primero.

​
3. Bloquea las herramientas con forma de fetch en la capa de nombres

Antes de que un destino de egress siquiera se evalúe, puedes eliminar la capacidad por completo. El nivel de autonomía tight deniega http_fetch, web_search, fetch_url y request por glob de nombre de herramienta como respaldo de SSRF y exfiltración. Si tu agente no necesita ninguna de esas herramientas, tight elimina la superficie de ataque en un paso: 
POST /api/workspace/firewall/autonomy
{ "level": "tight" }
Para denegar herramientas de fetch sin adoptar la postura completa tight, escribe una regla de deny en la superficie inbound. inbound bloquea la herramienta antes de que el modelo pueda elegirla — el agente nunca recibe la capacidad en su lista de herramientas: 
{
  "priority": 5,
  "label": "Deny fetch-shaped tools",
  "stage": "inbound",
  "tool_name_glob": "http_fetch",
  "verdict": "deny"
}
Repite para cada nombre de herramienta con forma de fetch que usa tu stack de agentes.

​
4. Guardrail Secrets Blocker — detiene las credenciales en el prompt

El guardrail Secrets Blocker se ejecuta en la etapa de entrada, escaneando el prompt en busca de claves de acceso al estilo AWS, claves OpenAI, claves Anthropic, tokens GitHub y patrones de credenciales similares antes de que la solicitud salga del gateway. Si se detecta un secreto, la solicitud se bloquea — la credencial nunca llega a un modelo y nunca aparece en una llamada a herramienta. Habilítalo desde el panel de Guardrails, o como parte del nivel de autonomía tight. Es independiente de las reglas de egress del firewall.
AmenazaCapa que la detiene
El prompt lleva una clave APISecrets Blocker (guardrail de entrada)
El agente llama a una herramienta de fetch hacia un host del atacanteRegla de allow/deny de egress
Herramienta con forma de fetch anunciada al modeloRegla de deny inbound o autonomía tight
El agente alcanza metadatos de nube o RFC-1918Regla de deny de egress listando esos CIDRs

​
5. Despliega con modo shadow

Si no estás seguro de qué hosts alcanza legítimamente tu agente hoy, empieza en modo shadow antes de aplicar:
  1. Crea las reglas de egress con tu lista de permitidos prevista y establece shadow_mode: true en la política.
  2. Observa el feed de Events — las llamadas que se bloquearían aparecen como [shadow] would deny con el destino.
  3. Ajusta la lista allow hasta que solo los destinos alcanzables por el atacante se denegarían, luego deshabilita el modo shadow para empezar a aplicar.
Ningún tráfico se bloquea mientras el modo shadow está activado.

​
6. Dónde ir a continuación

Referencia de reglas del firewall

Lenguaje completo de coincidencia — listas de egress, CIDRs, cláusulas de argumentos y todos los veredictos.

Vista general del Agent Firewall

Políticas, superficies, niveles de autonomía y observabilidad.

Inyección de prompts

El paso de inyección que dirige los agentes hacia la exfiltración.

Envenenamiento de herramientas MCP

Herramientas MCP maliciosas que registran capacidades con forma de fetch.