Durante gran parte de 2024 y principios de 2025, la conversación sobre agentes de IA estuvo dominada por capacidades: mejores modelos, más herramientas, contexto más largo, workflows más autónomos.
Ahora la conversación está cambiando.
La pregunta ya no es solamente:
“¿Qué puede hacer el agente?”
La pregunta que los equipos de plataforma y seguridad están empezando a hacer es mucho más importante:
“¿Qué pasa cuando el agente hace algo que no debería?”
Ese cambio de enfoque está empujando una nueva arquitectura operacional que aparece cada vez más en herramientas enterprise, frameworks open source y documentación de seguridad:
containment-first agents
La idea es simple:
asumir desde el diseño que el agente eventualmente se va a equivocar, desviarse, alucinar o abusar de permisos.
Y construir el sistema alrededor de esa realidad.
El problema: los agentes ya no son chatbots
Un chatbot tradicional produce texto.
Un agente moderno:
- ejecuta comandos
- modifica archivos
- llama APIs
- interactúa con infraestructura
- usa credenciales
- despliega código
- corre tests
- opera browsers
- toma decisiones multi-step
Eso lo convierte en una entidad operacional.
Y las entidades operacionales necesitan límites.
La mayoría de los incidentes recientes alrededor de agentes tienen el mismo patrón de fondo:
- permisos demasiado amplios
- aislamiento insuficiente
- herramientas sin restricciones
- contexto contaminado
- ejecución no auditada
El problema no es necesariamente que el modelo sea “malo”.
El problema es que estamos conectando sistemas probabilísticos a superficies de ejecución reales.
Por qué “prompt engineering” no alcanza
Durante mucho tiempo, muchas organizaciones trataron la seguridad de agentes como un problema de prompting:
NO MODIFIQUES PRODUCCIÓN
NO BORRES ARCHIVOS
NO EJECUTES COMANDOS PELIGROSOS
Eso funciona hasta que deja de funcionar.
Porque los prompts no son boundaries de seguridad.
Son instrucciones probabilísticas.
Y cuando:
- el contexto cambia
- una herramienta responde distinto
- el agente entra en loops
- aparece prompt injection
- el razonamiento deriva
…las instrucciones blandas dejan de ser suficientes.
La industria está empezando a aceptar una realidad incómoda:
los agentes necesitan restricciones técnicas reales, no solo reglas textuales.
Qué significa “containment-first”
Containment-first significa diseñar el entorno operativo suponiendo que el agente puede comportarse de manera incorrecta.
Eso cambia completamente la arquitectura.
En lugar de:
Modelo → Herramientas → Producción
el patrón pasa a ser algo más parecido a:
Modelo
↓
Policy Layer
↓
Sandbox / Runtime aislado
↓
Herramientas limitadas
↓
Aprobación humana (cuando aplica)
↓
Sistemas reales
La seguridad deja de depender de “esperar que el agente entienda”.
Empieza a depender de:
- aislamiento
- permisos mínimos
- observabilidad
- recuperación
- límites de ejecución
Exactamente igual que en infraestructura distribuida tradicional.
El patrón más importante: permisos mínimos
La mayoría de los agentes actuales tienen demasiado acceso.
Ejemplos comunes:
- acceso completo al filesystem
- acceso total al repo git
- tokens de cloud reutilizados
- credenciales compartidas
- navegación web irrestricta
- shells sin sandbox
Containment-first invierte esta lógica.
El agente recibe:
- solo las herramientas necesarias
- solo los directorios necesarios
- solo los permisos necesarios
- solo durante el tiempo necesario
No diferente de cómo ya operamos:
- containers
- IAM roles
- Kubernetes service accounts
- temporary credentials
La diferencia es que ahora la entidad que consume esos permisos es un sistema probabilístico.
Sandboxes: el nuevo runtime estándar
Uno de los cambios más visibles de 2026 es la adopción acelerada de entornos aislados para agentes.
Cada vez más herramientas:
- ejecutan código dentro de containers efímeros
- aíslan filesystem
- bloquean networking por defecto
- separan credenciales
- limitan persistencia
Porque un agente que:
- genera código
- lo ejecuta
- observa resultados
- reitera automáticamente
…sin sandbox, es básicamente RCE asistido por IA.
Y eso cambia completamente el modelo de riesgo.
El problema de prompt injection cambia todo
Los sistemas agénticos introducen una superficie nueva:
prompt injection indirecto
Ejemplo:
- el agente navega una página
- la página contiene instrucciones ocultas
- el modelo las interpreta como contexto válido
- el agente ejecuta acciones no previstas
Esto no es teórico.
Es exactamente el tipo de ataque que aparece naturalmente cuando:
- modelos consumen contenido externo
- herramientas tienen capacidad de ejecución
- el contexto no está aislado
Containment-first asume que eventualmente va a ocurrir.
Por eso:
- herramientas sensibles requieren aprobación
- los outputs externos se sanitizan
- las capacidades críticas se separan
- los agentes no reciben acceso irrestricto
Observabilidad: la pieza que faltaba
Otro patrón fuerte:
execution tracing
Los equipos quieren saber:
- qué decidió el agente
- qué herramienta usó
- qué contexto vio
- qué outputs produjo
- qué comandos ejecutó
- qué falló
- por qué tomó una acción
Esto está empujando:
- logs estructurados
- tracing de herramientas
- replay de sesiones
- snapshots de contexto
- auditoría de decisiones
En otras palabras:
AI observability empieza a parecerse muchísimo a distributed systems observability.
Los agentes ya se están diseñando como jobs distribuidos
OpenAI, Anthropic, LangGraph, OpenHands y otros ecosistemas están convergiendo hacia patrones similares:
- retries
- checkpoints
- state persistence
- lifecycle APIs
- resumable execution
- workflow durability
Eso no es casualidad.
La industria está descubriendo que los agentes no son “UX de chat”.
Son runtimes operacionales.
Y los runtimes operacionales necesitan:
- control
- recuperación
- límites
- aislamiento
El error más común hoy
Muchos equipos todavía despliegan agentes así:
LLM + tools + production access
sin:
- sandboxes
- límites de permisos
- policy layer
- aprobación humana
- observabilidad seria
Eso funciona en demos.
No necesariamente sobrevive contacto con producción.
Qué están haciendo los equipos más maduros
Los patrones que más aparecen hoy:
1. Tool gating
El agente puede:
- leer archivos
pero no:
- escribir
- ejecutar
- desplegar
sin aprobación explícita.
2. Sandboxes efímeros
Cada sesión:
- container nuevo
- filesystem aislado
- networking limitado
- cleanup automático
3. Credenciales temporales
Nada persistente.
Tokens:
- scoped
- rotativos
- revocables
4. Runtime policies
Capas explícitas de reglas:
- qué herramientas existen
- cuándo pueden ejecutarse
- qué comandos están prohibidos
- qué rutas son válidas
5. Human-in-the-loop
Las acciones sensibles:
- requieren aprobación
- quedan auditadas
- pueden revertirse
La dimensión LATAM
Para equipos en América Latina, containment-first tiene una ventaja importante:
reduce riesgo operacional sin requerir organizaciones gigantes.
Muchos equipos regionales:
- operan lean
- tienen menos margen para incidentes
- trabajan con infraestructura compartida
- manejan budgets cloud sensibles
En ese contexto:
- un agente con permisos excesivos
- un loop runaway
- un deploy incorrecto
- una filtración accidental
…pueden tener impacto desproporcionado.
Containment-first permite adoptar automatización AI sin asumir niveles de riesgo difíciles de absorber operacionalmente.
El cambio cultural
Hay una transición cultural interesante ocurriendo.
Durante años:
- más autonomía
- menos fricción
- más acceso
- más herramientas
eran vistos como progreso natural para agentes.
Ahora empieza a emerger otra filosofía:
los mejores agentes no son los más libres.
Son los más gobernables.
Qué deberían hacer hoy los equipos
Antes de desplegar agentes en workflows reales:
Revisar permisos
- ¿Qué puede tocar realmente el agente?
- ¿Qué pasa si se equivoca?
Aislar ejecución
- Containers
- VMs efímeras
- Filesystems temporales
Agregar observabilidad
- logs
- tracing
- replay
- auditoría
Introducir policy layers
- límites explícitos
- reglas técnicas
- no solo prompts
Diseñar rollback
- reversión rápida
- checkpoints
- recovery workflows
Veredicto
Containment-first agents probablemente se convierta en el patrón dominante de seguridad para IA operacional.
No porque los modelos empeoren.
Sino porque los agentes están dejando de ser asistentes pasivos y empezando a operar sistemas reales.
Y cualquier sistema que:
- ejecuta acciones
- usa herramientas
- modifica infraestructura
- toma decisiones autónomas
…eventualmente necesita las mismas propiedades que exigimos del resto de nuestra infraestructura:
- aislamiento
- observabilidad
- control
- recuperación
- governance
La industria finalmente está empezando a tratar a los agentes como lo que realmente son: