db.query a
las 3am del domingo, un agente martillando una herramienta que falla en un
bucle ajustado, un salto de herramienta a herramienta que este espacio de
trabajo nunca ha hecho antes. Cada llamada pasa cada regla; el patrón es el
problema.
La detección de anomalías del firewall es la capa de comportamiento. El
gateway aprende la forma normal de uso de herramientas de tu espacio de
trabajo y puntúa la actividad en vivo contra ella, sacando a la luz las
desviaciones en un feed que cualquier Member puede leer. Es cómo notas un
agente comprometido o un bucle descontrolado sin haber pre-escrito una regla
para una forma que nunca habías visto. Esta página es el aterrizaje enfocado
para ese feed de detección de anomalías del firewall; la
Visión general del Firewall es la
referencia profunda.
El feed de anomalías es detección, no aplicación. Te dice qué se ve raro —
no bloquea. Cuando un patrón es real, lo conviertes en una
regla o un
veredicto con límite de tasa para que la
siguiente ocurrencia se detenga en línea. Leer el feed está abierto a cada
Member; convertir un hallazgo en política es
Developer+.
1. Qué marca la detección de anomalías del firewall
Cuatro tipos de señal, cada uno ligado a un modo de fallo diferente:rate_spike — demasiadas llamadas para esta hora
rate_spike — demasiadas llamadas para esta hora
El volumen de llamadas por herramienta puntuado contra una línea base de
hora-de-la-semana aprendida. Una herramienta dispara
rate_spike
cuando su conteo supera un piso absoluto y corre alto en relación con la
línea base para esa hora, o cuando su z-score cruza el umbral. Tener
clave en hora-de-la-semana (no hora-del-día) significa que martes-14:00 se
compara con martes-14:00 pasados, así que el tráfico legítimo de pico de
día laboral no se lee como un pico mientras que el mismo volumen a las 3am
del domingo sí.burn_spike — el coste corre caliente vs línea base
burn_spike — el coste corre caliente vs línea base
La misma comparación de hora-de-la-semana, aplicada al coste acumulado
en vez del conteo de llamadas. Una herramienta cuyo gasto corre muy por
encima de su norma de coste aprendida sale a la luz como un
burn_spike —
la señal de advertencia temprana para un agente que es costoso antes de ser
destructivo.retry_loop — la misma llamada, una y otra vez
retry_loop — la misma llamada, una y otra vez
Un grupo
(conversation, tool, arguments) que se repite muchas veces
dentro de una ventana corta — un agente atascado reemitiendo la misma
llamada a herramienta que falla en vez de recuperarse. El polling legítimo
lento no lo dispara; la señal es un bucle ajustado.novel_path — una transición nunca vista antes
novel_path — una transición nunca vista antes
Una transición consecutiva
tool_a → tool_b para la que este espacio de
trabajo no tiene línea base aprendida. La primera vez que un agente va,
digamos, crm.read → http.fetch, ese borde es nuevo — exactamente el tipo
de paso que toma una cadena de
exfiltración de datos.2. La línea base de 14 días
El detector no es un umbral fijo — es una norma aprendida. Para cada bucket(tool, hour-of-week) el gateway mantiene un conteo de llamadas y coste
esperado móvil, rellenado desde una mirada hacia atrás de 14 días (unas dos
ocurrencias de cada bucket de hora-de-la-semana — suficiente para suavizar un
solo día extraño sin perder la forma semanal). novel_path usa la línea base
de transición paralela: el conteo de ocurrencia aprendido para cada borde
tool_a → tool_b en esa hora-de-la-semana.
Un espacio de trabajo completamente nuevo no tiene línea base todavía. Eso está
bien: sin una norma aprendida, los detectores de volumen caen a un piso
absoluto, así que una inundación obvia aún se captura en el día uno mientras
las normas por hora se rellenan.
| Señal | De qué aprende |
|---|---|
rate_spike / burn_spike | Conteo y coste por (tool, hour-of-week), móvil de 14 días. |
novel_path | Conteo de transiciones por (tool_a → tool_b, hour-of-week). |
retry_loop | Sin línea base — un umbral de repetición por ventana sobre (conversation, tool, args). |
El feed reporta solo nombres de herramienta, ids de token redactados y
conteos. Un id de clave API en bruto nunca aparece — cada ítem lleva un
digest de una sola vía del token que llama, así que puedes distinguir dos
anomalías sin que el feed filtre jamás la clave detrás de ellas.
3. Una lectura concreta
Supón que una clave de agente empieza a entrar en bucle. Saca el feed en la consola bajo Security → Firewall → Anomalies, o léelo directamente — cualquier Member puede:retry_loop no lleva baseline ni z_score (esos campos quedan en
0 — pertenecen a los detectores de volumen/coste), y lleva un id opaco
estable para que dos bucles distintos en la misma herramienta no colisionen en
una fila. Un rate_spike es lo inverso: reporta un baseline aprendido y un
z_score, y deja id vacío.
Cada ítem nombra la herramienta, el token redactado, cuántas llamadas se
dispararon, el z-score (solo señales de volumen/coste), y un
suggested_action (rate_limit, block_tool o review). De aquí actúas:
suelta una regla deny sobre la
herramienta, valida sus argumentos,
o abre el registro de eventos para ver
exactamente qué hizo el agente.
4. Posponer el feed
Una prueba de carga conocida o un backfill planeado iluminará el feed. En vez de perseguir ruido, pospónlo (snooze) — por hasta 7 días:snoozed_until; se limpia solo en el momento en que pasa la fecha límite. El
tope es un techo duro — un until mal tecleado u hostil más allá se acota
para que la detección de anomalías no pueda silenciarse indefinidamente. Hacer
POST de un until pasado o actual limpia un snooze existente.
Leer el feed es una acción Member; posponerlo es Developer+ —
silenciar una señal de seguridad a nivel de espacio de trabajo es una
escritura, no una lectura.
5. RBAC de un vistazo
La superficie de analítica se divide a lo largo de la línea habitual de leer/actuar:| Acción | Rol |
|---|---|
| Leer el feed de anomalías | Member |
| Leer configuración, políticas, herramientas descubiertas | Member |
| Posponer el feed | Developer+ |
| Events, runs, aggregate, trace | Developer+ |
| Autorar una regla desde un hallazgo | Developer+ |
6. De la señal a la política
El feed es el inicio de un bucle, no el final:Detecta el patrón
Un
novel_path o rate_spike muestra una forma que no esperabas. Léelo
contra el registro de eventos para
confirmar que es real, no un caso aislado.Escribe la regla
Convierte el hallazgo en aplicación — un
bloqueo, una
cláusula de argumentos, una
regla de secuencia para la cadena, o
un tope de coste para el gasto.
Lánzalo de forma segura
Aterriza la regla bajo modo shadow
primero para medir su radio de explosión antes de que bloquee una sola
llamada, luego aplica.
Dónde ir a continuación
Visión general del Firewall
La referencia completa de detección de anomalías y el resto del plano de
política.
Registro de eventos
Profundiza desde una anomalía hacia las llamadas exactas detrás de ella.
Bloquear una herramienta
Convierte un hallazgo en una regla de aplicación.
Modos de aplicación
Cómo encajan detección, audit, shadow y aplicar.