Saltar al contenido principal
Una sola llamada a herramienta puede verse perfectamente inocente. Leer un registro de CRM: permitido. Llamar a una herramienta de exportación: permitido. Golpear un host externo: permitido. La forma de la ejecución — cincuenta lecturas, luego una exportación, luego egress a un host que nunca has visto a las 3am de un domingo — es el ataque. Los veredictos por llamada juzgan cada llamada de forma aislada y nunca lo ven. Esta página cubre los dos mecanismos del firewall que vigilan una ejecución a lo largo del tiempo en vez de una llamada a la vez: las reglas de secuencia (una cadena ordenada que autoras) y la detección de anomalías de comportamiento (desviación del normal aprendido de tu espacio de trabajo). Juntas son cómo detectas el comportamiento de cadena de ataque de agentes que ninguna regla allow/deny puede capturar.
Todo aquí se configura en la consola (Security → Firewall), cuyas rutas de gestión usan tu sesión / token de acceso — no una clave de relay sk-orca-…. Las llamadas /v1/* de tu agente no cambian.

​
1. Por qué las reglas por llamada pasan por alto la cadena

Los globs de herramienta y las cláusulas de argumentos del firewall son sin estado y deterministas por diseño — deciden una llamada, rápido, en la ruta caliente. Eso es exactamente lo que quieres para “bloquear shell.exec rm -rf”. Es exactamente erróneo para una exfiltración de combustión lenta donde cada llamada individual es legal. Dos herramientas complementarias llenan el hueco:

Reglas de secuencia

Una regla que autoras que coincide con una cadena ordenada de llamadas dentro de una ventana de tiempo — “lectura masiva → exportación → egress”. Tú nombras el patrón.

Detección de anomalías

El firewall aprende la forma normal de uso de herramientas de cada espacio de trabajo y marca las desviaciones — bucles de reintento, rutas de herramienta nunca antes vistas y picos de volumen/coste. Ninguna regla que autorar.

​
2. Reglas de secuencia: nombra la cadena de ataque

Una regla sequence vive dentro de una política de firewall como cualquier otra regla, pero en vez de un solo tool_name_glob lleva una lista ordenada de pasos. Cada paso es un glob de herramienta con un min_count opcional y un egress: true opcional; los pasos deben ocurrir en orden (el entrelazado con llamadas no relacionadas está bien) y toda la cadena debe completarse dentro de window_seconds. 
{
  "label": "bulk-read-then-exfil",
  "verdict": "audit",
  "sequence": {
    "window_seconds": 600,
    "steps": [
      { "match": "crm.*",   "min_count": 50 },
      { "match": "*.export" },
      { "match": "*", "egress": true }
    ]
  }
}
Esta se dispara cuando un agente lee 50+ registros crm.*, luego llama a cualquier herramienta *.export, luego hace cualquier llamada de egress — todo dentro de diez minutos. Cada llamada por sí sola pasaría; el patrón es la señal.
Una secuencia se evalúa en la llamada que la completa. El bucle de reglas en línea omite las reglas de cadena (una llamada no puede satisfacer una cadena de varios pasos); la coincidencia se ejecuta cuando una llamada podría ser el paso final de una cadena, momento en el cual el firewall extrae los eventos recientes de ese principal y prueba la cadena. El verdict que estableces en la regla es lo que luego le pasa a la llamada que completa: audit la registra y la deja pasar, pending_approval la retiene para revisión humana, y deny la bloquea. Así que una cadena puede detener su llamada final en tiempo real — elige el veredicto que corresponda. Usa audit cuando solo quieras detectar y alertar; usa pending_approval o deny (o combina con un deny / regla de egress por llamada) cuando necesites una parada dura.
La sintaxis completa del campo sequence — window_seconds: 0 para sin límite de tiempo, valores por defecto de min_count, semántica de orden de pasos — está en el esquema de regla. Autora las reglas de secuencia en el editor de reglas de la consola; guardar es una acción Developer+.

​
3. Detección de anomalías: desviación del normal aprendido

Donde las reglas de secuencia preguntan “¿ocurrió este patrón específico”, la detección de anomalías pregunta “¿hay algo en esta ejecución que sea anormal para este espacio de trabajo”. No necesita ninguna regla — el firewall construye una línea base a partir de tu propio tráfico y puntúa la actividad en vivo contra ella. Cuatro tipos salen a la luz:
El volumen de llamadas por (herramienta, clave) puntuado contra la línea base aprendida para esta hora-de-la-semana. Una fila sale a la luz cuando el conteo supera un piso absoluto y corre alto en relación con la línea base, o cuando su z-score cruza el umbral estadístico. Así “100 llamadas db.query a las 3am del domingo” destaca aunque una ráfaga de martes-2pm del mismo tamaño no lo haría.
La misma idea aplicada al gasto: una herramienta quemando múltiplos de su coste de línea base aprendido para esta hora-de-la-semana. La advertencia temprana de denegación-de-cartera — combínala con una regla cap_cost para aplicar un techo duro.
Un grupo (conversation, tool, arguments) que se repite muchas veces en una ventana ajustada — un agente atascado llamando a la misma herramienta que falla con los mismos argumentos una y otra vez, en vez de un polling legítimo lento.
Una transición tool_a → tool_b que este espacio de trabajo nunca ha hecho antes. La primera vez que un agente va de read_file directo a http_fetch, ese borde se ilumina aunque ambas herramientas estén individualmente permitidas.

​
La línea base de hora-de-la-semana

La línea base es un promedio móvil de 14 días agrupado por hora de la semana (weekday × 24 + hour), así que martes-14:00 se compara específicamente contra el historial pasado de martes-14:00 — no una media plana de todos los tiempos que lavaría tu ritmo diario y semanal real. Un espacio de trabajo nuevo sin un normal aprendido todavía aún captura una inundación obvia vía un piso absoluto, así que estás protegido desde el día uno.
El feed reporta nombres de herramienta, ids de clave redactados, conteos y un z-score — nunca material de clave en bruto. Cada anomalía lleva una remediación sugerida (rate_limit, review o block_tool) para que el siguiente paso sea un clic, no una suposición.

​
4. Un recorrido concreto

Supón que un prompt comprometido lleva a uno de tus agentes a un bucle de fallo ajustado, luego sondea una ruta de exportación que nunca ha tocado. Esto es lo que ves — sin ninguna regla autorada de antemano:
1

El agente se comporta mal

Las instrucciones inyectadas empujan al agente a reintentar un db.query que falla con argumentos idénticos, luego llamar a report.export seguido de un fetch saliente — una ruta que este espacio de trabajo nunca ha ejecutado.
2

Abre el feed de anomalías

En Security → Firewall → Anomalies, la ejecución saca a la luz un retry_loop en db.query y un novel_path en el borde report.export → http_fetch. Leer el feed es una acción Member — cualquiera en el equipo puede triar.
3

Confirma en la traza de eventos

Haz clic hacia el registro de eventos y la analítica de ejecuciones para ver la secuencia de llamadas exacta, correlacionada con la ejecución y la conversación del agente. El feed de anomalías es legible por Member, pero el registro de eventos y la traza de ejecución llevan la procedencia de llamadas a herramienta y son Developer+.
4

Convierte el hallazgo en una regla

Ahora que has visto la cadena, codifícala: un deny sobre la exportación peligrosa, una lista de permitidos de egress sobre el fetch, o una regla de secuencia que audita todo el patrón la próxima vez. La detección de anomalías encuentra lo desconocido; una regla fija lo conocido.
Si el feed es ruidoso mientras afinas — un trabajo por lotes legítimo que genuinamente pica cada domingo, digamos — pospón (snooze) el feed de anomalías hasta 7 días mientras investigas. Posponer es una acción Developer+; la ventana está acotada por el servidor para que la detección siempre vuelva por sí sola.

​
5. Reglas de secuencia vs. detección de anomalías

Resuelven problemas adyacentes — elige el que coincida con lo que sabes:
Regla de secuenciaDetección de anomalías
Tú autorasLa cadena exactaNada — aprende
CapturaUn patrón de varios pasos conocidoLo desconocido / anormal
ActúaAplica el veredicto de la regla a la llamada que completa (audit / pending_approval / deny)Sale a la luz en el feed
Un espacio de trabajo maduro ejecuta ambos: la detección de anomalías es el radar que saca a la luz cadenas que no anticipaste — solo sacar a la luz, nunca bloquear; las reglas de secuencia son cómo codificas las que tienes, para que estén etiquetadas, rastreadas y (con un veredicto pending_approval o deny) capaces de gobernar la llamada que completa. Para una parada dura en una sola llamada sin importar ninguna cadena, recurre a un veredicto por llamada.

​
6. RBAC y las rutas detrás del feed

El feed de anomalías y las reglas de secuencia se sitúan bajo las rutas de gestión del firewall del espacio de trabajo — tu sesión / token de acceso, nunca una clave de relay:
Método y rutaRolPropósito
GET /api/workspace/firewall/anomaliesMemberLeer el feed de anomalías (?window=).
POST /api/workspace/firewall/anomalies/snoozeDeveloper+Posponer el feed ({until}, acotado a 7 días).
POST /api/workspace/firewall/rulesDeveloper+Crear una regla de secuencia (o cualquiera) bajo una política.
POST /api/workspace/firewall/testDeveloper+Ejecutar en seco una política contra una llamada de muestra antes de depender de ella.
Las lecturas del feed están abiertas a cada Member para que todo el equipo pueda triar; autorar reglas y posponer el feed son escrituras Developer+, consistentes con el resto del modelo RBAC del firewall.

​
Dónde ir a continuación

Esquema de regla

El campo sequence completo — pasos, min_count, window_seconds y cada otro campo de regla.

Registro de eventos

Dónde aterrizan las secuencias coincidentes y las anomalías — filtra por ejecución, superficie y veredicto.

Limitar coste

Convierte una señal burn_spike en un techo de gasto duro por ejecución.

Control de egress

Detén el paso final de exfiltración de una cadena en la frontera de red.
Para los manuales de atacante que estos mecanismos contrarrestan, ver ataques encadenados, exfiltración de datos y agencia excesiva. Para la referencia profunda del firewall, ver Reglas del Firewall.