LangSmith Sandboxes pone el debate incómodo: el agente que ejecuta código necesita su propia computadora

LangChain viene empujando una frase que resume bien el cambio de infraestructura: cada agente necesita una computadora. El punto no es poético. Entre el 5 y el 12 de junio de 2026, la empresa publicó material sobre LangSmith Sandboxes y una guía para elegir sandboxes de agentes, con una tesis clara: si tu agente escribe y ejecuta código, ya no estás solo construyendo una API; estás operando máquinas efímeras para trabajo no confiable.

Eso es especialmente relevante para builders de Latinoamérica que empiezan con contenedores locales, scripts rápidos y “ya luego aislamos mejor”. Ese camino sirve para prototipos. En producción, el agente puede instalar paquetes, abrir archivos, leer datos, levantar servidores, llamar red y persistir estado. Si todo eso ocurre cerca de tu infraestructura real, el blast radius crece rápido.

El criterio de decisión

No todo agente necesita sandbox. Un bot que solo llama APIs fijas con schemas estrictos puede vivir con permisos acotados y buenos logs. Pero un agente que genera scripts, clona repos, instala dependencias, procesa archivos de usuario o corre notebooks necesita otro tipo de frontera.

La guía de LangChain ordena la evaluación alrededor de controles concretos:

• filesystem aislado;
• red limitada por destino;
• límites de CPU, memoria y tiempo;
• reusabilidad controlada del estado;
• aislamiento a nivel de kernel, no solo proceso.

La parte más incómoda es la última. Docker ayuda, pero un contenedor comparte kernel con el host. Para código no confiable, esa frontera puede ser insuficiente. LangSmith Sandboxes apuesta por microVMs hardware-virtualizadas: una máquina separada, con su propio kernel, que puede desaparecer al terminar o persistir cuando el flujo lo necesita.

El error común: confundir velocidad con seguridad

Muchos equipos evalúan sandboxes por tiempo de arranque y experiencia del agente. Eso importa, porque una sesión que espera dos minutos por ambiente pierde utilidad. Pero el criterio incompleto lleva a malas decisiones: “arranca rápido” no significa “puede contener un prompt injection con salida de red”.

El marco práctico es la llamada lethal trifecta: acceso a datos sensibles, exposición a contenido no confiable y capacidad de comunicarse hacia afuera. Si tu agente tiene las tres, necesitas reducir al menos una con controles reales.

Para un agente de coding, eso suele verse así:

1. montar solo el repo o subset necesario;
2. bloquear endpoints externos salvo allowlist;
3. inyectar secretos por proxy, no como variables visibles para el agente;
4. limitar duración y recursos por corrida;
5. guardar trazas de comandos, procesos y llamadas de red.

Qué cambia para productos con agentes

El lanzamiento importa porque vuelve producto una pieza que muchos equipos estaban resolviendo de forma artesanal. Sandboxes no son solo “ejecución segura”; también habilitan snapshots, forks, ambientes pre-calentados, URLs autenticadas para previews y estado que puede sobrevivir una tarea larga.

Eso afecta directamente a agentes de soporte técnico, data analysis, CI, contenido programático y revisión de código. Si el agente puede correr el trabajo, ver el error, corregir y volver a validar, pasa de sugerir a operar. Pero esa capacidad solo es aceptable si puedes explicar dónde corrió, con qué límites y cómo se limpió.

La demanda se infiere por señales actuales: publicaciones oficiales de LangChain, discusión constante sobre sandboxes, agentes de coding y seguridad ante prompt injection. No invento volumen de búsqueda. Sí hay una intención clara en queries como AI agent sandbox, LangSmith Sandboxes, microVM agents y secure code execution agents.

La conclusión para builders es simple: si el agente ejecuta código dinámico, el sandbox no es una optimización. Es parte del producto.