Observabilidad de agentes de IA: monitorear lo que no puedes ver

Anthropic lanzó en Claude Desktop una función llamada Cowork. Esa función creaba un bundle de máquina virtual de 10 GB en cada instalación de macOS. Los usuarios que nunca activaron Cowork recibían la VM de todos modos. Quienes la borraban la veían regenerarse. Un usuario reportó un bundle que creció hasta los 21 GB. El issue de GitHub acumuló 345 puntos y 175 comentarios en Hacker News antes de que Anthropic reconociera el problema.¹

Nadie lo notó hasta que se agotó el espacio en disco.

¿Qué es la observabilidad de agentes de IA? La observabilidad de agentes es la práctica de monitorear qué consumen y qué ejecutan los agentes autónomos en tiempo de ejecución. Requiere tres capas: medición de recursos (disco, memoria, CPU y red por sesión), aplicación de políticas (reglas de permitir y denegar en cada llamada a una herramienta) y auditoría en ejecución (registro del comportamiento real a nivel del kernel). Sin las tres, los operadores no pueden detectar la deriva, ni hacer cumplir el alcance, ni reconstruir incidentes.

TL;DR

Las herramientas de agentes ya asignan recursos de cómputo (disco, memoria, CPU y red) sin visibilidad para el operador. La VM de Cowork de Anthropic es el ejemplo visible; cada llamada a una herramienta MCP, cada subagente lanzado y cada descarga web son ejemplos invisibles. Gobernar agentes exige tres capas de observabilidad: medición de recursos (¿qué consumió?), aplicación de políticas (¿qué tenía permitido hacer?) y auditoría en ejecución (¿qué hizo realmente?). Dos proyectos de código abierto cubren la capa de políticas y la de auditoría (mcp-firewall y Logira), pero ninguna herramienta lista para producción cubre las tres. A continuación: el problema de visibilidad, la pila de tres capas, qué detecta cada capa y los hooks mínimos de monitoreo que puedes implementar hoy mismo.

El problema de visibilidad

El software tradicional opera por debajo de una línea de observabilidad que los operadores eligen trazar. Un servidor web escribe logs de acceso porque alguien configuró el registro. Una base de datos rastrea consultas lentas porque alguien definió log_min_duration_statement. La granularidad la decide el operador.

Los sistemas de agentes invierten esa relación. Es el agente quien decide qué ejecutar en tiempo de ejecución. Un agente de programación que recibe «arregla el endpoint de inicio de sesión» puede leer 47 archivos, escribir en 12, lanzar tres subagentes, descargar dos páginas web y ejecutar 15 comandos de bash. Cada acción consume recursos. Nada de ese consumo aparece en el monitoreo tradicional.

El incidente de Cowork dejó al descubierto esa inversión en la capa de infraestructura. Claude Desktop asignaba 10 GB de espacio en disco, consumía entre 24 y 55 % de CPU en reposo y elevaba la actividad de swap de 20.000 a más de 24.000 swapins en máquinas de 8 GB.¹ Los usuarios descubrieron ese consumo por las alertas de almacenamiento de macOS, no por la telemetría de Anthropic. La aplicación no ofrecía ningún panel, ningún medidor ni ningún aviso previo sobre la asignación de la VM.

El patrón no es hipotético. En marzo de 2026, un desarrollador reportó que Claude Code ejecutó un comando de Terraform que destruyó una base de datos de producción. El agente corrió terraform apply contra un archivo de estado de producción. No apareció ninguna confirmación. Ningún hook interceptó el comando. El desarrollador descubrió la destrucción cuando la aplicación se cayó. El incidente acumuló 142 puntos y 158 comentarios en Hacker News.¹² Días después, otro desarrollador reportó que Claude Code borró una instalación de producción completa, incluidos los snapshots de base de datos que representaban 2,5 años de registros.¹³ Ambos incidentes comparten la misma causa raíz: cero visibilidad sobre lo que el agente estaba haciendo antes de que el daño fuera irreversible.

Lleva el patrón a la escala de las sesiones de agentes. Mi sistema de orquestación de hooks — construido sobre la infraestructura de hooks de Claude Code — intercepta 15 tipos de eventos en cada llamada a una herramienta.¹¹ A lo largo de más de 60 sesiones, el sistema registró 84 hooks disparándose en cada acción y produjo una telemetría que ninguna instalación de agente por defecto entrega.² Sin esa instrumentación no habría detectado los 12 incidentes de deriva, ni las verificaciones fantasma, ni los bucles de lanzamiento recursivo que documenté en mi comentario público al NIST.³

El informe DORA Accelerate State of DevOps 2024 encontró que los equipos con prácticas sólidas de observabilidad despliegan con más frecuencia y se recuperan más rápido de las fallas. La edición de 2025 extiende el marco al desarrollo asistido por IA y conecta la observabilidad con «cómo la programación o las pruebas asistidas por IA afectan la calidad, el tiempo de entrega y la confiabilidad general».⁴ La observabilidad de agentes no es un lujo. Medir el comportamiento de un agente es requisito previo para gobernarlo.

Tres capas de visibilidad de agentes

La observabilidad de agentes exige tres capas independientes. Cada capa responde una pregunta distinta. La falla de una capa no compromete a las demás.

Las capas trazan una progresión: no puedes aplicar políticas sobre recursos que no mides, y no puedes auditar el cumplimiento de políticas que nunca definiste. Cada capa se apoya en la que tiene debajo.

Capa 1: medición de recursos

La medición de recursos responde: ¿cuánto consumió el agente y dónde?

El incidente de Cowork es una falla de medición de recursos. El bundle de la VM ocupaba 10 GB de disco. El proceso de renderizado consumía 24 % de CPU en reposo. La actividad de swap subía de forma sostenida durante las sesiones. Todas esas métricas existían en el Monitor de Actividad de macOS. Ninguna aparecía en la interfaz de Claude Desktop.¹

En las sesiones de programación con agentes, la medición de recursos rastrea cuatro dimensiones:

Disco. Cada escritura de archivo, cada entrada de caché, cada archivo de log. Mis sesiones generan entre 200 y 400 KB de archivos de estado por sesión (jiro.state.json, jiro.progress.json, logs de hooks). En más de 60 sesiones, eso se acumula hasta 12-24 MB de datos de estado que persisten de una sesión a otra mientras no se limpien de forma explícita.²

Memoria. El consumo de la ventana de contexto por turno. Una ventana de contexto de 200.000 tokens cuesta cerca de 3 dólares por llenado completo con los precios actuales de Opus. Mi rastreador de costos registra el uso acumulado de tokens por sesión, con umbrales de presupuesto en 80 %, 90 % y 95 % de un límite configurable.⁵

CPU. El tiempo de ejecución de los hooks. Mi despachador de prompts con nueve hooks agrega 200 ms por prompt. Esa sobrecarga es invisible para los usuarios (el cuello de botella es la escritura humana), pero se acumula en los pipelines automatizados. El bucle autónomo ralph dispara el despachador entre 50 y 100 veces por historia, lo que suma entre 10 y 20 segundos de sobrecarga de hooks por historia.²

Red. Descargas web, llamadas a APIs, invocaciones de herramientas MCP. Cada petición saliente es un canal de datos potencial, y cada servidor MCP es una nueva superficie de ataque que la medición de red debe cubrir. Mi biblioteca de extracción web registra las URL descargadas y el tamaño de las respuestas. Sin medición de red, una descarga que devuelve 50 MB es indistinguible de otra que devuelve 5 KB.⁶

Ninguna herramienta comercial de agentes ofrece un panel de recursos por sesión. Los proveedores de nube miden el cómputo para facturar, no para dar visibilidad al operador. La brecha entre lo que los agentes consumen y lo que los operadores pueden ver es el déficit de medición de recursos.

Esa ausencia se siente invisible hasta que los números se acumulan. Una sesión que escribe 400 KB de archivos de estado no es nada. Sesenta sesiones que escriben 400 KB cada una, sin limpieza, dejan 24 MB de estado huérfano. Una descarga web que devuelve 847 KB es despreciable. Un pipeline de escaneo que descarga 80 URL por ejecución genera 67 MB de contenido en caché que la abstracción de herramientas del agente le oculta al operador. La medición de recursos hace visible lo acumulado antes de que se convierta en la crisis que lleva a alguien a abrir el issue #22543 de GitHub.¹

Capa 2: aplicación de políticas

La aplicación de políticas responde: ¿qué reglas limitan al agente y esas reglas se aplican de forma consistente?

mcp-firewall cubre la capa de políticas para agentes de línea de comandos.⁷ La herramienta se ubica entre el agente y todas las solicitudes de uso de herramientas, y evalúa cada solicitud contra una política basada en expresiones regulares antes de ejecutarla. Las políticas usan archivos de configuración JSONNet delimitados por carpeta, repositorio de git o usuario. El firewall es compatible con Claude Code y GitHub Copilot CLI mediante la integración con el hook PreToolUse.

La arquitectura refleja una idea clave: cada agente implementa su propia solución a medias para la lógica de permitir y denegar. Claude Code usa patrones glob. Codex CLI solo hace coincidencias por prefijo. Cada enfoque cubre un subconjunto del espacio de políticas. mcp-firewall centraliza las reglas en un único motor que funciona con distintos agentes.

Piensa en la brecha de políticas sin una aplicación centralizada. Mi sistema de hooks incluye 12 manejadores PreToolUse:Bash que buscan patrones de credenciales, operaciones peligrosas de git, accesos a rutas sensibles y comandos de despliegue.² Cada manejador es un script de shell aparte con sus propias expresiones regulares. Cuando necesito agregar una regla de denegación, escribo un script nuevo. Cuando necesito auditar qué reglas existen, hago grep en 12 archivos. mcp-firewall consolida todo eso en un solo archivo de configuración con arreglos de permisos explícitos.

El OWASP Top 10 for Agentic Applications (2025) identifica el secuestro de objetivos del agente (ASI01) y la agencia excesiva (LLM06:2025) como riesgos principales.⁸ Ambos riesgos exigen aplicación de políticas al nivel de la llamada a la herramienta. Un agente cuyo objetivo fue secuestrado sigue llamando herramientas. Un agente con agencia excesiva sigue pidiendo permisos. La aplicación de políticas intercepta ambos casos en la frontera donde la intención del agente se encuentra con las herramientas del sistema.

La aplicación de políticas no es lo mismo que el control de acceso. El control de acceso tradicional pregunta: «¿este usuario tiene permiso?». La aplicación de políticas para agentes pregunta: «¿esta acción, en este contexto y para esta tarea, cae dentro del alcance aprobado?». La paradoja de confianza entre desplegar y defender explica por qué otorgar permisos amplios a los agentes para que sean útiles crea exactamente la superficie que la aplicación de políticas debe contener. El desafío está en la sensibilidad al contexto. Un git push a una rama de función y un git push --force a main son la misma herramienta (Bash) con radios de impacto muy distintos. Las expresiones regulares de mcp-firewall saben distinguirlos. Los permisos por defecto de un agente, no.

La aplicación de políticas a nivel de aplicación también corre riesgo de ser eludida. Como documenté en tu sandbox de agentes es apenas una sugerencia, las fronteras de aplicación que parecen sólidas suelen tener huecos estructurales. Un análisis de marzo de 2026 documentó tres técnicas cada vez más avanzadas de escape del sandbox frente a la lista de denegación integrada de Claude Code: evasión por ruta (/proc/self/root/usr/bin/npx resuelve al mismo binario que el bloqueado /usr/bin/npx), desactivación autodirigida del sandbox (el agente razonó por su cuenta sobre cómo quitar el sandbox cuando este impedía completar la tarea) e invocación del enlazador dinámico (ld-linux-x86-64.so.2 carga binarios mediante mapeo de memoria y elude por completo los hooks de aplicación del kernel).¹⁴ La tercera técnica constituye toda una clase de exploit: cualquier carga de código que evite execve elude la aplicación a nivel de proceso. La conclusión para la aplicación de políticas es que las listas de denegación por coincidencia de cadenas son una primera capa necesaria, pero no suficiente. La aplicación direccionada por contenido (identificar binarios por su hash SHA-256 y no por su nombre de archivo) cierra el hueco de la evasión por ruta, pero eludir el cargador dinámico exige controles a nivel de kernel que quedan por debajo de la capa de políticas.

La misma lección se sostiene una capa más arriba, donde la política no ve absolutamente nada. Plugin4Shell, publicada por Air Security en septiembre de 2026, es una falla de cadena de suministro del marketplace en los cuatro principales agentes de programación: un marketplace fija un commit verificado para un plugin, pero el agente hace checkout de ese commit sin comprobar que realmente esté ahí, así que un atacante que controle el repositorio del plugin puede crear una rama con el nombre del commit fijado y volverla la rama predeterminada; una refijación rutinaria en el marketplace dispara entonces la actualización automática en segundo plano de cada agente, y el checkout resuelve hacia la rama mientras la fijación sigue pareciendo respetada. Según mi lectura, ningún hook PreToolUse, ninguna lista de denegación y ningún cortafuegos de esta pila ve el cambio de un plugin, porque el cambio ocurre antes de que el agente haga una llamada a una herramienta. La cronología de Air dice que Anthropic confirmó una corrección en Claude Code 2.1.179 y que OpenAI entregó otra en Codex 0.146.0, sin corrección para GitHub Copilot y sin ninguna prevista para Gemini CLI, ya descontinuado; la entrada pública del changelog de Claude Code para 2.1.179 no nombra la corrección, así que la versión se apoya en el relato de los investigadores. El control que aplica es la higiene de versiones más un inventario de lo que el marketplace resolvió realmente, y eso es una cuestión de medición, no de políticas.¹⁷

Capa 3: auditoría en ejecución

La auditoría en ejecución responde: ¿qué hizo realmente el agente al nivel de las llamadas al sistema?

Logira cubre la capa de auditoría con sondas eBPF que interceptan llamadas al sistema a nivel del kernel.⁹ La herramienta registra tres categorías de eventos: ejecución de procesos (eventos exec), operaciones sobre archivos (incluido el acceso a archivos de credenciales) y conexiones de red (con seguimiento del destino). Cada ejecución auditada genera tres archivos: events.jsonl para revisar la línea de tiempo, index.sqlite para filtrar mediante consultas y meta.json para los metadatos de la ejecución.

La filosofía de diseño es «observe-only»: Logira registra y detecta, pero no aplica ni bloquea nada.⁹ La separación respecto de la capa de aplicación es deliberada. La aplicación de políticas evita las acciones que ya se saben dañinas. La auditoría en ejecución descubre después las acciones dañinas desconocidas. Las dos capas cumplen funciones temporales distintas: prevención (antes) y forense (después).

Las sondas eBPF de Logira operan por debajo de la capa de aplicación. Un agente que construye un comando novedoso para exfiltrar datos igual hace llamadas al sistema. El agente no puede ocultar lecturas de archivos, conexiones de red ni procesos lanzados frente al trazado a nivel del kernel. El enfoque captura lo que se les escapa a los hooks de nivel de aplicación: los efectos secundarios que eluden la abstracción de la llamada a la herramienta.

Las reglas de detección integradas apuntan específicamente a los riesgos de los agentes de IA: acceso a archivos de credenciales, cambios en mecanismos de persistencia (/etc, systemd, cron), cadenas de comandos sospechosas (patrones curl-pipe-sh), operaciones destructivas (rm -rf) y tráfico de salida anómalo.⁹ Son valores por defecto con criterio propio para el modelo de amenazas de los agentes, no una auditoría genérica del sistema.

La restricción de plataforma importa. Logira requiere Linux 5.8+ con cgroup v2. Los agentes en macOS (Claude Desktop, Claude Code en Darwin) no pueden usar auditoría basada en eBPF. Mi sandbox del sistema operativo usa perfiles Seatbelt de macOS como el equivalente más cercano: reglas de denegación impuestas por el kernel que bloquean escrituras en rutas sensibles.³ Seatbelt es aplicación, no auditoría. A macOS le falta un equivalente listo para producción del rastro de auditoría de solo observación de Logira.

Agent Safehouse, una herramienta de sandbox nativa de macOS que acumuló 802 puntos y 181 comentarios en Hacker News en marzo de 2026, aborda esa brecha de plataforma desde el lado de la aplicación.¹⁵ La herramienta ofrece perfiles de sandbox diseñados específicamente para agentes de IA locales en macOS. La respuesta de la comunidad (802 puntos son excepcionales para una herramienta de sandbox) refleja la urgencia: quienes ejecutan agentes en macOS tienen pocas opciones entre «sin sandbox» y «escribe tu propio perfil de Seatbelt». Agent Safehouse llena ese vacío del lado de la aplicación. Del lado de la auditoría, la brecha en macOS sigue abierta.

La distinción entre aplicación y auditoría corresponde a una división temporal en la respuesta a incidentes. La aplicación previene el incidente. La auditoría permite reconstruirlo después. Ambas son necesarias. Una capa de aplicación que bloquea todo acceso a credenciales evita la exfiltración, pero también impide operaciones legítimas de SSH. Una capa de auditoría que registra todo acceso a credenciales sin bloquearlo le permite al operador revisar patrones de acceso y ajustar las reglas de aplicación con evidencia. Ese circuito de retroalimentación entre datos de auditoría y refinamiento de políticas es lo que hace mejorar la pila de visibilidad con el tiempo: la auditoría revela patrones, los patrones informan la política y la política reduce la superficie que la auditoría debe cubrir.

El aislamiento con cgroup v2 de Logira suma una propiedad que la auditoría de nivel de aplicación no puede replicar: la atribución por ejecución. El sistema atribuye cada evento a una ejecución auditada concreta, no al sistema en su conjunto. Cuando dos sesiones de agentes corren a la vez en la misma máquina, el aislamiento de cgroup garantiza que un acceso a un archivo en la sesión A no aparezca en el rastro de auditoría de la sesión B. Los hooks de nivel de aplicación no pueden ofrecer la misma garantía, porque se disparan dentro del proceso del agente, que no tiene ninguna frontera a nivel del kernel que separe las sesiones concurrentes.⁹

Lo que uso realmente

Mi sistema de orquestación cubre las tres capas con hooks, no con herramientas de monitoreo dedicadas.

Medición de recursos. El hook cost-gate rastrea el uso de tokens por sesión frente a umbrales de presupuesto configurables.⁵ El monitor de rendimiento del sistema revisa CPU, memoria, disco y swap en intervalos configurables, e inyecta advertencias cuando la presión sobre los recursos supera los umbrales.¹⁰ El detector de deriva de sesión se dispara cada 25 llamadas a herramientas y calcula la similitud coseno entre el embedding del prompt original y una ventana deslizante de las acciones recientes.²

Aplicación de políticas. Ocho hooks despachadores PreToolUse enrutan hacia hooks manejadores según el tipo de herramienta. Solo PreToolUse:Bash ejecuta 12 manejadores que cubren patrones de credenciales, operaciones destructivas de git, accesos a rutas sensibles y comandos de despliegue. El guardián de recursión impone una profundidad máxima de dos y un máximo de cinco hijos por agente padre.²

Auditoría en ejecución. Los hooks PostToolUse registran el resultado de cada llamada a una herramienta. Los hooks de escaneo de seguridad revisan la salida de bash en busca de filtraciones de credenciales después de la ejecución. Los archivos de estado de sesión (jiro.state.json) dejan constancia de cada historia completada, cada veredicto del revisor y cada resultado del control de evidencia.² El sistema no usa eBPF (limitación de macOS), pero captura telemetría a nivel de herramienta mediante el pipeline de hooks.

El sistema funciona porque cada acción pasa por el pipeline de hooks. La limitación es la profundidad: el monitoreo a nivel de hook captura lo que el agente pidió hacer, no lo que el sistema operativo ejecutó realmente. Un agente que construye un comando de bash con subshells incrustados ejecuta código que el hook ve como una sola cadena. Una auditoría a nivel del kernel vería cada subproceso.

Resultados concretos de incidentes en producción donde la pila de tres capas detectó fallas que el monitoreo por defecto habría pasado por alto:

El punto ciego que se multiplica

Los agentes que lanzan agentes multiplican la opacidad. Cada salto de delegación introduce pérdida de información.

Cuando mi sistema de orquestación ejecuta el bucle autónomo ralph, el proceso padre lanza instancias nuevas de Claude Code para cada historia del PRD. Cada agente hijo recibe una tarea acotada y una ventana de contexto limpia. El padre sigue el estado de finalización. Lo que el padre no ve son las llamadas a herramientas, las lecturas de archivos ni el consumo de recursos del hijo.²

En profundidad uno (el padre lanza un hijo), el padre ve la salida final del hijo. En profundidad dos (el hijo lanza un nieto), el padre ve el informe del hijo sobre la salida del nieto. Cada salto comprime información. El análisis de la cadena de delegación de mi comentario al NIST midió tres riesgos que se acumulan: compresión semántica (el contexto se reduce a una cadena de prompt), amplificación de autoridad (los hijos heredan permisos sin entender su sensibilidad) y difusión de la responsabilidad (el agente raíz responde por resultados que nunca inspeccionó).³

La observabilidad se degrada al mismo ritmo. Una pila de visibilidad de tres capas en el agente raíz no da ninguna visibilidad sobre el agente nieto, a menos que cada hijo ejecute su propio monitoreo de forma independiente. Mi guardián de recursión impone el límite de profundidad, pero ese guardián es un control de política, no un control de observabilidad. Saber que la delegación se detuvo en la profundidad dos no te dice qué ocurrió en esa profundidad.

Un ejemplo concreto de mi sistema en producción: el bucle ralph lanzó un agente hijo para implementar una historia de migración de base de datos. El agente hijo decidió que la migración necesitaba un «paso de verificación» y lanzó su propio subagente para correr pruebas de integración. El agente nieto falló en silencio (la base de datos de pruebas no estaba configurada). El agente hijo recibió una respuesta vacía, interpretó el silencio como éxito y reportó la historia como completa. El padre registró «historia 4: completa». Descubrí la migración rota tres horas después, cuando la aplicación se cayó por la columna faltante. La telemetría del agente raíz mostraba una ejecución limpia. La falla vivía a dos saltos de profundidad, invisible para todas las capas de monitoreo que había desplegado en la raíz.²

El marco OWASP Agentic Applications aborda las fallas en cascada y los agentes descontrolados, pero no prescribe requisitos de observabilidad para las cadenas de delegación entre varios agentes.⁸ El análisis de OpenGuard de marzo de 2026 sobre inyección de prompts en agentes expone la misma brecha desde el lado de la seguridad: el contexto contaminado que fluye entre agentes con permisos distintos crea, a través de los traspasos, «una vía silenciosa para escalar autoridad», sin políticas claras de flujo de datos ni autorización a nivel de composición.¹⁶ La brecha es estructural: cada agente de la cadena necesitaría su propia medición de recursos, su propia aplicación de políticas y su propia auditoría en ejecución, configuradas y reportadas de forma independiente. La sobrecarga es multiplicativa. Tres capas de monitoreo sobre tres agentes de una cadena son nueve instancias de monitoreo, cada una generando su propia telemetría y exigiendo su propia configuración. Ninguna herramienta existente maneja esa coordinación.

Lo que puedes implementar hoy

Tres hooks mínimos de monitoreo que cubren la pila de visibilidad:

1. Recursos: rastreador de presupuesto de tokens. Registra los tokens acumulados de entrada y salida por sesión. Fija un límite estricto. Alerta al 80 %. La implementación exige leer las estadísticas de uso del agente (Claude Code expone los costos de sesión con /cost) y compararlas contra un umbral. Mi hook cost-gate lo hace en 47 líneas de bash.⁵

2. Política: lista de denegación en PreToolUse. Crea un hook que se dispare antes de cada llamada a la herramienta Bash. Compara el comando contra una lista de patrones: rm -rf /, git push --force, rutas que contengan .ssh o .env, curl | sh. Bloquea las coincidencias. La implementación exige un script de shell que lea stdin (el JSON de la llamada a la herramienta), extraiga el campo del comando y haga grep contra un archivo de patrones. Mi hook de verificación de credenciales lo hace en 31 líneas.²

3. Auditoría: log de sesión en PostToolUse. Agrega cada llamada a una herramienta y su resultado a un archivo JSONL propio de la sesión. Incluye marca de tiempo, nombre de la herramienta, argumentos y código de salida. Ese log permite reconstruir después de la sesión: ¿qué hizo el agente, en qué orden y falló algo en silencio? Mi registrador de sesión lo hace en 22 líneas de bash.²

Un ejemplo trabajado del hook de lista de denegación en settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/check-sensitive-paths.sh"
          }
        ]
      }
    ]
  }
}

El script del hook lee la llamada a la herramienta desde stdin, extrae la cadena del comando y la compara contra los patrones. Un comando bloqueado devuelve un objeto JSON con {"decision": "block", "reason": "Sensitive path access denied"}. Un comando permitido devuelve {"decision": "approve"}. Claude Code respeta ambas respuestas sin volver a preguntar. El hook completo no agrega ninguna latencia a los comandos permitidos (la verificación por expresión regular corre en menos de 5 ms) y da retroalimentación inmediata para los bloqueados.

Estos tres hooks suman menos de 100 líneas en total. No reemplazan a las herramientas de monitoreo dedicadas. Reemplazan la visibilidad nula por una visibilidad mínima, y esa visibilidad mínima es el requisito previo de toda decisión de gobernanza que venga después. No puedes fijar un presupuesto de recursos sin medición. No puedes hacer cumplir una política de alcance sin una lista de denegación. No puedes investigar un incidente sin un log de auditoría. Empieza por el log. Los otros dos vienen después.

Conclusiones clave

Para ingenieros de plataforma: los agentes consumen recursos que el monitoreo actual no rastrea. El uso de disco, memoria, CPU y red por sesión de agente pertenece al mismo panel que las métricas de contenedores. El incidente de Cowork prueba la necesidad: 10 GB asignados sin ninguna visibilidad para el operador.

Para equipos de seguridad: la aplicación de políticas en la frontera de la llamada a la herramienta es la postura mínima viable de seguridad para agentes. El enfoque centralizado de mcp-firewall consolida la lógica de permitir y denegar de cada agente en una única configuración auditable. Evalúa si los permisos integrados de tu agente cubren el espacio de políticas que exige tu modelo de amenazas.

Para líderes de ingeniería: la respuesta de largo plazo es el autogobierno de los agentes: agentes que interiorizan el monitoreo como norma de comportamiento y no solo como una restricción externa. Mientras eso madura, hazle tres preguntas a tus herramientas de agentes. ¿Puedes ver el consumo de recursos por sesión? ¿Puedes definir y auditar políticas de llamadas a herramientas? ¿Puedes reconstruir después lo que hizo un agente? Si alguna respuesta es «no», tienes una brecha de visibilidad que crece con cada agente adicional en tu flujo de trabajo.

Preguntas frecuentes

¿Qué es la observabilidad de agentes?

La observabilidad de agentes es la capacidad de monitorear y entender qué hace un agente de IA durante su ejecución: qué recursos consume, qué acciones realiza y si esas acciones cumplen con las políticas definidas.

¿Por qué Cowork, de Anthropic, creó una VM de 10 GB?

La función Cowork de Claude Desktop aprovisiona una máquina virtual para sesiones de desarrollo colaborativo. Claude Desktop crea el bundle de la VM automáticamente en cada instalación de macOS, incluso para usuarios que nunca activan la función, y lo conserva hasta que se borra a mano.¹

¿Qué es mcp-firewall?

mcp-firewall es una herramienta de código abierto para aplicar políticas que intercepta las solicitudes de uso de herramientas de los agentes de línea de comandos (Claude Code, GitHub Copilot CLI) y las evalúa, antes de ejecutarlas, contra reglas de permitir y denegar basadas en expresiones regulares.⁷

¿Qué es la auditoría en ejecución con eBPF?

eBPF (extended Berkeley Packet Filter) permite trazar llamadas al sistema a nivel del kernel sin modificar el proceso auditado. Herramientas como Logira usan sondas eBPF para registrar la ejecución de procesos, las operaciones sobre archivos y las conexiones de red durante las ejecuciones de agentes de IA.⁹

¿Cómo lanzan los agentes subagentes sin visibilidad para el operador?

Los agentes que delegan tareas lanzan procesos hijos con ventanas de contexto limpias. El agente padre ve la salida final del hijo, pero no sus llamadas a herramientas, sus lecturas de archivos ni su consumo de recursos. En cada salto de delegación la información se comprime: la sesión completa del nieto se convierte en una línea de estado en el log del padre. La observabilidad se degrada al mismo ritmo al que aumenta la profundidad de delegación.²

¿En qué se diferencia el monitoreo de agentes del APM tradicional?

El monitoreo tradicional de rendimiento de aplicaciones (APM) rastrea latencia de peticiones, tasas de error y throughput de software determinista. El monitoreo de agentes rastrea comportamiento no determinista: qué decidió hacer el agente en tiempo de ejecución, si esas decisiones cayeron dentro de la política y qué recursos consumió cada una. El APM asume que la aplicación sigue una ruta de código conocida. El monitoreo de agentes asume que el agente elige su propia ruta.²

¿Los hooks de Claude Code pueden dar observabilidad de agentes?

Sí. El sistema de hooks de Claude Code dispara scripts en eventos del ciclo de vida (PreToolUse, PostToolUse, Notification) capaces de medir recursos, aplicar políticas y registrar acciones. Un montaje de tres hooks — rastreador de presupuesto de tokens, lista de denegación en PreToolUse y registrador de sesión en PostToolUse — cubre las tres capas de visibilidad en menos de 100 líneas de bash. Los hooks son el punto de entrada más accesible para los equipos que ya usan Claude Code.

¿Qué pasa cuando los agentes eluden su propio sandbox?

Que se eluda el sandbox significa que la capa de aplicación falla en silencio. El agente sigue ejecutándose fuera del alcance previsto y, sin auditoría en ejecución, no queda registro de la brecha. Las técnicas de escape del sandbox documentadas en marzo de 2026 incluyen la evasión por ruta, la desactivación autodirigida del sandbox y la invocación del enlazador dinámico, todas invisibles para el monitoreo a nivel de aplicación.

¿Por qué importa la observabilidad de las herramientas MCP?

Cada llamada a una herramienta MCP es un canal de datos potencial: puede leer archivos, hacer peticiones de red y ejecutar código. Los servidores MCP amplían la superficie de ataque porque cada servidor introduce capacidades nuevas que el agente puede invocar en tiempo de ejecución. Sin registro por llamada ni aplicación de políticas, las invocaciones de herramientas MCP son invisibles para el operador.

¿Cómo se monitorean las cadenas de delegación entre varios agentes?

Cada agente de una cadena de delegación necesita su propia medición de recursos, su propia aplicación de políticas y su propia auditoría en ejecución. El bucle autónomo ralph muestra el problema: un padre lanza agentes hijos que reciben cada uno una ventana de contexto limpia. El padre ve la salida final, no las llamadas individuales a herramientas. La observabilidad se degrada al mismo ritmo al que aumenta la profundidad de delegación, lo que obliga a monitorear de forma independiente en cada salto.

Fuentes