El agente invisible: por qué no puede gobernar lo que no puede ver

Anthropic lanzó una función llamada Cowork en Claude Desktop. La función creó un paquete de máquina virtual de 10GB en cada instalación de macOS. Los usuarios que nunca habilitaron Cowork igualmente recibieron la VM. Los usuarios que la eliminaron observaron cómo se regeneraba. Un usuario reportó que el paquete creció hasta 21GB. 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 el espacio en disco se agotó.

TL;DR

Las herramientas de agentes ahora asignan recursos de cómputo (disco, memoria, CPU, red) sin visibilidad para el operador. La VM de Cowork de Anthropic es el ejemplo visible; cada llamada a herramientas MCP, cada sub-agente generado y cada solicitud web es un ejemplo invisible. Gobernar agentes requiere tres capas de observabilidad: medición de recursos (¿qué consumió?), aplicación de políticas (¿qué tenía permitido hacer?) y auditoría en tiempo de ejecución (¿qué hizo realmente?). Dos proyectos de código abierto abordan las capas de política y auditoría (mcp-firewall y Logira), pero ninguna herramienta en producción cubre las tres. A continuación: el problema de visibilidad, el stack de tres capas, qué detecta cada capa y los hooks mínimos de monitoreo que puede implementar hoy.

El problema de visibilidad

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

Los sistemas de agentes invierten la relación. El agente decide qué ejecutar en tiempo de ejecución. Un agente de programación que recibe “arregla el endpoint de login” podría leer 47 archivos, escribir en 12, generar tres sub-agentes, solicitar dos páginas web y ejecutar 15 comandos bash. Cada acción consume recursos. Ninguno de esos consumos aparece en el monitoreo tradicional.

El incidente de Cowork expuso la inversión a nivel de infraestructura. Claude Desktop asignó 10GB de espacio en disco, consumió entre 24 y 55% de CPU en reposo y elevó el uso de swap de 20K a más de 24K swapins en máquinas con 8GB.¹ Los usuarios descubrieron el consumo de recursos a través de las advertencias de almacenamiento de macOS, no a través de la telemetría de Anthropic. La aplicación no proporcionó ningún panel de control, ningún medidor ni ninguna divulgación de aceptación para la asignación de la VM.

Escale el patrón a sesiones de agentes. Mi sistema de orquestación de hooks intercepta 15 tipos de eventos en cada llamada a herramientas.¹¹ A lo largo de 60 sesiones, el sistema registró 84 hooks disparándose en cada acción, produciendo telemetría que ninguna instalación predeterminada de agentes proporciona.² Sin esa instrumentación, no habría detectado los 12 incidentes de desviación, las fallas de verificación fantasma ni los bucles de generación recursiva documentados en mi comentario público al NIST.³

El DORA 2024 Accelerate State of DevOps Report encontró que los equipos con prácticas sólidas de observabilidad despliegan con mayor frecuencia y se recuperan más rápido de las fallas. La edición 2025 extiende el marco al desarrollo asistido por IA, conectando 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 algo opcional. Medir el comportamiento de los agentes es un prerrequisito para gobernarlos.

Tres capas de visibilidad de agentes

La observabilidad de agentes requiere tres capas independientes. Cada capa responde a una pregunta diferente. Una falla en una capa no compromete las demás.

Las capas se corresponden con una progresión: no se pueden aplicar políticas sobre recursos que no se miden, y no se pueden auditar políticas que nunca se definieron. Cada capa se construye sobre la anterior.

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 paquete de la VM consumió 10GB de espacio en disco. El proceso del renderizador consumió 24% de CPU en reposo. La actividad de swap creció constantemente durante las sesiones. Todas estas métricas existían en el Monitor de Actividad de macOS. Ninguna apareció en la interfaz de Claude Desktop.¹

Para sesiones de agentes de programación, 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 400KB de archivos de estado por sesión (jiro.state.json, jiro.progress.json, logs de hooks). A lo largo de 60 sesiones, eso se acumula a 12-24MB de datos de estado que persisten entre sesiones a menos que se limpien explícitamente.²

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

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

Red. Solicitudes web, llamadas a API, invocaciones de herramientas MCP. Cada solicitud saliente es un canal potencial de datos. Mi biblioteca de extracción web registra las URLs solicitadas y los tamaños de respuesta. Sin medición de red, una solicitud web que devuelve una respuesta de 50MB es indistinguible de una que devuelve 5KB.⁶

Ninguna herramienta comercial de agentes proporciona un panel de recursos por sesión. Los proveedores de nube miden el cómputo para facturación, no para visibilidad del 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.

La ausencia se siente invisible hasta que los números se acumulan. Una sesión que escribe 400KB de archivos de estado es insignificante. Sesenta sesiones que escriben 400KB cada una, sin limpieza, dejan 24MB de estado huérfano. Una solicitud web que devuelve 847KB es despreciable. Un pipeline de escaneo que solicita 80 URLs por ejecución genera 67MB de contenido en caché que la abstracción de herramientas del agente 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 reportar el issue GitHub #22543.¹

Capa 2: Aplicación de políticas

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

mcp-firewall aborda la capa de políticas para agentes CLI.⁷ La herramienta se interpone entre el agente y todas las solicitudes de uso de herramientas, evaluando cada solicitud contra una política basada en regex antes de la ejecución. Las políticas utilizan archivos de configuración JSONNet con alcance por carpeta, repositorio git o usuario. El firewall es compatible con Claude Code y GitHub Copilot CLI mediante integración con hooks PreToolUse.

La arquitectura refleja una observación clave: cada agente implementa su propia solución parcial de lógica de permitir/denegar. Claude Code usa patrones glob. Codex CLI usa coincidencia solo por prefijo. Cada enfoque cubre un subconjunto del espacio de políticas. mcp-firewall centraliza las reglas en un solo motor que funciona entre agentes.

Considere la brecha de políticas sin aplicación centralizada. Mi sistema de hooks incluye 12 manejadores PreToolUse:Bash que verifican patrones de credenciales, operaciones peligrosas de git, acceso a rutas sensibles y comandos de despliegue.² Cada manejador es un script de shell separado con sus propios patrones regex. Cuando necesito añadir una nueva regla de denegación, escribo un nuevo script. Cuando necesito auditar qué reglas existen, hago grep en 12 archivos. mcp-firewall consolida todo eso en un único archivo de configuración con arrays 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 requieren aplicación de políticas a nivel de llamadas a herramientas. Un agente que secuestra un objetivo aún realiza llamadas a herramientas. Un agente con agencia excesiva aún solicita permisos. La aplicación de políticas intercepta ambos en el límite donde la intención del agente se encuentra con las herramientas del sistema.

La aplicación de políticas difiere del control de acceso. El control de acceso tradicional pregunta “¿tiene este usuario permiso?” La aplicación de políticas para agentes pregunta “¿esta acción, en este contexto, para esta tarea, cae dentro del alcance aprobado?” La sensibilidad al contexto es el desafío. Un git push a una rama de funcionalidad y un git push --force a main son la misma herramienta (Bash) con radios de impacto diferentes. Los patrones regex de mcp-firewall pueden distinguir entre ellos. Los permisos predeterminados de los agentes no pueden.

Capa 3: Auditoría en tiempo de ejecución

La auditoría en tiempo de ejecución responde: ¿qué hizo realmente el agente a nivel de syscalls?

Logira aborda la capa de auditoría utilizando sondas eBPF para interceptar llamadas al sistema a nivel de kernel.⁹ La herramienta registra tres categorías de eventos: ejecución de procesos (eventos exec), operaciones de archivos (incluyendo acceso a archivos de credenciales) y conexiones de red (con seguimiento de destino). Cada ejecución auditada genera tres archivos: events.jsonl para revisión cronológica, index.sqlite para filtrado mediante consultas e meta.json para metadatos de la ejecución.

La filosofía de diseño es “solo observar”: Logira registra y detecta pero no aplica ni bloquea.⁹ La separación de la capa de aplicación es deliberada. La aplicación de políticas previene acciones conocidas como malas. La auditoría en tiempo de ejecución descubre acciones desconocidas como malas después del hecho. Las dos capas sirven funciones temporales diferentes: prevención (antes) y análisis 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 aún realiza syscalls. El agente no puede ocultar lecturas de archivos, conexiones de red ni generación de procesos del rastreo a nivel de kernel. El enfoque captura lo que los hooks a nivel de aplicación pierden: efectos secundarios que evitan la abstracción de llamadas a herramientas.

Las reglas de detección integradas apuntan específicamente a riesgos de 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 egreso de red anómalo.⁹ Las reglas son valores predeterminados con criterio para el modelo de amenazas de agentes, no 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 de SO usa perfiles Seatbelt de macOS como el equivalente más cercano: reglas de denegación aplicadas a nivel de kernel que bloquean escrituras a rutas sensibles.³ Seatbelt es aplicación, no auditoría. macOS carece de un equivalente listo para producción del registro de auditoría de solo observación de Logira.

La distinción entre aplicación y auditoría se corresponde con una división temporal en la respuesta a incidentes. La aplicación previene el incidente. La auditoría permite la reconstrucción después del incidente. Ambas son necesarias. Una capa de aplicación que bloquea todo acceso a credenciales previene la exfiltración pero también previene operaciones legítimas de SSH. Una capa de auditoría que registra todo acceso a credenciales sin bloquear permite al operador revisar patrones de acceso y ajustar las reglas de aplicación basándose en evidencia. El ciclo de retroalimentación entre datos de auditoría y refinamiento de políticas es cómo el stack de visibilidad mejora con el tiempo: la auditoría revela patrones, los patrones informan las políticas, las políticas reducen la superficie que la auditoría necesita cubrir.

El aislamiento cgroup v2 de Logira añade una capacidad que la auditoría a nivel de aplicación no puede replicar: atribución con alcance por ejecución. El sistema atribuye cada evento a una ejecución auditada específica, no al sistema globalmente. Cuando dos sesiones de agentes se ejecutan concurrentemente en la misma máquina, el aislamiento por cgroup asegura que el acceso a archivos en la sesión A no aparezca en el registro de auditoría de la sesión B. Los hooks a nivel de aplicación no pueden proporcionar la misma garantía porque los hooks se disparan dentro del proceso del agente, que no tiene un límite a nivel de kernel que separe las sesiones concurrentes.⁹

Lo que realmente ejecuto

Mi sistema de orquestación cubre las tres capas a través de hooks, no a través de herramientas de monitoreo dedicadas.

Medición de recursos. El hook cost-gate rastrea el uso de tokens por sesión contra umbrales de presupuesto configurables.⁵ El monitor de rendimiento del sistema verifica CPU, memoria, disco y swap a intervalos configurables, inyectando advertencias cuando la presión de recursos excede los umbrales.¹⁰ El detector de desviación de sesión se dispara cada 25 llamadas a herramientas, calculando la similitud coseno entre el embedding del prompt original y una ventana deslizante de acciones recientes.²

Aplicación de políticas. Ocho hooks del despachador PreToolUse enrutan hacia hooks manejadores por tipo de herramienta. PreToolUse:Bash por sí solo ejecuta 12 manejadores que cubren patrones de credenciales, operaciones destructivas de git, acceso a rutas sensibles y comandos de despliegue. El guard de recursión aplica una profundidad máxima de dos y un máximo de cinco hijos por agente padre.²

Auditoría en tiempo de ejecución. Los hooks PostToolUse registran el resultado de cada llamada a herramientas. Los hooks de escaneo de seguridad verifican la salida de bash en busca de fugas de credenciales después de la ejecución. Los archivos de estado de sesión (jiro.state.json) registran cada historia completada, veredicto del revisor y resultado de la evaluación de evidencia.² El sistema no usa eBPF (limitación de macOS) pero captura telemetría a nivel de herramientas a través del 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 hooks captura lo que el agente pidió hacer, no lo que el sistema operativo realmente ejecutó. Un agente que construye un comando bash con subshells embebidas ejecuta código que el hook ve como una sola cadena de texto. La auditoría a nivel de kernel vería cada subproceso.

El punto ciego que se acumula

Los agentes que generan 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 genera instancias frescas de Claude Code para cada historia de PRD. Cada agente hijo recibe una tarea enfocada y una ventana de contexto nueva. El padre rastrea el estado de completitud. El padre no ve las llamadas individuales a herramientas, lecturas de archivos ni el consumo de recursos del hijo.²

A profundidad uno (el padre genera al hijo), el padre ve la salida final del hijo. A profundidad dos (el hijo genera al nieto), el padre ve el reporte del hijo sobre la salida del nieto. Cada salto comprime información. El análisis de cadenas de delegación en mi comentario al NIST midió tres riesgos que se acumulan: compresión semántica (el contexto colapsa a una cadena de prompt), amplificación de autoridad (los hijos heredan permisos sin comprender la sensibilidad) y difusión de responsabilidad (el agente raíz asume la responsabilidad de resultados que nunca inspeccionó).³

La observabilidad se degrada al mismo ritmo. Un stack de visibilidad de tres capas sobre el agente raíz proporciona cero visibilidad sobre el agente nieto a menos que cada hijo ejecute independientemente su propio monitoreo. Mi guard de recursión aplica el límite de profundidad, pero el guard es un control de políticas, no un control de observabilidad. Saber que la delegación se detuvo en profundidad dos no indica qué sucedió en profundidad dos.

Un ejemplo concreto de mi sistema en producción: el bucle ralph generó 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 generó su propio sub-agente para ejecutar pruebas de integración. El agente nieto falló silenciosamente (la base de datos de prueba no estaba configurada). El agente hijo recibió una respuesta vacía, interpretó el silencio como éxito y reportó la historia como completada. El padre registró “historia 4: completada”. 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 mostró una ejecución limpia. La falla vivía a dos saltos de profundidad, invisible para cada capa de monitoreo que había desplegado en la raíz.²

El marco OWASP Agentic Applications aborda fallas en cascada y agentes descontrolados pero no prescribe requisitos de observabilidad para cadenas de delegación multi-agente.⁸ La brecha es estructural: cada agente en la cadena necesitaría su propia medición de recursos, aplicación de políticas y auditoría en tiempo de ejecución, configuradas independientemente y reportadas independientemente. La sobrecarga es multiplicativa. Tres capas de monitoreo en tres agentes en una cadena son nueve instancias de monitoreo, cada una generando su propia telemetría, cada una requiriendo su propia configuración. Ninguna herramienta existente gestiona esa coordinación.

Lo que puede implementar hoy

Tres hooks mínimos de monitoreo que cubren el stack de visibilidad:

1. Recursos: Rastreador de presupuesto de tokens. Registre los tokens de entrada y salida acumulados por sesión. Establezca un límite estricto. Alerte al 80%. La implementación requiere leer las estadísticas de uso del agente (Claude Code expone los costos de sesión vía /cost) y compararlas contra un umbral. Mi hook cost-gate hace esto en 47 líneas de bash.⁵

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

3. Auditoría: Log de sesión PostToolUse. Agregue cada llamada a herramienta y su resultado a un archivo JSONL específico de la sesión. Incluya marca de tiempo, nombre de herramienta, argumentos y código de salida. El log permite la reconstrucción post-sesión: ¿qué hizo el agente, en qué orden y algo falló silenciosamente? Mi logger de sesión hace esto en 22 líneas de bash.²

Un ejemplo funcional 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 herramienta desde stdin, extrae la cadena del comando y verifica contra 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 solicitar confirmación adicional. El hook completo añade cero latencia a los comandos aprobados (la verificación regex se ejecuta en menos de 5ms) y proporciona retroalimentación inmediata para los bloqueados.

Estos tres hooks requieren menos de 100 líneas en total. No reemplazan herramientas de monitoreo dedicadas. Reemplazan visibilidad cero con visibilidad mínima. La visibilidad mínima es el prerrequisito para cada decisión de gobernanza que sigue. No puede establecer un presupuesto de recursos sin medición. No puede aplicar una política de alcance sin una lista de denegación. No puede investigar un incidente sin un registro de auditoría. Comience con el registro. Los otros dos le siguen.

Conclusiones clave

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

Para equipos de seguridad: La aplicación de políticas en el límite de llamadas a herramientas es la postura mínima viable de seguridad de agentes. El enfoque centralizado de mcp-firewall consolida la lógica de permitir/denegar por agente en una sola configuración auditable. Evalúe si los permisos integrados de su agente cubren el espacio de políticas que requiere su modelo de amenazas.

Para gerentes de ingeniería: Haga tres preguntas sobre sus herramientas de agentes: ¿Puede ver el consumo de recursos por sesión? ¿Puede definir y auditar políticas de llamadas a herramientas? ¿Puede reconstruir lo que hizo un agente después del hecho? Si alguna respuesta es “no”, tiene una brecha de visibilidad que crece con cada agente adicional en su flujo de trabajo.

Preguntas frecuentes

¿Qué es la observabilidad de agentes? La observabilidad de agentes es la capacidad de monitorear y comprender lo que 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 10GB? La función Cowork en Claude Desktop provisiona una máquina virtual para sesiones de desarrollo colaborativo. Claude Desktop crea el paquete de la VM automáticamente en cada instalación de macOS, incluso para usuarios que nunca habilitan la función, y lo mantiene hasta que se elimina manualmente.¹

¿Qué es mcp-firewall? mcp-firewall es una herramienta de aplicación de políticas de código abierto que intercepta solicitudes de uso de herramientas de agentes CLI (Claude Code, GitHub Copilot CLI) y las evalúa contra reglas de permitir/denegar basadas en regex antes de la ejecución.⁷

¿Qué es la auditoría en tiempo de ejecución con eBPF? eBPF (extended Berkeley Packet Filter) permite el rastreo a nivel de kernel de llamadas al sistema sin modificar el proceso auditado. Herramientas como Logira utilizan sondas eBPF para registrar la ejecución de procesos, operaciones de archivos y conexiones de red durante las ejecuciones de agentes de IA.⁹

Fuentes