Saltar al contenido principal
Un agente de codificación es lo de mayor apalancamiento en tu espacio de trabajo y lo más peligroso. Ejecuta shell.exec, edita archivos, obtiene URLs y carga skills de la comunidad — cualquiera de las cuales puede hacer rm -rf a un volumen, leer un .env o exfiltrar hacia un host atacante. Esta receta blinda esa superficie con el Firewall: deniega shell destructivo, valida los argumentos de las llamadas que sí permites, cerca el egress y retiene las operaciones genuinamente arriesgadas para un humano. Nada de ello toca el código de tu agente — la política vive en el gateway y se aplica en la siguiente llamada.
Todo lo de abajo se configura en la consola (Firewall → Posture / Policies). Esas rutas de gestión usan tu sesión de consola, no una clave de relay. Solo las llamadas /v1/* que hace tu agente llevan una clave sk-orca-…. Las ediciones de política requieren el rol Developer.

​
1. Empieza vigilando, no bloqueando — línea base del agente de codificación seguro

No autores reglas a ciegas. Dale al agente su clave sk-orca-…, luego abre Firewall → Posture y aplica el nivel de autonomía balanced. En una transacción esto audita cada llamada a herramienta, marca PII y deniega shell destructivo — así que la peor acción ya está cercada mientras aprendes el resto del comportamiento del agente desde tráfico real. Déjalo correr, luego lee Firewall → Discovered tools: cada herramienta que el espacio de trabajo ha visto, marcada covered (una regla aplica) o gap (ninguna lo hace). Esa lista es el borrador de tu lista de permitidos. Cuando el feed se vea bien, pasa a tight (default-deny) o autora la política dirigida de abajo.
balanced es la postura de inicio recomendada; permissive no bloquea nada pero aún registra todo; tight es default-deny más los presets de secretos y SSRF. Ver la línea base para exactamente qué materializa cada uno.

​
2. Deniega shell destructivo — el suelo no negociable

La única regla más importante para un agente de codificación es nada de shell destructivo. Los niveles de autonomía balanced y tight ya incluyen esto como el preset Block destructive shell, que materializa reglas deny reales y editables que cubren tanto los nombres de herramienta directos del espacio de trabajo (shell.*, bash, cmd.*, powershell.*, exec.*) como las formas con espacio de nombres MCP que un servidor registrado expone (*.shell.*, *.cmd.*, …). Si prefieres acotarlo más estrechamente que “denegar todo shell”, autora una regla que solo deniegue los comandos destructivos y audite el resto. Una regla coincide sobre un glob de nombre de herramienta más un predicado de argumentos opcional (JSONPath contra los argumentos de la llamada):
En Firewall → Policies, añade una regla por encima de tu valor por defecto:
  • Glob de herramienta: shell.exec
  • Args match (cláusula JSONPath):
{
  "clauses": [
    { "path": "$.command", "op": "regex", "value": "(?i)\\brm\\s+-[a-z]*[rf]" }
  ]
}
  • Veredicto: deny
Los operadores de argumentos son un conjunto cerrado — eq, contains, regex, in, cidr_match, gt, lt. Una llamada cuyo $.command coincide con el regex se bloquea; todo lo demás cae a la siguiente regla.
Una llamada denegada en la superficie inbound devuelve HTTP 400 con el código de error firewall_blocked y un mensaje que nombra la herramienta y la razón. Una llamada despachada a través del gateway MCP vuelve como un error de herramienta (firewall deny: …) para que el modelo pueda reaccionar en vez de fallar. Los bloqueos inbound se disparan antes de la llamada al modelo upstream, así que no cuestan tokens de modelo.
Ver Reglas del firewall para el lenguaje de coincidencia completo (globs de herramienta, cláusulas de argumentos, secuencias, topes de coste).

​
3. Valida los argumentos en las herramientas que conservas

Permitir una herramienta no es lo mismo que permitir cada argumento a ella. El mismo predicado JSONPath que acota un deny te permite restringir la forma de una llamada permitida — así que db.query no puede llevar un DROP, y file.write no puede escapar de un directorio.

Bloquea un DROP de SQL

Glob db.query, cláusula {"path":"$.sql","op":"regex","value":"(?i)\\bdrop\\b"}, veredicto deny.

Redacta un secreto en argumentos

El veredicto sanitize redacta las subcadenas coincidentes de los argumentos de la llamada a herramienta antes de que la llamada se reenvíe. Nunca toca lo que una herramienta devuelve; en la superficie inbound (sin argumentos en tiempo de llamada aún) escala a un bloqueo.
El Firewall sanea los argumentos de la llamada a herramienta, no los resultados de la herramienta. Para evitar que un secreto entre siquiera en una solicitud, adjunta el guardrail Secrets Blocker a la clave — eso criba el propio texto del prompt antes de que el modelo lo vea. Los dos planos se componen: los guardrails criban texto, el Firewall gobierna la acción.

​
4. Controla el egress — cerca a dónde puede alcanzar el agente

Un agente de codificación que puede obtener URLs puede ser dirigido a SSRF (alcanzando cloud-metadata o un host interno 10.x) o usado para exfiltrar. El nivel de autonomía tight incluye un preset SSRF que deniega los nombres de herramienta con forma de fetch (http_fetch, web_search, fetch_url, request y sus formas <server>.*) por completo. Para control a nivel de destino, autora una regla egress. Las reglas de egress acotan por host o CIDR con entradas allow / deny, evaluadas en la superficie egress: 
{ "deny": ["169.254.169.254", "10.0.0.0/8", "*.internal"] }
Eso se dispara ante cualquier destino saliente reportado por una herramienta que aterriza en un rango privado, la IP de cloud-metadata o un nombre de host interno — dejando pasar los destinos públicos mientras cerca los peligrosos.
Ningún preset incluye reglas de egress basadas en CIDR — el preset SSRF coincide con nombres de herramienta con forma de fetch. La denylist de host/CIDR de arriba es una que autoras tú mismo. Ver Detener la exfiltración para el patrón completo.

​
5. Retén operaciones arriesgadas para un humano (HITL)

Algunas operaciones no deberían auto-permitirse ni auto-denegarse — un despliegue, un git push, una migración destructiva. Para esas, usa el veredicto pending_approval. La llamada se retiene, el agente obtiene una respuesta “retenida” con un id de aprobación, y un revisor la resuelve fuera de banda:
  1. Autora una regla (p. ej. glob deploy.*, veredicto pending_approval).
  2. La llamada retenida devuelve HTTP 400 firewall_approval_pending con un id de aprobación.
  3. Un revisor la aprueba desde la consola (Developer+) o vía un callback de webhook firmado con HMAC.
  4. El agente hace polling de la aprobación, luego reenvía la llamada original con una cabecera X-OrcaRouter-Firewall-Approval de un solo uso — y el gateway la deja pasar esa única vez.
Lanza cualquier política nueva en modo shadow primero. La política evalúa y registra exactamente como lo haría en producción, pero cada veredicto de aplicación se degrada a audit con una razón [shadow] would … — así que puedes demostrar que se dispara en lo que esperas antes de que pueda romper un build.

​
6. Gobierna las skills y servidores MCP que carga

Los agentes de codificación incorporan capacidades en tiempo de ejecución — skills de la comunidad, servidores MCP propios. El Firewall gobierna ambos en el gateway:
  • Las Skills se escanean en una banda de riesgo con un modo de aplicación (allow / quarantine / block). Una skill auto-detectada se pone en cuarentena — retenida para aprobación — hasta que un revisor la despeja. Ver Skills.
  • Los servidores MCP que registras despachan cada tools/call a través del gateway, que evalúa cada uno en la superficie mcp antes del despacho. Las credenciales se almacenan cifradas; una sonda de salud reporta ok / degraded / down. Ver Servidores MCP y Endurecer un agente MCP.

​
7. Verifica y observa

Antes de depender de una política, ejecútala en seco. La pestaña Test evalúa una llamada a herramienta de muestra contra la política actual y muestra el veredicto, la regla coincidente y la razón — nada se despacha, nada se persiste. Una vez en vivo, Firewall → Events / Runs es el registro de cada evaluación, filtrable por veredicto, superficie, herramienta y ejecución, y el feed de anomalías marca picos de tasa/coste contra la línea base aprendida del espacio de trabajo, retry_loop y rutas de herramienta nunca antes vistas.

​
Resumen

Referencia de Firewall

El plano de política completo — superficies, veredictos, resolución, autonomía.

Reglas del firewall

El lenguaje de coincidencia: globs, cláusulas de argumentos, egress, secuencias.

Llamadas a herramientas peligrosas

La amenaza contra la que esta receta defiende.

Agencia excesiva

Por qué los agentes con permisos excesivos son el riesgo central del agente.

Receta de agente autónomo

Blinda un bucle de agente totalmente autónomo de extremo a extremo.

Detener la exfiltración

Los patrones de egress y trifecta letal en profundidad.