Problema
Un agente que solo redacta texto puede fallar con poco daño. Un agente que ejecuta codigo, consulta sistemas privados, instala dependencias, escribe archivos o toca infraestructura falla en otro plano.
El error ya no es una respuesta mala. Es un side effect.
Muchas empresas intentan resolverlo con prompts: “no hagas nada peligroso”. Eso no es un control. Es una esperanza escrita en lenguaje natural.
Tesis
Sandboxed Work sera el nuevo perimetro de los agentes que hacen trabajo real.
El punto no es encerrar al modelo. El modelo no ejecuta. El punto es encerrar la accion: filesystem, red, secretos, herramientas, procesos, tiempo, coste y permisos.
La arquitectura madura separa cerebro, orquestador, sandbox y sistemas de destino.
Framework
Un sandbox agentico debe definir cinco limites:
- Filesystem: que puede leer, crear o modificar.
- Network: que endpoints puede tocar y desde donde.
- Secrets: que credenciales se inyectan y durante cuanto tiempo.
- Tools: que comandos, APIs o MCP servers puede invocar.
- Timebox: cuanto dura el trabajo antes de matar el entorno.
Mini-caso: un agente de soporte reproduce un bug de cliente. En un sandbox puede clonar repo, instalar dependencias, correr tests, leer logs sanitizados y proponer un patch. En una maquina compartida puede contaminar entorno, filtrar secretos o dejar procesos vivos.
Senal medible: porcentaje de acciones agenticas con entorno efimero, logs y limites declarados.
Postura: si el agente puede ejecutar, tambien debe poder ser contenido.
Por que importa ahora
Cloudflare ha empujado sandboxes para agentes como entornos aislados y escalables. Anthropic ha presentado Managed Agents con sandboxes externos y MCP tunnels. AWS ha llevado MCP a operaciones cloud con IAM, CloudWatch, CloudTrail y ejecucion acotada.
La tendencia no es solo “mas agentes”. Es agentes con manos.
Y cuando un sistema tiene manos, necesita guantes, sala limpia y registro de movimientos.
Anti-ejemplo
“Tenemos un runner compartido para todos los agentes.”
Eso mezcla contextos, permisos y residuos de ejecucion. Un agente de exploracion no deberia vivir en el mismo perimetro que un agente que toca produccion.
Protocolo (3 pasos)
- Clasifica acciones por riesgo. Lectura, escritura, ejecucion, red privada, secretos y produccion.
- Crea sandboxes por clase. No uses el mismo entorno para investigacion, build y sistemas sensibles.
- Destruye por defecto. El entorno debe expirar, registrar y limpiar.
| Capa | Control minimo | Pregunta operativa |
|---|---|---|
| filesystem | directorio aislado | que puede leer |
| red | allowlist | a donde puede llamar |
| secretos | tokens efimeros | cuanto duran |
| herramientas | permisos por tool | que puede hacer |
| tiempo | timeout | cuando muere |
Relacionado
- Claude Managed Agents + Cloudflare: el perimetro se convierte en producto
- AWS MCP Server GA: cuando los agentes de coding entran en cloud con guardrails
- AI Traces: la capa que convierte agentes en sistemas auditables
Fuentes consultadas
Proximo paso
Dibuja un diagrama de ejecucion de tu agente mas peligroso: modelo, orquestador, sandbox, secretos, red, herramientas, logs y sistema destino. Si no sabes donde esta el limite, aun no tienes perimetro.