OpenClaw representa un cambio importante en la forma en que la gente utiliza la IA. En lugar de un chatbot alojado en la nube, OpenClaw se ejecuta localmente -en su portátil o estación de trabajo- con capacidad para escribir código, gestionar archivos, invocar herramientas y actuar de forma autónoma en su nombre.
Ese poder es exactamente lo que eleva lo que está en juego.
OpenClaw se encuentra en desarrollo activo y acelerado, con nuevas características que se añaden rápidamente. Esa velocidad es un punto fuerte, pero también significa que áreas fundamentales como la autenticación, la autorización y la auditabilidad siguen evolucionando. A medida que los agentes de OpenClaw se hacen más autónomos y se utilizan más ampliamente, estas lagunas pasan de ser compensaciones en fase inicial a riesgos reales para la seguridad.
Este artículo examina el modelo de autenticación actual de OpenClaw, sus recientes mejoras (incluido el modo de proxy de confianza), lo que aún falta y por qué integrarlo con ZTNA empresariales como Aryaka AI>Secure es la solución más limpia y escalable.
Autenticación nativa de OpenClaw: Acceso basado en token
En la actualidad, OpenClaw se basa principalmente en un modelo de token secreto compartido.
Durante la configuración, OpenClaw genera un token de puerta de enlace -unacadena secreta larga y aleatoria- que se almacena localmente (por ejemplo, bajo el directorio personal del usuario en los archivos de configuración de OpenClaw). Este token actúa como la credencial necesaria para acceder al agente OpenClaw a través de su interfaz HTTP local.
Cuando un usuario abre la interfaz de usuario de control basada en navegador de OpenClaw, se le pide que proporcione este token. Una vez suministrado, el navegador puede comunicarse con el agente sin repetidas solicitudes de autenticación.
Las versiones recientes han añadido la aprobación manual en el terminal cuando una nueva sesión de navegador intenta conectarse. Se trata de una mejora significativa de la seguridad, pero no cambia el modelo central de confianza:
Cualquiera que posea el token tiene pleno acceso al agente.
Todavía no hay identidad de usuario, MFA, separación de roles o evaluación contextual.
Persistencia del navegador: Conveniencia con riesgo
Por razones de usabilidad, la interfaz de usuario del navegador suele persistir el token localmente (por ejemplo, en el almacenamiento del navegador). Esto evita las solicitudes repetidas pero introduce riesgos predecibles:
- El token se convierte en una credencial de larga duración
- El malware o las extensiones maliciosas del navegador pueden extraerlo
- No hay caducidad de sesión ni validación contextual
Desde el punto de vista de la seguridad, el token se comporta más como una clave API que como un inicio de sesión de usuario.
Riesgos en escenarios de usuario único y multiusuario
Incluso en configuraciones de un solo usuario, la exfiltración de tokens a través de malware o el compromiso del navegador conduce a la toma total del agente.
En entornos compartidos o de equipo, la situación empeora:
- Sin identidades de usuario
- Sin funciones ni permisos
- No hay forma de atribuir acciones a los individuos
- Sin revocación de grano fino
- Sin registro de auditoría empresarial
Esto es fundamentalmente incompatible con el uso empresarial, regulado o de producción.
Modo Trusted-Proxy: La dirección arquitectónica correcta
Para abordar estas limitaciones, OpenClaw ha introducido el modo de proxy de confianza, que constituye un paso arquitectónico significativo y positivo.
En modo proxy de confianza:
- OpenClaw sólo acepta solicitudes de un proxy designado en sentido ascendente
- El token de puerta de enlace permanece confinado a ese proxy
- Los usuarios finales nunca interactúan directamente con el agente
Este diseño reconoce explícitamente un principio básico: la identidad y el control de acceso deben vivir fuera del agente.
Integración de ZTNA: La inyección de identidad hecha con seguridad
Aquí es donde ZTNA se integra de forma limpia e intencionada con el diseño de proxy de confianza de OpenClaw.
Una plataforma ZTNA como Aryaka AI>Secure se sitúa delante de OpenClaw y realiza una autenticación, autorización y contabilidad (AAA ) completas antes de que el tráfico llegue al agente.
Tras autenticar a los usuarios mediante IdP empresariales (Okta, Azure AD, Google Workspace), aplicar la MFA y validar la postura del dispositivo, ZTNA reenvía las solicitudes a OpenClaw con el contexto de identidad verificado inyectado, normalmente utilizando cabeceras como:
- X-Forwarded-User
- X-Forwarded-Groups
El modo de proxy de confianza de OpenClaw está diseñado para confiar en estas cabeceras sólo desde el proxy configurado.
Requisito crítico de seguridad: No al reenvío ciego de cabeceras
Es necesario explicitar un punto:
La ZTNA nunca debe reenviar ciegamente las cabeceras de identidad de la conexión del cliente al agente.
Si cabeceras como X-Forwarded-User se copian directamente de la solicitud del cliente, un atacante podría falsificar tri vialmente las cabeceras de identidad y eludir los controles de seguridad en la capa del agente OpenClaw.
Una integración ZTNA correcta sigue reglas estrictas:
- Se eliminan todas las cabeceras de identidad proporcionadas por el cliente
- Las cabeceras de identidad son reconstruidas por ZTNA tras la autenticación a partir de JWT
- Los encabezados son de confianza criptográfica o lógica porque:
- Proceden únicamente del proxy ZTNA
- OpenClaw sólo los acepta en modo trusted-proxy
- Ninguna entrada controlada por el cliente se reutiliza como contexto de identidad
Esta separación es lo que hace que el modelo OpenClaw + ZTNA sea seguro por diseño y no por convención.
Autorización y auditabilidad sin cambios de agente
Aunque OpenClaw aún no dispone de usuarios o roles nativos:
- ZTNA controla quién puede acceder al agente
- Las políticas pueden aplicarse por usuario, grupo, dispositivo y contexto de red
- Cada solicitud se registra con una identidad humana verificada
- Las empresas obtienen una pista de auditoría limpia para el cumplimiento de la normativa y el análisis forense
OpenClaw sigue centrándose en el comportamiento de los agentes.
Conclusión: La ZTNA sigue siendo importante, incluso si OpenClaw evoluciona
OpenClaw evoluciona rápidamente y en la dirección correcta. El modo de proxy de confianza es una fuerte señal arquitectónica de que el proyecto comprende la importancia de la confianza externalizada.
Aunque OpenClaw implemente más adelante la autenticación nativa de usuarios o los roles, la ZTNA sigue siendo valiosa -y a menudo esencial- para las empresas.
¿Por qué?
Porque las empresas necesitan un control de seguridad uniforme en todas las aplicaciones :
- SaaS
- Aplicaciones web internas
- APIs
- Herramientas para desarrolladores
- Y ahora, los agentes de IA
ZTNA proporciona: Política centralizada
- MFA coherente y postura del dispositivo
- Registros de auditoría unificados
- Una única capa de aplicación en sistemas heterogéneos
OpenClaw no necesita convertirse en una plataforma IAM completa para ser segura.
Cuando el modo de proxy de confianza de OpenClaw se combina con una capa ZTNA correctamente implementada, las empresas obtienen lo mejor de ambos mundos:
- Agentes de IA rápidos y potentes
- Seguridad de grado empresarial Zero Trust