《Arquitectura de sandbox de Agent de Openclaw: de la elección técnica a una historia de seguridad comprensible para el público》 Dos modos Imagina que necesitas contratar a un guardia de seguridad para que cuide de tu casa. Tienes dos opciones: Opción uno: el guardia vive en tu casa, pero tiene su caja de herramientas guardada en una caja fuerte. El guardia puede moverse y ver tu casa, pero no tiene la llave. Opción dos: el guardia vive en un puesto afuera, y no hay nada en tu casa para él. Si quiere tomar algo, tiene que buscar a tu mayordomo. La empresa Browser Use (que opera millones de Web Agents) eligió la opción dos. Su historia, en realidad, está relacionada con cada persona que utiliza AI.

Dos, ¿Cómo se usa el navegador? Inicialmente usaron la opción uno: el Agente se ejecuta en su propio servidor, y la ejecución del código se realiza en una sandbox aislada. Suena bastante seguro, ¿verdad? Pero hay un problema: el Agente en sí sigue en el servidor, puede ver las variables de entorno, las claves API y las credenciales de la base de datos. ¿Qué pasaría si el Agente decidiera "robar algo"?

Tres, por lo que reescribieron toda la arquitectura: • Agente completamente aislado: cada Agente corre en su propio micro-VM de Unikraft, el arranque tarda menos de un segundo • Plano de control como mayordomo: toda la comunicación externa (ajustar LLM, almacenar archivos, facturación) pasa por el plano de control, que posee todas las credenciales • Sandbox sin conocimiento: el Agente solo recibe tres variables de entorno: token de sesión, URL del plano de control, ID de sesión. Sin claves de AWS, sin credenciales de base de datos • Desechabilidad: ¿El Agente ha muerto? Reinicia uno. ¿Se perdió el estado? El plano de control tiene el contexto completo. No tiene nada que valga la pena robar, ni ningún estado que necesite ser retenido.

Cuatro, Detalles técnicos: micro-VM de Unikraft para producción (scale-to-zero, se suspende cuando está inactivo), contenedores Docker para desarrollo. La misma imagen en todas partes. Desde la perspectiva de una persona común: ¿qué tiene que ver esto conmigo? Puede que no sepas qué son las "micro-VM" o las "URLs prefirmadas", pero cuando usas AI, estás tratando con este tipo de arquitectura.

Cinco, Sensación de seguridad: cuando utilizas un servicio de IA para escribir código o buscar información, en realidad están ejecutando tu solicitud en una VM aislada. Si la arquitectura está mal diseñada (opción uno), teóricamente ese Agente de IA podría ver todos los secretos del proveedor del servicio: contraseñas de bases de datos, claves API, datos de otros usuarios.

Seis, Coste y velocidad: la opción dos tiene un precio: cada operación implica un salto adicional en la red. Pero comparado con el tiempo de respuesta de LLM, esta pequeña latencia es casi despreciable. Más importante aún, cuando el Agente está inactivo, la VM se suspende, lo que hace que el coste sea casi cero. Privacidad de los datos: ¿cómo se almacenan tus archivos? La sandbox solicita una URL presignada al plano de control y luego se sube directamente a S3. Durante todo el proceso, la sandbox no ha visto la clave de AWS. Tus datos no se filtrarán al Agente.

Siete, Mis reflexiones: Local vs Nube Mi configuración actual (OpenClaw + LM Studio + x-reader) es un típico "modo local": • El modelo se ejecuta localmente (Qwen3.5-35B en RTX 3090) • El Agente no está aislado (porque está en tu computadora) • Datos completamente locales Esto en comparación con la solución de Uso del Navegador: Dimensiones Agente local único (nosotros) Agente aislado en la nube (Uso del Navegador) Privacidad Los datos no salen de local Los datos se suben a la nube, pero el Agente no puede obtener la clave Seguridad Depende de la protección local Agente completamente aislado, sin nada que robar Costo Inversión de hardware única Pago por uso (escalado a cero) Escalabilidad Limitada por el hardware local Escalabilidad infinita, múltiples Agentes en paralelo Latencia Cero latencia de red Un salto de red adicional (pero se puede ignorar)

Ocho, mi juicio: el futuro será un modo híbrido. • Tareas simples se ejecutan localmente: escribir un script, buscar información, organizar archivos, todo esto se puede hacer localmente, con buena privacidad y velocidad. • Tareas complejas en la nube: se necesita paralelizar múltiples Agentes, procesar grandes cantidades de datos y ejecutar durante mucho tiempo, en este caso, usar una arquitectura como Browser Use es más adecuado.

Nueve, Originalmente no hay nada, ¿de dónde viene el polvo? Tu Agente no debería tener nada que valga la pena robar, ni ningún estado que necesite ser conservado. En otras palabras: • No vale la pena robar: el Agente no sabe ningún secreto. ¿Necesita tokens para ajustar el LLM? Los proporciona el plano de control, se usan y se desechan. ¿Necesita almacenar archivos? La URL prefirmada es temporal, caduca y se invalida. • No necesita conservar: ¿el Agente ha muerto? Reinicia uno nuevo. ¿Recuerda el contexto? Hay un registro completo en la base de datos del plano de control. Esto es en realidad la aplicación de la arquitectura de confianza cero en la era de la IA: no confíes en ningún componente, ni siquiera en tu propio Agente.

Diez, ¿Cómo debería un principiante en IA aprender? 1. Selección de herramientas de IA: al utilizar servicios de IA en la nube, pregúntate: ¿qué podría obtener este agente si se descontrola? Una buena arquitectura debería hacer que esté "totalmente desinformado". 2. Conciencia de la privacidad: ejecutar IA localmente para tareas simples (OpenClaw, LM Studio), sin subir datos sensibles a la nube. Para tareas complejas, utilizar soluciones de aislamiento en la nube, pero ten en cuenta que los datos saldrán de tu local. 3. Flujo de trabajo futuro: la colaboración de una persona + múltiples agentes es la tendencia (lo que Karpathy llama Tab→Agente→Agentes Paralelos→Equipos de Agentes). Pero cada agente debe estar aislado, no debe "vivir en tu casa".

Once, Equilibrio entre seguridad y eficiencia La solución de Browser Use no es perfecta: hay que desplegar tres servicios más y cada operación implica un salto de red adicional. Pero comparado con el riesgo de que "el Agente robe todas las claves", estos costos valen la pena. Para nosotros, que tenemos un setup de IA local, la lección es: • Escenarios simples: seguir usando la solución local (OpenClaw + LM Studio), buena privacidad, bajo costo • Escenarios complejos: en el futuro podría ser necesario conectar con servicios de Agente aislados en la nube, dejando que los profesionales hagan su trabajo La seguridad de la IA no es una cuestión esotérica, es diseño arquitectónico. Un buen diseño hace que el Agente "no tenga nada" — sin secretos que robar, sin estados de los que hacerse responsable.

Doce, Así es como probablemente será la infraestructura de IA en el futuro: los agentes son desechables, el plano de control es confiable y los datos de los usuarios están protegidos. ¿Y nosotros? Continuamos usando OpenClaw para ejecutar agentes locales, y cuando llegue el día en que necesitemos ejecutar decenas o cientos en paralelo, consideraremos integrar una arquitectura como Browser Use. Mañana será mejor.