OpenClaw 2.0 busca atraer a las empresas, pero sus configuraciones de seguridad por defecto ya generan preocupación
OpenClaw evoluciona. Con su versión 2.0, la plataforma de código abierto para agentes de IA no solo asiste a un usuario aislado; introduce sesiones compartidas, roles de equipo, una nueva interfaz web y una gestión más estructurada de secretos, convirtiéndose en una herramienta colaborativa para las empresas.
Sin embargo, este avance trae consigo un importante paradoja. OpenClaw ahora ofrece mecanismos avanzados de sandboxing y control de acceso, pero mantiene la aislamiento de los agentes desactivada por defecto. Dado que es una plataforma capaz de leer archivos, ejecutar comandos y manipular identificaciones, esta decisión claramente merece la atención de los administradores.
OpenClaw 2.0 transforma el agente personal en herramienta de equipo
La nueva versión, conocida como OpenClaw 2.0, representa una de las evoluciones más significativas del proyecto. Su desarrollo ha involucrado a varias cientos de colaboradores y una cantidad considerable de cambios de código.
La filosofía ha cambiado fundamentalmente. Hasta ahora, OpenClaw se concebía principalmente como un entorno personal donde un usuario instalaba y controlaba sus propios agentes. La nueva generación busca permitir que varias personas trabajen alrededor de los mismos agentes, sesiones y recursos.
Una de las novedades centrales son las sesiones colaborativas. Varios usuarios pueden retomar o continuar el mismo ambiente de trabajo sin necesidad de empezar de nuevo. Para un equipo de desarrollo, esto puede resultar extremadamente práctico. Un primer colaborador pide al agente que analice un problema, un segundo retoma la sesión y un tercero puede continuar la ejecución sin tener que reconstruir todo el historial.
La sesión se convierte casi en un documento viviente de transmisión.
El contexto del agente se convierte en un objeto colaborativo
Este es un cambio importante en la forma de conceptualizar los agentes de IA. Con un chatbot clásico, la conversación generalmente pertenece a un usuario. Con OpenClaw 2.0, el contexto puede convertirse en un recurso grupal.
El agente sabe lo que ya se ha intentado, conserva las decisiones tomadas, puede recuperar los archivos utilizados y puede continuar un flujo de trabajo donde otro colega lo dejó. Esta continuidad es especialmente interesante para los equipos técnicos, donde una tarea compleja puede pasar fácilmente de una persona a otra.
La interfaz web ha sido completamente rediseñada
OpenClaw también introduce una nueva interfaz de navegador mucho más accesible. Su diseño retoma las pautas familiares de asistentes modernos como ChatGPT: instalación, configuración, conversaciones, gestión de agentes. Grande parte de la experiencia ahora puede ser controlada desde el navegador.
Este cambio reduce la dependencia de la línea de comando y potencialmente amplía el público de la plataforma. OpenClaw ya no se dirige únicamente a usuarios técnicamente avanzados.
Las empresas pueden definir roles más precisos
La versión 2.0 también trae consigo roles de operación nombrados. Un administrador puede determinar qué usuarios tienen acceso a ciertos agentes, sesiones o privilegios. Esto hace posible crear perfiles que se correspondan con diferentes funciones en la empresa.
Desarrollador, operador, administrador, colaborador limitado. Estos roles también pueden imponer ciertas políticas, como la utilización obligatoria de un entorno sandbox para nuevas sesiones.
Pero estos roles no constituyen una fuerte aislación de seguridad
Esta es una matiz particularmente importante. La documentación de OpenClaw aclara que los controles de equipo están diseñados para organizar la colaboración entre personas que pertenecen al mismo perímetro de confianza. No se presentan como una frontera suficiente contra usuarios hostiles.
En otras palabras, dos departamentos que deben ser estrictamente separados no deberían necesariamente compartir la misma instancia solo porque existen roles. Lo mismo aplica a dos clientes distintos de un proveedor.
Para una verdadera aislación, se recomiendan varias instancias o entornos separados.
OpenClaw se vuelve más adecuado para las empresas, pero no automáticamente multi-tenant
Esta es una distinción esencial para los responsables de TI. Un producto colaborativo no es necesariamente una plataforma multi-tenant asegurada. OpenClaw 2.0 puede ser utilizado por un equipo donde todos los miembros pertenecen a la misma organización y comparten un nivel general de confianza.
Sin embargo, albergar a varios grupos que nunca deben poder acceder unos a otros requiere más separación.
El nuevo sistema de permisos mejora la gobernanza, pero no convierte una instancia de OpenClaw en una fortaleza compartimentada.
El sandboxing es la principal protección contra agentes demasiado poderosos
OpenClaw tiene una función diseñada precisamente para reducir este riesgo: el sandboxing. Cuando el sandboxing está activado, las herramientas utilizadas por un agente pueden ejecutarse en un entorno aislado.
Esto se aplica especialmente a operaciones sensibles como: lectura de archivos, escritura, modificación de archivos, ejecución de comandos y gestión de procesos. El objetivo es limitar los daños si el agente comete un error o interpreta incorrectamente una instrucción.
Sin embargo, el sandboxing está desactivado por defecto
Este es probablemente el punto más controvertido de esta versión. En la configuración estándar de OpenClaw, el modo de sandboxing global permanece configurado en off. Esto significa que, en ausencia de una configuración adicional o un rol que imponga explícitamente un sandbox, las herramientas pueden ejecutarse directamente en el host.
La documentación lo dice claramente: el directorio de trabajo por defecto no es una frontera de seguridad. Las rutas absolutas pueden permitir el acceso a otras partes del sistema si la aislación no está activada.
Para un entorno personal controlado, esto puede ser una elección de flexibilidad. En una empresa, el riesgo cambia completamente de escala.
Un agente de IA con acceso al sistema no es una aplicación ordinaria
El problema radica en la naturaleza misma de un agente. Un chatbot tradicional produce principalmente texto. Un agente puede actuar, leer un repositorio de código, modificar un archivo, ejecutar un script, interrogar un servicio, manipular datos o abrir un navegador. Cuando un sistema así trabaja directamente en el host, una mala decisión no se limita a una respuesta incorrecta.
Puedes tener un impacto concreto en la máquina.
La inyección de solicitudes hace que esta cuestión sea aún más sensible
Los agentes también pueden estar expuestos a contenidos externos. Una página web, un documento, un correo electrónico o un repositorio Git pueden contener instrucciones maliciosas destinadas a influir en el modelo.
Ese es el problema de la injection de solicitudes. Si un agente comprometido tiene un acceso muy amplio al sistema de archivos y a la terminal, el impacto potencial es evidentemente mayor. El sandboxing no resuelve completamente el problema de la injection de solicitudes.
Sin embargo, reduce el alcance de las acciones posibles cuando algo sale mal.
El sandbox de OpenClaw, sin embargo, ofrece configuraciones bastante estrictas
Cuando la función está correctamente activada, OpenClaw ofrece varias protecciones interesantes. El administrador puede elegir sandboxizar todas las sesiones o solo algunas. El acceso al espacio de trabajo puede ser eliminado, limitado a solo lectura o permitido en lectura-escritura. Los entornos de Docker también pueden funcionar con un sistema de archivos raíz de solo lectura y sin acceso a la red por defecto en ciertas configuraciones. Se pueden retirar capacidades de Linux.
Estas opciones permiten construir un entorno significativamente más restrictivo. El problema no es la falta de herramientas de seguridad, sino que exigen una configuración intencionada.
La elección de «seguro por defecto» sigue siendo discutible
Para los expertos en seguridad, es aquí donde comienza el debate. Una plataforma destinada a empresas podría adoptar la filosofía inversa. Aislamiento máximo en la instalación, luego apertura progresiva según las necesidades. OpenClaw prioriza más la compatibilidad y la potencia inmediata. Esta decisión puede facilitar la experiencia de los usuarios avanzados.
Sin embargo, también aumenta el riesgo de que un equipo implemente el producto rápidamente sin medir todas las implicaciones. En un entorno profesional, un ajuste por defecto raramente es trivial.
Los secretos se benefician de un nuevo sistema dedicado
OpenClaw 2.0 también mejora la gestión de identificaciones. La plataforma ahora cuenta con un almacén de identificaciones compartido a nivel de equipo. Los secretos pueden ser registrados allí sin ser expuestos directamente en las conversaciones. Para los valores marcados como secretos protegidos, la interfaz y los comandos clásicos no permiten simplemente volver a leerlos en texto plano.
El agente puede utilizar una referencia hacia el secreto en lugar de recibir directamente su valor en su contexto. Esta es una mejora importante en comparación con una clave API copiada en un prompt.
Pero, los secretos almacenados localmente no están cifrados en reposo
Una limitación importante debe ser destacada aquí. La documentación indica que los valores colocados en el almacén de secretos locales no están cifrados en reposo. Se conservan en la base de datos SQLite del estado compartido y están protegidos principalmente por los permisos del sistema de archivos.
OpenClaw utiliza permisos restrictivos en los archivos y carpetas involucrados. Pero, para una empresa que exige una verdadera protección criptográfica de los identificativos almacenados, esto puede ser insuficiente.
OpenClaw mismo recomienda cofres externos para entornos sensibles
El proyecto prevé precisamente varias alternativas. Los identificadores pueden ser reemplazados por SecretRefs, es decir, referencias a una fuente externa. OpenClaw puede, por ejemplo, trabajar con gestores como 1Password o soluciones tipo Vault. La plataforma recupera los secretos en el momento en que son necesarios en lugar de dejarlos en la configuración local.
Esta arquitectura reduce considerablemente la superficie de exposición. Para un despliegue profesional, parece mucho más adecuada.
1Password se beneficia de una integración específica
La versión 2.0 introduce un broker opcional para 1Password. La idea es permitir que OpenClaw acceda únicamente a las identificaciones necesarias para una tarea dada. Los administradores pueden controlar los elementos expuestos, y los registros de auditoría también pueden funcionar sin registrar el valor del secreto en sí.
Para ciertos flujos de trabajo, el gestor puede inyectar la identificación sin que aparezca directamente en el chat. Este es exactamente el tipo de integración que una plataforma de agentes necesita para ser creíble en el entorno empresarial.
El almacenamiento en texto plano sigue siendo posible
OpenClaw también conserva mecanismos de compatibilidad menos estrictos. La documentación precisa que los identificadores también pueden almacenarse directamente en ciertos archivos o perfiles. El modo de instalación por defecto puede permitir que ciertas claves API persistan como valores clásicos en lugar de referencias a un cofre.
Las herramientas de auditoría pueden buscar estos residuos. Pero, nuevamente, la seguridad óptima requiere de una acción del administrador. Esta filosofía se repite constantemente en OpenClaw 2.0: las protecciones adecuadas están ahí, pero no son necesariamente las que se activan automáticamente.
La plataforma ahora cuenta con herramientas de auditoría
Sería injusto presentar a OpenClaw como indiferente a esta cuestión. El proyecto proporciona varias órdenes para auditar la configuración de seguridad. Los administradores pueden buscar secretos que aún estén presentes en texto plano, pueden realizar verificaciones más profundas en el Gateway y también pueden aplicar ciertas correcciones o examinar los parámetros efectivos.
Esto es valioso para los equipos de DevOps. Pero, estas herramientas suponen una vez más que alguien piense en utilizarlas.
El nuevo modelo empresarial exige una verdadera administración
OpenClaw 2.0 no es un producto que deberías instalar en un servidor y abrir inmediatamente a toda una organización. Un despliegue serio requiere reflexionar sobre varios elementos. ¿Qué agentes pueden ejecutar código? ¿Qué carpetas son accesibles? ¿Qué usuarios pertenecen realmente al mismo perímetro de confianza? ¿Qué secretos deben permanecer en un cofre externo? ¿Qué sesiones necesitan un sandbox? ¿Qué herramientas deben ser desactivadas? La respuesta depende de la empresa, pero estas preguntas deben plantearse antes de la producción.
Es mejor tratar a un agente como un usuario privilegiado
Probablemente esta es la mejor aproximación conceptual. Un agente de IA capaz de ejecutar comandos debe ser considerado como un cuenta técnica con permisos. Y como toda cuenta técnica, debería operar con el mínimo privilegio necesario.
Sin acceso al directorio personal completo si solo se requiere un repositorio Git, sin acceso a la red completa cuando solo se necesita una API, sin claves de administrador cuando un token de solo lectura es suficiente. La inteligencia del modelo no reemplaza los principios clásicos de ciberseguridad. Por el contrario, los hace aún más necesarios.
El cloud colaborativo aumenta mecánicamente la superficie de ataque
La transición de una instalación personal a un entorno compartido también cambia el modelo de amenaza. Un solo usuario tiene un perímetro relativamente simple. Una vez que varias personas inician sesión en el mismo entorno, el número de escenarios se incrementa.
Cuenta comprometida, permiso mal configurado, sesión compartida por error, secreto accesible para demasiadas personas o incluso un agente con privilegios excesivos. Cada función colaborativa aporta valor, pero también nuevas fronteras que asegurar.
Este es un problema clásico en el software profesional. Una plataforma que funciona inmediatamente con un acceso amplio parece agradable de usar, mientras que una plataforma altamente compartimentada requiere más configuración.
OpenClaw parece haber decidido preservar cierta libertad operativa. Esto se alinea bien con sus orígenes de código abierto y su público técnico. Sin embargo, a medida que el proyecto apunta a empresas menos experimentadas con agentes autónomos, este compromiso se vuelve más difícil de defender.
La documentación ofrece incluso una recomendación bastante clara para entornos que requieren una verdadera separación. Es mejor usar agentes o Gateways distintos con herramientas mínimas. Un equipo interno que comparte los mismos recursos puede funcionar dentro de una misma instancia. Pero clientes distintos o equipos que manejen datos que deban ser estrictamente compartimentados deberían beneficiarse de entornos separados.
Este principio recuerda más la administración de servidores que el uso de un chatbot SaaS. Y, probablemente, así es como debes pensar en OpenClaw.
OpenClaw 2.0, sin embargo, marca un progreso significativo
Las preocupaciones de seguridad no deben ocultar la magnitud del cambio. Sesiones compartidas, roles de operadores, gestión centralizada de secretos, interfaz web más accesible, instalación en la nube y permisos más ajustados. Todas estas funciones acercan claramente a OpenClaw a una plataforma realmente utilizable por equipos profesionales.
El agente ya no es solo un asistente individual, se convierte en una infraestructura colaborativa.
Es aquí donde el próximo paso parece obvio. OpenClaw ya cuenta con muchas de las piezas necesarias para asegurar correctamente un despliegue. El desafío ahora es convertir estas protecciones en el camino más simple, y no en una opción reservada para administradores que han leído toda la documentación.
Una plataforma destinada a empresas no puede ser solo asegurada, debe ser idealmente difícil de desplegar de manera peligrosa.
