La mayoría de los frameworks de agentes hoy en día asumen un escritorio. Un usuario, una máquina, un proceso. El agente se ejecuta mientras la laptop está abierta, escribe en un sistema de archivos local, guarda las claves API en variables de entorno y muere cuando se cierra la terminal. Cuando algo falla, el usuario reintenta. Cuando el agente necesita un paquete, pip install lo coloca en el Python del usuario. El estado, los secretos y el ciclo de vida residen dentro de un único límite de confianza.
La infraestructura de agentes en la nube no tiene ninguno de esos lujos.
El agente se ejecuta en un sandbox que arranca desde cero, en hardware compartido con desconocidos, activado por emisores que el usuario nunca conoce: un programador, una solicitud HTTP, otro agente. El usuario normalmente está durmiendo cuando ocurre la ejecución. El código dentro del sandbox puede ser adversario. El sistema de archivos debe sobrevivir a los despliegues. Las credenciales no pueden vivir donde vive el agente. Cada garantía que el escritorio te da gratuitamente —persistencia, identidad, confianza en la red, reintentos— debe reconstruirse como un sistema explícito.
Pasamos los últimos meses ajustando esa capa en CREAO. Salieron dos lecciones. Si alguna vez has enviado un agente de escritorio y te has preguntado qué cambia cuando se traslada a la nube, esto es lo que cambia.
Lección 1: Separa lo que cambia lentamente de lo que cambia rápido
En un escritorio, el entorno del usuario y el runtime del agente son la misma cosa, actualizados con la misma cadencia, por la misma persona. En la nube, no lo son.
Una aplicación agente acumula estado en el lado de la plataforma. Un analista de acciones instala matplotlib, descarga datos del mercado, escribe scripts de gráficos. Ese entorno es la memoria muscular del agente. Lo congelamos en una instantánea del sandbox en el momento en que el usuario está satisfecho, y mantenemos esa instantánea congelada hasta que el usuario edite el entorno nuevamente. Cada ejecución arranca desde la misma imagen. Los mismos paquetes, los mismos archivos, las mismas versiones. La ejecución del lunes se comporta como la del viernes, porque nada debajo se ha movido.
Esta es la propiedad que los frameworks de escritorio no pueden darte gratuitamente. Un pip install de hace seis meses se resuelve en versiones diferentes hoy. Una instantánea en la nube se resuelve en los mismos bytes para siempre. La reproducibilidad es algo que la plataforma le debe al usuario, y una instantánea congelada es la forma más barata de proporcionarla.
Luego aparece el problema del acoplamiento.
La misma imagen que congela el entorno del usuario también contiene el código del runner —la pequeña biblioteca de arnés desarrollada por nosotros que gestiona el agente en cada ejecución. El usuario quiere que su entorno permanezca quieto. Nosotros queremos que nuestro runner se despliegue muchas veces al día. Un artefacto, dos requisitos opuestos.
Nuestra primera solución fue contundente. Al arrancar, verificar si el runner dentro de la instantánea coincide con la versión que acabamos de desplegar. Si no es así, desechar la instantánea y arrancar desde una plantilla limpia. Funcionó y nadie se quejó. El daño solo afectaba a la primera ejecución después de un despliegue.
Las ejecuciones no supervisadas eliminaron esa cobertura. Un cron job a las 9 a.m. del lunes no debería perder su entorno porque desplegamos a las 8:55 a.m. El contrato que estábamos violando silenciosamente —"tu entorno está congelado hasta que lo cambies"—.
Nos tomó más tiempo del que debería darnos cuenta de la solución. El entorno del usuario y el código del runner cambian a velocidades completamente diferentes. El usuario edita su agente cuando lo decide. Nosotros desplegamos la plataforma muchas veces al día. Tratarlos como un solo artefacto forzaba una decisión en cada despliegue: mantener código runner obsoleto o destruir el entorno congelado que el usuario nos pidió explícitamente que preserváramos.
El modelo al que llegamos toma prestado de cómo los sistemas operativos manejan las actualizaciones. El kernel cambia. Tu directorio personal no. No borras el disco para instalar un parche de seguridad.
Trazamos el mismo límite. El sandbox arranca desde la instantánea congelada del usuario, intacta. Luego intercambiamos en caliente solo el runner. La secuencia:
- Colocar el nuevo runner en un directorio temporal dentro del sandbox.
- Validarlo con node --check para que cualquier error de sintaxis se detecte antes de tocar algo en vivo.
- Intercambiarlo atómicamente: desbloquear el flag inmutable en el runner anterior, copiar el nuevo, volver a bloquear con chattr +i, luego ocultar el propio binario chattr para que el código del sandbox no pueda revertir el bloqueo.
- Purgar el caché de compilación de V8 (/home/user/.cache/v8-compile-cache/*) para que el nuevo archivo realmente se cargue en lugar de ejecutar bytecode obsoleto.
- Si algún paso falla, eliminar el sandbox y reintentar con uno nuevo. Nunca se ejecuta un agente con un estado medio actualizado.
Todo el intercambio toma unos 300 milisegundos. Hacemos una nueva instantánea después de una ejecución exitosa solo cuando se intercambió el código del runner, integrando el código actualizado en la imagen del usuario para que la próxima ejecución omita el intercambio por completo. Los despliegues de la plataforma nunca descartan el estado del usuario; lo pliegan dentro del nuevo runner. Los paquetes, archivos y personalizaciones del usuario continúan sin cambios.
Si te llevas algo de esta lección, es la pregunta de diagnóstico. Para cualquier cosa que persistas en una plataforma en la nube, pregúntate: ¿quién controla la cadencia de cambio de este artefacto? Si tanto el usuario como la plataforma lo poseen, eventualmente pagarás por el acoplamiento. Divide el artefacto a lo largo del límite de propiedad y deja que cada lado se actualice en su propio reloj.
Lección 2: Mantén los secretos fuera del límite de ejecución
Esta es la lección que separa la infraestructura de agentes en la nube de todo lo demás.
Un agente de escritorio se ejecuta como el usuario. Usa las claves del usuario, en la máquina del usuario, contra la red del usuario. Un agente en la nube se ejecuta como nadie, en hardware compartido, contra internet abierto, ejecutando código que un LLM escribió a partir de un prompt que pudo haber sido adversario. El modelo de seguridad debe asumir que el código dentro del sandbox ya está comprometido, no esperar lo contrario.
La regla que mantenemos es simple. Ninguna credencial de larga duración vive jamás dentro del sandbox.
Cuando un agente necesita llamar a un servicio autenticado —Slack, GitHub, la propia API del usuario— no tiene el token. Envía una solicitud HTTP local a un puente API que se ejecuta fuera del sandbox. El puente adjunta el token OAuth en el lado del host y reenvía la llamada. La respuesta regresa sin que el token entre jamás en la memoria o el entorno del sandbox.
La parte interesante es cómo el puente sabe que el sandbox está autorizado a preguntar. Dos verificaciones, en capas intencionadamente.
Primero, lista blanca de IP. El puente solo acepta conexiones del rango de red interna en el que residen nuestros hosts de sandbox. Una llamada desde cualquier otro lugar —una laptop de desarrollador, una URL filtrada, internet público— se descarta en la capa de red antes de que se ejecute cualquier código de aplicación. Esto fija el puente a una pieza de infraestructura física y lo vuelve inútil para cualquiera fuera de ella.
Segundo, un JWT de corta duración acuñado por ejecución. Cuando un sandbox arranca, la plataforma firma un token con alcance para esa ejecución específica: qué usuario, qué aplicación, qué sesión, con una caducidad que cubre la ventana de ejecución y nada más. El sandbox lo presenta en cada llamada al puente. El puente verifica la firma, comprueba la caducidad y solo entonces resuelve las credenciales almacenadas del usuario y las adjunta en el lado del servidor. Si un sandbox es secuestrado, el atacante hereda un token que muere con la ejecución y solo autoriza llamadas con alcance para esa sesión. No hay una credencial maestra que robar.
El mismo puente saca las deducciones de facturación, los registros y las métricas, por lo que es la única interfaz que cruza el límite del sandbox en cualquier dirección. Todo lo demás dentro del sandbox se trata como comprometido por defecto.
Si una inyección de prompt convence a un agente de volcar process.env a un webhook mañana, el atacante obtiene un JWT de corta duración que solo funciona desde dentro de nuestra red y caduca con la ejecución. Esa propiedad es lo que nos permite ejecutar código de usuario no confiable en infraestructura compartida sin perder el sueño.
El patrón subyacente
La infraestructura de agentes en la nube confiable y segura no es un sistema novedoso. Son unas pocas propiedades mantenidas sin excepción:
- El estado vive en el sandbox, congelado hasta que el usuario lo cambie.
- El código es intercambiable en caliente, independiente del estado.
- Las credenciales viven en el lado del host, nunca dentro del agente.
- Un único pipeline de ejecución sirve a todos los emisores, ya sea el disparador un humano, un programador u otro software.
Esa última propiedad es el remate de todo el diseño. Una función executeAgent maneja clics de UI, ejecuciones programadas y llamadas API. El sistema de facturación, los registros de deducción de créditos, las señales de observabilidad —todos idénticos independientemente de si un humano hizo clic en Ejecutar, un cron disparó o un script llamó a la API. Agregar una nueva superficie de disparador es un cambio de enrutamiento, no un cambio de arquitectura. El agente mismo no sabe ni le importa quién apretó el gatillo.
Eso es lo que los frameworks de escritorio no pueden darte, y lo que hace que valga la pena construir la versión en la nube. Un agente en una laptop está ligado a la laptop. Un agente en la nube es una función que el resto de tu stack puede llamar. El usuario lo escribe una vez. La plataforma lo hace sobrevivir a los despliegues, ejecutarse de forma segura en hardware compartido y aceptar emisores que el usuario nunca anticipó.
Un agente es una función con una interfaz de lenguaje natural. Su implementación pertenece al usuario. Su superficie de disparo, su runtime, su límite de seguridad pertenecen a la plataforma. La disciplina es construir las capas para que cada una evolucione en su propio reloj, y dedicar el tiempo a encontrar las grietas entre los sistemas antes de que alguien más lo haga.
Eso es lo que hace que la próxima superficie sea barata de enviar, y segura de enviar.
