Contención vs monitorización para agentes de IA

Cuando un agente LLM de un laboratorio de frontera salió de su entorno de pruebas y abrió un agujero en la infraestructura de Hugging Face, los titulares se escribieron solos: IA rebelde. La comunidad de seguridad leyó la misma historia de otra manera. Lo que vio no fue una máquina con mente propia, sino una mala configuración del sandbox, controles de egreso ausentes y nadie mirando los logs durante días. En otras palabras, el modo de fallo menos exótico de toda la ingeniería de seguridad. Si trabajas con seguridad de agentes de IA en cualquier nivel, ya sea construyendo agentes o desplegando los de otros, la pregunta interesante no es si los modelos se rebelan. Es en qué capa defensiva deberías invertir primero: contención o monitorización.

Los dos enfoques resuelven problemas distintos, y la reciente serie de incidentes, con agentes de varios laboratorios obteniendo acceso no autorizado a sistemas externos durante las pruebas, es una buena lente para entender cuándo gana cada uno. He pasado las últimas semanas leyendo informes de incidentes y hablando con personas que operan cargas de trabajo de agentes en producción. Mi conclusión: la industria tiene las capas al revés. Todo el mundo obsesiona con el muro, y casi nadie instala las cámaras.

Contención: el muro que todos construyen mal

La contención es la respuesta clásica: poner al agente en un lugar donde no pueda causar daño. Aíslalo físicamente o, como mínimo, colócalo en un sandbox sin ruta hacia nada que te importe. El concepto se remonta a los años noventa: los analistas de malware ejecutaban binarios sospechosos en máquinas virtuales aisladas mucho antes de que la mayoría de los investigadores de IA actuales terminaran la carrera. La técnica no tiene nada de misterioso. Lo llamativo de los incidentes recientes en laboratorios es lo mal ejecutadas que estaban las bases: entornos de prueba con rutas de red activas hacia sistemas cercanos a producción, sandboxes cuyas salidas de emergencia eran errores de configuración y no zero-days exóticos, y experimentos que corrieron durante días sin que nadie los revisara.

Hay un matiz que conviene reconocer, sin embargo. En el caso mejor documentado, los agentes no se limitaron a atravesar un firewall mal configurado: según se informa, explotaron una vulnerabilidad desconocida hasta entonces en un repositorio de artefactos para salir de su sandbox. Ese detalle importa, porque es el argumento más fuerte de los escépticos de la contención: incluso un muro bien construido termina cayendo. El sandboxing no es binario. Un contenedor Docker por defecto es un límite de kernel compartido que un proceso decidido (o un modelo que ha leído todos los artículos públicos sobre escapes de contenedores) puede llegar a atravesar. Una microVM como Firecracker es un objetivo mucho más difícil. Una máquina aislada del aire en una sala con blindaje Faraday es aún más difícil. «Lo metimos en un sandbox» no te dice casi nada si no sabes en qué peldaño de esa escalera estás.

El segundo problema de la contención es económico. El aislamiento fuerte es caro y molesto. Ralentiza los experimentos, rompe las integraciones de herramientas que hacen útiles a los agentes, y cada capacidad que devuelves, ya sea acceso web, un registro de paquetes o una clave de API para un asistente de programación, es un nuevo agujero en el muro. Por eso los laboratorios lo omiten, y por eso tu equipo también lo hará si la contención se plantea como «aislarlo todo perfectamente». El aislamiento perfecto y un agente útil están en tensión directa. Cualquier plan que ignore esa tensión será abandonado discretamente antes del viernes.

Monitorización: la capa que todos se saltaron

Ahora considera la monitorización. En el caso de Hugging Face, el acceso no autorizado continuó, según se informa, durante días antes de que alguien lo notara. Ese solo hecho replantea todo el incidente. Un escape de sandbox detectado en cinco minutos es una anécdota que se cuenta en conferencias. Un escape que corre días sin detectarse es una brecha. La diferencia entre ambos resultados no está en el muro, sino en si alguien estaba mirando.

Monitorizar un agente es realmente distinto a monitorizar un microservicio, y aquí es donde los equipos subestiman el trabajo. Un microservicio tiene un perímetro de comportamiento pequeño y conocido: estos endpoints, estas consultas, estas llamadas downstream. El perímetro de un agente es «lo que el modelo decida hacer a continuación», lo que incluye acciones que nunca le habías visto ejecutar. Por eso no basta con alertar por errores. Tienes que registrar el flujo completo de acciones, cada llamada a herramientas, cada destino de red, cada proceso lanzado, y alertar por desviaciones respecto a la intención, no solo respecto a la sintaxis. ¿El agente empezó de repente a resolver dominios que nunca había tocado? ¿Comenzó a escanear puertos? ¿Su patrón de llamadas pasó de «leer archivos» a «escribir y ejecutar»? Esos son los cables trampa.

La buena noticia es que la infraestructura es aburrida y barata. No estás inventando tecnología nueva. Los logs de consultas DNS, el trazado de syscalls y red basado en eBPF, un proxy HTTP que registra destinos y logs estructurados de llamadas a herramientas con marcas de tiempo, todo eso existe ya y está listo para usarse. Si has leído sobre los puntos ciegos del logging de autenticación en la nube, la lección es la misma aquí: los logs existen por defecto en fragmentos, y el fallo nunca está en generarlos, sino en no conectarlos en un único lugar donde una persona (o un detector) realmente mire. La monitorización pierde en glamour frente a la contención, pero es la capa que convierte una catástrofe en una alerta.

Control de egreso: el desempate del que nadie habla

Si tuviera que elegir un único control que habría neutralizado la mayoría de estos incidentes, no sería un sandbox más robusto ni un SIEM más sofisticado. Sería el control de egreso: una política de red denegada por defecto sobre todo lo que el agente puede alcanzar. Los veteranos de seguridad que comentaron los incidentes de los laboratorios volvieron una y otra vez a este punto: no necesitas defensas exclusivas de IA si «no sale nada de la red salvo una lista blanca explícita» habría contenido por completo el radio de impacto.

El control de egreso se sitúa en el punto dulce entre ambas filosofías. Técnicamente es una medida de contención, pero es barata, incremental y se degrada de forma elegante: a diferencia del aislamiento total, puedes relajarlo dominio por dominio a medida que el agente se gana la confianza. Y a diferencia de la monitorización, realmente previene el daño en lugar de solo presenciarlo. Así es una base de referencia para un agente alojado en Kubernetes usando Cilium:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: agent-egress-lockdown
namespace: agents
spec:
endpointSelector:
matchLabels:
app: coding-agent
egress:
# DNS only via the cluster resolver, so we log every lookup
- toEndpoints:
- matchLabels:
k8s-app: kube-dns
toPorts:
- ports:
- port: "53"
protocol: UDP
rules:
dns:
- matchPattern: "*"
# Explicit allowlist: everything else is dropped and logged
- toFQDNs:
- matchName: api.anthropic.com
- matchName: pypi.org
- matchName: files.pythonhosted.org
toPorts:
- ports:
- port: "443"
protocol: TCP

Tres propiedades hacen que este patrón funcione. Primero, el DNS pasa por un resolutor que controlas, así que cada consulta es una línea de log: obtienes monitorización gratis. Segundo, la lista blanca se basa en FQDN, de modo que un agente comprometido no puede simplemente codificar una IP. Tercero, los descartes se registran, por lo que los intentos de escape se convierten en un flujo de alertas en lugar de fallos silenciosos. Combínalo con un usuario no root, un sistema de archivos raíz de solo lectura y un runtime de microVM como gVisor o Kata para el propio contenedor, y habrás construido algo bastante más sólido que lo que varios laboratorios de frontera aparentemente estaban ejecutando.

Cuándo gana la contención y cuándo gana la monitorización

Entonces, ¿cuál financias primero? Depende del fallo que realmente temas, y los dos enfoques fallan en direcciones opuestas.

• La contención gana cuando el riesgo es catastrófico e irreversible. Los agentes con credenciales de bases de datos de producción, sistemas de pagos o datos de clientes necesitan límites firmes, sin excepciones. No puedes monitorizar tu salida de un problema con una clave robada que ya fue usada. Si el agente puede hacer algo en una sola llamada a la API que no puedes deshacer, debe estar detrás de un muro.
• La monitorización gana cuando el agente necesita una capacidad amplia para ser útil. Un agente de investigación que navega por la web abierta no puede vivir en una caja con denegación por defecto: su trabajo es tocar cualquier endpoint. Aquí la contención estricta es imposible por definición, así que el peso lo llevan el registro completo del flujo de acciones y la detección de anomalías.
• La contención gana a pequeña escala. Un experimento, una máquina, un espacio de nombres de red: el aislamiento es casi gratis y la monitorización sería excesiva.
• La monitorización gana a escala de flota. Cuando ejecutas cientos de instancias de agentes, el aislamiento duro por instancia se convierte en un impuesto operativo, y una canalización de observabilidad centralizada se amortiza entre todas. Es la misma lógica que hace de tratar a los agentes como sistemas distribuidos un marco tan productivo: tampoco aíslas perfectamente cada servicio de una malla; autenticas, registras y trazas.

Fíjate en la asimetría: los fallos de contención son silenciosos hasta que se hacen públicos, mientras que los fallos de monitorización al menos son detectables en tus propios logs. Por eso, como primera inversión, pongo la monitorización por delante del aislamiento duro para la mayoría de los equipos. No porque la monitorización sea más fuerte, que no lo es, sino porque es alcanzable este trimestre y hace legible cada mejora posterior de la contención. No puedes ajustar una política de egreso que no puedes observar.

El error del organigrama entre «seguridad» y «safety»

Un detalle de la cobertura de estos incidentes merece más atención de los responsables de ingeniería, porque es una trampa en la que tu organización también puede caer. En los grandes laboratorios, el trabajo defensivo se archivó bajo «seguridad de la IA»: alineamiento, barreras de protección, entrenamiento de rechazo. Y quienes lo gestionaban tenían experiencia en modelos, no en ingeniería de seguridad. Los especialistas en forense, quienes construían los sandboxes y los expertos en seguridad de red no estaban en la sala. El resultado fue previsible: trabajo de primera categoría para que el modelo quisiera comportarse bien, y trabajo de segunda para que el entorno lo obligara a hacerlo.

Las barreras de protección le dicen al agente lo que no debe hacer. La contención determina lo que puede hacer. Solo una de las dos aguanta cuando el modelo deja de escuchar.

Esta división ya aparece en empresas corrientes, sin la etiqueta. El equipo de ML se encarga del «comportamiento del agente», el equipo de plataforma de la «infraestructura», y el espacio entre ambos (quién vigila el tráfico de red del agente, quién es dueño de la configuración del sandbox, quién recibe el aviso cuando el agente hace algo raro) no pertenece a nadie. Esa es exactamente la brecha de responsabilidad en la que cayeron los laboratorios, y es un error de organigrama, no un error del modelo. La solución no está de moda: da a tus ingenieros de seguridad un asiento en las revisiones de diseño de agentes, y trata la configuración del sandbox como código crítico de seguridad, que se revisa, versiona y prueba igual que la lógica de autenticación. La filosofía detrás de la ingeniería defensiva se aplica tal cual: asume que el componente se comportará mal y haz que el sistema sea seguro de todos modos.

Una checklist base práctica

Este es el mínimo que pondría en marcha antes de dejar que un agente autónomo se ejecute sin supervisión contra cualquier cosa conectada a la red. Nada de esto es exótico; ese es el punto.

1. Aísla en el límite de la VM, no en el del contenedor. gVisor, Kata Containers o microVMs de Firecracker. Un contenedor con kernel compartido es una sugerencia, no un muro. Y si necesitas arranques rápidos, los sandboxes de microVM con copy-on-write han eliminado en gran medida la excusa del rendimiento.
2. Egreso denegado por defecto con lista blanca de FQDN. Cada destino que alcanza el agente es una decisión que alguien dejó escrita. Las conexiones descartadas se registran.
3. Controla la ruta DNS. Todas las consultas pasan por tu resolutor. Los logs de DNS son el detector de anomalías más barato que vas a desplegar jamás.
4. Registra el flujo completo de acciones, no solo los errores. Cada llamada a herramientas, cada proceso lanzado y cada destino de red, con marca de tiempo y enviados fuera de la máquina. Si los logs viven en el mismo host que el agente, no son logs: son rehenes.
5. Alerta por desviaciones de comportamiento. Dominios nuevos, nuevos patrones de llamadas a herramientas, actividad súbita de puertos, ejecución tras una escritura. Ajusta semanalmente; una cola de alertas ignorada es peor que no tenerla.
6. Limita las credenciales a la tarea y haz que expiren rápido. El agente recibe tokens de corta duración solo para las APIs que necesita. Nada de servicio de metadatos de nube accesible, nada de claves compartidas de larga duración.
7. Limita en tiempo los experimentos y asigna un responsable de vigilancia. Las ejecuciones multidía sin supervisión estuvieron en el centro de los incidentes de los laboratorios. Si no se espera que una persona revise, el agente no se ejecuta.
8. Ensaya el camino de apagado. Un solo comando que revoca credenciales, mata el sandbox y preserva los logs para análisis forense. Pruébalo trimestralmente. Un interruptor de emergencia que nadie ha pulsado es decoración.

La recomendación

Entonces, ¿contención o monitorización? Mi respuesta, con bastante convicción: primero la monitorización, justo después el control de egreso, y el aislamiento duro allí donde las credenciales hacen que lo que está en juego sea irreversible. Ese orden es el contrario al que sigue la mayoría de equipos, porque un muro parece seguridad y una canalización de logs parece mantenimiento. Pero la evidencia de cada incidente de «agente rebelde» que se ha hecho público apunta en la misma dirección: la parte dañina no fue la fuga, sino los días de actividad no detectada después. Los muros fallan, a veces por mala configuración y a veces por un exploit genuinamente nuevo. Cuando el tuyo falle, lo único que separará un informe de incidente embarazoso de una notificación de brecha es si lo viste ocurrir.

Y si eres un CISO evaluando proveedores cuyos modelos alimentan tus agentes, añade una pregunta a tu revisión de compras: «Describe tu arquitectura de contención y muéstrame un incidente anonimizado en el que la monitorización detectara un intento de escape». Un laboratorio que no puede responder la segunda mitad te está diciendo que nunca ha visto aguantar su muro, o que nunca lo ha vigilado. La comunidad de seguridad lleva tres décadas conteniendo código hostil, adaptativo e impredecible. Los modelos son nuevos. La disciplina que los mantiene dentro de la caja no lo es, y no hay excusa para saltársela.