Saltar al contenido principal
La mayoría de los equipos recurren a la seguridad de agentes demasiado tarde y un plano a la vez — un regex sobre los prompts aquí, una lista de bloqueados de herramientas allá. El resultado es una postura con huecos: examen de texto que nunca ve un shell.exec, o un firewall de herramientas que nunca nota un número de tarjeta de crédito saliendo en un prompt. La forma más rápida de una línea base de seguridad de agentes completa es establecer ambos planos a la vez. El control de autonomía de OrcaRouter — la línea base de Agentes Seguros — hace exactamente eso: un único interruptor a nivel de espacio de trabajo que escribe una política de firewall y un guardrail juntos, en una transacción, con deshacer de un clic. No autoras una regla para quedar protegido; eliges un nivel y afinas después.
Los dos planos son complementarios, no redundantes. Los Guardrails examinan el texto de prompt/respuesta (PII, secretos, intención de jailbreak e inyección); el firewall gobierna las acciones que un agente toma (qué herramientas, llamadas MCP y hosts). Cualquiera por sí solo deja un hueco que el otro cierra — ver Guardrails vs. Firewall.

​
1. Por qué una línea base supera a dos medias medidas

Una ejecución de agente real cruza ambos planos en una sola solicitud. El modelo lee un prompt (texto), decide llamar a db.query (acción), y el resultado de la herramienta se realimenta en el siguiente turno (texto otra vez). Asegurar solo un plano deja el otro sin protección:

Solo firewall

Deniegas shell destructivo, pero un prompt aún lleva el SSN de un cliente directo al modelo — y un argumento de herramienta aún filtra una clave API.

Solo guardrails

Enmascaras PII en los prompts, pero el agente aún llama a rm -rf, alcanza un endpoint de metadatos de nube, o entra en bucle sobre una herramienta descontrolada.
El control de autonomía elimina la elección. Un nivel establece una postura coherente a través de ambos planos, así que no hay ventana donde uno esté configurado y el otro no.

​
2. La línea base de seguridad de agentes: tres niveles

Cada nivel cubre los mismos dos planos. Elige uno; es tu piso, y añades precisión con reglas después.
NivelFirewallGuardrailsModo observe
tightDefecto-deny; shell destructivo + herramientas con forma de fetch denegadasPII Shield + Secrets Blocker aplicadosApagado
balancedDefecto-audit; shell destructivo denegadoPII Shield solo en audit (marca PII)Apagado
permissiveSin política de aplicaciónNingunoActivado — registra cada llamada como un hueco
Algunas especificidades que vale la pena fijar, ya que dan forma a lo que cada nivel realmente captura:
tight estampa el veredicto por defecto de la política de firewall a deny, luego apila reglas deny para los nombres de herramienta shell/exec que llevan comandos destructivos — shell.*, bash, cmd, powershell, exec — y para los nombres de herramienta con forma de fetch que llevan SSRF — http_fetch, web_search, fetch_url, request (y sus variantes con espacio de nombres MCP <server>.*). Deniega estos nombres de herramienta; no incluye una regla de egress de CIDR o metadatos de nube. Si quieres denegar 169.254.169.254 o rangos RFC-1918 por destino, autora tu propia regla de egress — ver Control de egress.
Tanto el guardrail PII Shield como el Secrets Blocker están activos y aplicando. PII Shield enmascara PII en la solicitud antes de que llegue al modelo; Secrets Blocker captura credenciales en la solicitud. Los secretos en argumentos de herramienta son capturados por este guardrail en la solicitud — el firewall no los quita por defecto.
balanced audita todo (veredicto por defecto audit) para que veas el comportamiento real de tu agente, mientras aún deniega la única clase más destructiva — shell destructivo. PII Shield se ejecuta en modo solo audit (marca PII, no bloquea). Obtienes un rastro completo con casi ningún riesgo de un bloqueo inesperado, luego endureces desde la visibilidad en vez de desde la conjetura.
permissive no aplica nada — existe para observar un agente completamente nuevo con cero riesgo de bloqueos accidentales. El modo observe permanece activado, así que cada llamada a herramienta aún se registra como un hueco de cobertura (visible en Herramientas descubiertas). Úsalo para aprender la forma de un agente, luego pasa a balanced o tight.

​
3. Un ejemplo concreto: aplicar balanced, observar ambos feeds

Aplicar un nivel es una sola acción de consola (Firewall → Posture) o una llamada API. La ruta se ejecuta bajo tu sesión y requiere Developer+. 
# Configure in the console, or POST under your session token (Developer+):
POST /api/workspace/firewall/autonomy
Content-Type: application/json

{ "level": "balanced" }
La respuesta lleva un audit_id — guárdalo; es lo que pasas para deshacer. Una vez aplicada, la línea base está en vivo en la siguiente llamada a herramienta. Sin redespliegue, sin cambio de código del agente. Ahora observas ambos planos a la vez:
  • Firewall → Events — cada veredicto de llamada a herramienta (audit, las llamadas de shell destructivo denegadas). Ver Registro de eventos.
  • Guardrails → Matches — cada coincidencia de política de contenido (marcas de PII Shield).
Como balanced escribe una política de firewall y un guardrail reales y editables (cada uno nombrado por el nivel), puedes abrir cualquiera después y afinarlo — la línea base es un punto de partida, no un preset bloqueado.
Previsualiza antes de comprometerte. GET /api/workspace/firewall/simulate?level=tight (Member, solo lectura) muestra exactamente qué cambiaría tight contra tu estado actual — nada se aplica. Ejecútalo después de un día o dos en balanced para confirmar que tight no denegará llamadas que son parte de tu tráfico normal.

​
4. Deshacer es una sola llamada

Cada cambio de autonomía es reversible desde su snapshot de auditoría, restaurando el estado previo exacto — políticas, reglas, guardrails y configuración — no un reset genérico. 
# Developer+; :audit_id is the value returned when you applied the level.
POST /api/workspace/firewall/autonomy/undo/:audit_id
Para un espacio de trabajo muy grande cuyo snapshot excede el límite de tamaño del registro de auditoría, la aplicación aún tiene éxito pero el deshacer de un clic no está disponible para ese cambio — reaplicas el nivel que quieras en su lugar. Esto es raro, pero vale la pena saberlo antes de endurecer un espacio de trabajo de producción ocupado.

​
5. La ruta recomendada

Empieza amplio, observa, luego endurece desde una posición de visibilidad:
1

Aplica balanced

Rastro de auditoría completo; solo se deniega shell destructivo; se marca PII. Ejecuta tus agentes normalmente por un día o dos.
2

Simula tight

GET /api/workspace/firewall/simulate?level=tight y compara sus denegaciones contra lo que el feed de Events realmente mostró. Si las llamadas con forma de fetch o de shell destructivo son parte de tu flujo normal, arregla el agente primero.
3

Aplica tight

Una vez que simulate no contiene sorpresas, cambia a tight. Deshacer está a una llamada de distancia si producción se rompe.
4

Afina con reglas

La línea base es tu piso. Talla excepciones o añade controles que no cubre con reglas de firewall y guardrails nombrados. Adjunta una política o guardrail específico a una clave individual para un alcance más fino.

​
6. Roles para la línea base combinada

El control de autonomía abarca ambos planos, pero cada acción está gobernada por rol.
AcciónRol mínimo
Simular un nivel / ver Matches de guardrail / ver Herramientas descubiertasMember
Ver Events y Runs del firewallDeveloper+
Aplicar un nivel de autonomíaDeveloper+
Deshacer un cambio de autonomíaDeveloper+
Toda la configuración se ejecuta en la consola bajo tu sesión (/api/workspace/firewall/* y /api/guardrail/*). Solo las llamadas de relay /v1/* usan una clave sk-orca-…; las rutas de clave de gateway son un alcance separado. Ver Alcance: claves, políticas, espacios de trabajo.

​
7. Después de la línea base: dónde afinar cada plano

La línea base te deja protegido en los primeros 30 minutos. De ahí en adelante, cada plano tiene su propia referencia para trabajo de precisión:

Visión general del Firewall

Veredictos, superficies, predicados de argumentos, aprobaciones — el plano de acción.

Guardrails

Reglas de keyword, regex, PII, llm_judge y grounding — el plano de contenido.

Modo shadow

Lanza una política de firewall endurecida en solo audit antes de aplicar.

Línea base de Agentes Seguros

La página de concepto del control de autonomía y su semántica de deshacer.
La línea base es el piso que cierra ambos planos a la vez; las reglas son cómo elevas el techo. Ver Asegurar agentes de IA y la pila de controles para cómo se componen las capas, y Agencia excesiva para la amenaza que esta línea base responde más directamente.