Problema
Un agente que solo redacta texto puede fallar con poco daño. Un agente que ejecuta código, 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 perímetro de los agentes que hacen trabajo real.
El punto no es encerrar al modelo. El modelo no ejecuta. El punto es encerrar la acción: filesystem, red, secretos, herramientas, procesos, tiempo, coste y permisos.
La arquitectura madura separa cerebro, orquestador, sandbox y sistemas de destino.
Framework
Un sandbox agéntico 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 máquina compartida puede contaminar entorno, filtrar secretos o dejar procesos vivos.
Señal medible: porcentaje de acciones agénticas con entorno efimero, logs y limites declarados.
Postura: si el agente puede ejecutar, también 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 ejecución 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 ejecución. Un agente de exploración no debería vivir en el mismo perímetro que un agente que toca producción.
Protocolo (3 pasos)
- Clasifica acciones por riesgo. Lectura, escritura, ejecución, red privada, secretos y producción.
- Crea sandboxes por clase. No uses el mismo entorno para investigación, build y sistemas sensibles.
- Destruye por defecto. El entorno debe expirar, registrar y limpiar.
| Capa | Control mínimo | 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 perímetro 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
Próximo paso
Dibuja un diagrama de ejecución 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 perímetro.