OpenClaw: qué es, cómo funciona y por qué preocupa su seguridad

  • OpenClaw es un agente de IA local que orquesta tareas autónomas con acceso profundo a correos, archivos, chats y credenciales.
  • Sus vulnerabilidades, configuraciones por defecto e intercambio de “habilidades” lo convierten en un objetivo prioritario para ciberdelincuentes.
  • En entornos corporativos, centraliza secretos y permisos, multiplicando el riesgo de fugas y de incumplimientos normativos.
  • Su uso responsable exige aislamiento, mínimos privilegios, auditorías continuas y políticas claras de IA en la sombra.

OpenClaw agente de IA local conectado a múltiples servicios

OpenClaw se ha convertido en uno de los nombres más repetidos cuando se habla de agentes de IA capaces de actuar de forma autónoma en tu ordenador, gestionar tu correo, tocar tus archivos y hasta mandar mensajes por ti. El hype ha sido brutal: promesas de que “trabaja mientras duermes”, vídeos virales y una sensación casi mesiánica de que por fin había llegado esa pieza que faltaba a la IA generativa.

Pero cuando bajas del escenario de los vídeos virales y te metes en la realidad del software, OpenClaw deja de ser magia y se convierte en una mezcla curiosa de automatización avanzada, asistente conversacional y, sobre todo, un quebradero de cabeza en materia de seguridad si no sabes exactamente qué tienes entre manos. Vamos a ver con calma qué es realmente, cómo funciona, cuáles son sus vulnerabilidades y por qué muchas organizaciones ya lo ven como una auténtica bomba de relojería.

Qué es OpenClaw y de dónde sale

OpenClaw es un agente de IA personal de código abierto pensado para ejecutarse en tu propia máquina, no en la nube de un tercero. Nació bajo el nombre de Clawdbot, después pasó a llamarse Moltbot y, tras líos de marca registrada y alguna que otra polémica, terminó rebrandeado como OpenClaw. El proyecto está liderado por Peter Steinberger y cuenta con repositorios y documentación pública.

La idea de base es sencilla de entender pero muy potente: en lugar de un simple chatbot que contesta a tus preguntas, OpenClaw actúa como un “orquestador” que puede tomar decisiones encadenadas y ejecutar acciones reales sobre tu entorno digital. No se queda en el texto: mueve correos, toca archivos, hace peticiones web, programa tareas, habla por mensajería instantánea y, en general, opera como un asistente que se arremanga y trabaja sobre tu equipo.

En la práctica, OpenClaw se ejecuta localmente en tu ordenador (o en un servidor que controles tú) y se conecta con servicios como WhatsApp, Telegram, Signal, Discord, Slack, el navegador, el calendario, el correo electrónico o el propio sistema de archivos. Utiliza los permisos del sistema para operar, lo que significa que, en muchos casos, tiene exactamente las mismas capacidades que tú como usuario.

Lo que lo diferencia de los típicos chatbots es que no espera pasivamente a que le dicten cada paso: tú defines objetivos (“clasifica mis correos”, “prepara un informe con estos documentos”, “responde a estos mensajes”), el agente los descompone en tareas, decide qué herramientas utilizar y actúa sin que tengas que estar encima permanentemente, salvo que tú limites explícitamente su autonomía.

Cómo funciona OpenClaw por dentro

OpenClaw se comporta como una especie de torre de control que se apoya en modelos de lenguaje externos (locales o en la nube) para la “inteligencia”, mientras que él pone la capa de acción: integraciones, automatización y ejecución de comandos. En esencia, es una puerta de enlace que recibe órdenes a través de apps de chat o una interfaz web, las traduce en pasos concretos y se las pasa a diferentes agentes o herramientas de IA.

El flujo típico de funcionamiento se puede resumir así: primero el usuario define objetivos o tareas (por ejemplo, “responder a todos los correos urgentes de hoy”); después OpenClaw interpreta la intención, la trocea en pasos, elige las “habilidades” o herramientas adecuadas para cada paso, ejecuta las acciones y, en función del resultado, ajusta el comportamiento para seguir o rectificar. Esa capacidad de reaccionar en cadena es lo que da sensación de “agente autónomo”.

Para conseguirlo, OpenClaw necesita un acceso muy profundo a tu entorno: cuentas de correo, servicios de mensajería con sus historiales, calendarios, navegadores, archivos locales, sesiones activas, cookies, tokens de API y claves que le permiten actuar en tu nombre frente a otros servicios. Todo eso se combina con su memoria interna, donde conserva conversaciones previas, decisiones pasadas y hábitos de uso para afinar sus respuestas y su forma de actuar.

En realidad, para muchas de sus funciones más espectaculares, OpenClaw no “piensa” por sí mismo, sino que llama a modelos de terceros (Claude, GPT, otros LLM) que hacen el trabajo pesado de razonamiento, programación o análisis. El agente esencialmente les pasa las instrucciones que tú podrías escribir directamente, pero las envuelve en una lógica de automatización, integración con canales y memoria persistente.

Esto hace que, conceptualmente, OpenClaw se parezca más a un N8n o Zapier con esteroides y capa de IA conversacional que a una AGI mágica que resuelve tu vida mientras duermes. La gran diferencia es que el interfaz deja de ser una colección de botones y menús, y pasa a ser una conversación con una IA que va disparando flujos y comandos por debajo.

Qué tipo de información maneja OpenClaw

El nivel de acceso que necesita OpenClaw para ser útil hace que acabe tocando prácticamente todo tu universo digital. No solo lo que tú le das de forma explícita, sino también lo que “ve de paso” para poder actuar.

Por un lado, está la información que compartes voluntariamente: correos que le pides que responda, documentos que le das para resumir, mensajes que le pides que gestione, archivos que le entregas para clasificar o procesar, notas, tareas, etc. Todo eso forma parte de su contexto de trabajo y se analiza con los modelos de lenguaje que tenga configurados.

Luego está la información a la que accede para poder hacer cosas, aunque tú no se la “des” en cada momento: cuentas de correo completas, historiales de chats, listas de contactos, calendarios, archivos del sistema, cookies del navegador, sesiones ya abiertas y cualquier repositorio al que tenga permiso para entrar. Desde su punto de vista, son recursos disponibles para cumplir tus objetivos.

Un bloque crítico son los datos de autenticación y sesión: tokens de acceso, cookies, claves API, credenciales de acceso a servicios, configuraciones VPN, permisos OAuth sobredimensionados… Son las llaves que le permiten actuar como si fueras tú ante cada servicio conectado. Si esos elementos se exponen o se roban, el impacto es enorme.

A eso se suma el historial y el contexto que va acumulando el propio agente: acciones anteriores, decisiones tomadas, conversaciones, rutinas de uso, patrones de comportamiento… y también metadatos como horarios de actividad, frecuencia de ciertas tareas, prioridades implícitas o relaciones entre contactos. Esa información, combinada, dibuja un mapa muy fino de tu vida digital.

Además, OpenClaw no solo maneja tus datos, sino también los de terceros: mensajes que te han enviado otras personas, documentos compartidos contigo por compañeros, clientes o amigos, hilos de chat en grupos, ficheros colaborativos, etc. Muchos de esos terceros ni siquiera son conscientes de que un agente de IA está procesando lo que comparten contigo.

Vulnerabilidades y problemas de seguridad conocidos

Desde el punto de vista de la seguridad, OpenClaw se ha ganado una fama complicada. Empresas como 1Password o CrowdStrike lo han descrito como una auténtica pesadilla, y algunos expertos ya hablan de la “mayor amenaza interna de 2026” si se instala alegremente en entornos corporativos.

Para empezar, la puerta de entrada técnica ha tenido agujeros serios. La vulnerabilidad CVE-2026-25253, con una puntuación CVSS de 8,8, permitía a un atacante tomar el control completo de la puerta de enlace y ejecutar comandos arbitrarios. Bastaba con que el agente visitara una web maliciosa o que el usuario pulsara en un enlace diseñado para robar el token de autenticación principal. Con ese token, el atacante obtenía control administrativo total. El fallo se corrigió en la versión 2026.1.29, pero ilustra el nivel de riesgo.

Además, se detectaron dos vulnerabilidades peligrosas de inyección de comandos (CVE-2026-24763 y CVE-2026-25157), que abrían la puerta a ejecutar órdenes en la máquina host a través de entradas manipuladas. Todo esto en un proyecto que, aunque reconoce que la seguridad importa, funciona en gran parte como iniciativa de aficionado, sin un equipo dedicado ni procesos maduros de gestión de vulnerabilidades.

Los valores por defecto y algunas decisiones de diseño tampoco ayudan: la autenticación viene desactivada de serie, así que el panel puede quedar expuesto a Internet; el servidor acepta conexiones WebSocket sin validar el origen; las conexiones desde localhost se consideran implícitamente fiables, algo muy peligroso si hay un proxy inverso en juego; el modo Invitado permite acceder a herramientas potencialmente sensibles; y parámetros de configuración críticos se filtran por la red local vía mDNS.

Por si fuera poco, OpenClaw almacena configuración, memoria y registros de chat en texto plano, incluyendo claves API, contraseñas y otras credenciales de servicios integrados y LLM. Esto ha llamado rápidamente la atención de los ciberdelincuentes: variantes de infostealers como RedLine, Lumma o Vidar ya incluyen rutas de archivos de OpenClaw entre los objetivos a robar.

El ecosistema tampoco está libre de riesgos: las “habilidades” extensibles que se descargan desde el repositorio ClawHub aceptan contribuciones de cualquiera, lo que ha derivado en cientos de capacidades maliciosas. Entre ellas, se han visto cargas que incluían el infostealer AMOS para macOS camuflado como herramientas útiles. Tras el escándalo, los desarrolladores firmaron un acuerdo con VirusTotal para analizar cada nueva habilidad con bases de datos de malware y revisiones automatizadas vía LLM, pero ellos mismos admiten que no hay bala de plata.

Defectos estructurales del agente de IA

Aun parcheando vulnerabilidades y reforzando la configuración, OpenClaw arrastra problemas estructurales derivados de su propio modelo de funcionamiento, comunes en muchos agentes de IA multipropósito, pero especialmente pronunciados aquí.

En primer lugar, el agente opera con privilegios amplísimos sobre datos sensibles almacenados en la máquina host y en las cuentas personales del usuario. Desde correos y documentos internos hasta credenciales, historiales de navegación o repositorios de código, todo puede estar potencialmente al alcance del agente si no se segmenta con cuidado.

En segundo lugar, OpenClaw está expuesto constantemente a datos no confiables: recibe mensajes desde apps de mensajería, correos electrónicos de cualquier remitente, páginas web que navega de forma autónoma, contenidos en foros o redes sociales, etc. Cada uno de esos contenidos puede contener instrucciones ocultas para manipular su comportamiento.

Ahí entra en juego una limitación clave de los modelos actuales: los LLM no separan de forma fiable comandos de datos. La inyección de prompts (incluida la indirecta, escondida en webs o correos) puede llevar al agente a ejecutar acciones no deseadas, enviar información sensible a terceros o modificar su conducta futura sin que el usuario lo note.

A eso se suma que el agente conserva puntos clave, resúmenes y artefactos de las tareas que realiza para poder dar continuidad a su trabajo. Una sola inyección exitosa puede contaminar esa memoria y condicionar el comportamiento del agente a largo plazo, de forma sutil y persistente.

Por último, OpenClaw tiene capacidad para comunicarse hacia fuera: enviar correos, hacer llamadas API, interactuar con servicios externos… Si un atacante consigue influir en sus decisiones, esa capacidad de salida se convierte en un canal perfecto para la exfiltración de datos o para lanzar acciones maliciosas que parecen venir del propio usuario.

Riesgos específicos para empresas y entornos corporativos

Cuando un empleado instala OpenClaw en un dispositivo de trabajo, el cóctel de riesgos se dispara. El agente combina ejecución autónoma de comandos, acceso amplio al sistema de archivos y permisos OAuth excesivos sobre herramientas como Slack, SharePoint, correo corporativo o repositorios internos.

En ese contexto, una sola puerta de enlace comprometida puede servir para pivotar por toda la red: el bot acumula secretos, tokens y credenciales sin cifrar en un único punto, así que no hace falta vulnerar directamente los servidores de la empresa, basta con explotar el agente local. Incluso aunque OpenClaw no llegue a verse comprometido, su tendencia a centralizar información sensible es en sí misma un problema de diseño.

Además, muchas de las configuraciones habituales chocan frontalmente con los requisitos regulatorios de la UE y otros marcos como el AI Risk Management Framework del NIST, que exigen controles de acceso estrictos, minimización de permisos y trazabilidad clara sobre los sistemas que procesan datos sensibles. OpenClaw, tal y como se suele desplegar en modo “juguete potente”, no cumple esos estándares.

El riesgo no desaparece ni siquiera cuando la empresa prohíbe formalmente instalar OpenClaw en equipos corporativos. El software puede acabar ejecutándose en dispositivos personales de empleados que tienen configuradas en esos mismos dispositivos VPNs corporativas, sesiones de correo profesional, accesos a herramientas internas, etc.

En ese escenario, el agente se convierte en un puente perfecto hacia la infraestructura de la empresa: puede secuestrarse el acceso a sistemas corporativos desde el dispositivo personal, las apps de chat usadas para controlarlo (WhatsApp, Telegram, etc.) amplían la superficie de ingeniería social, y cualquier servicio de trabajo conectado al agente (correo, almacenamiento, mensajería) puede servir para extraer datos de forma prácticamente invisible para los sistemas de monitorización corporativos.

Cómo detectar la presencia de OpenClaw

Para los equipos de seguridad y SOC, detectar que OpenClaw está corriendo en la red es clave para poder evaluar y mitigar riesgos. En función de las capacidades de monitorización, se pueden usar varios indicadores.

A nivel de host, es útil buscar directorios característicos en los equipos: rutas como ~/.openclaw/, ~/clawd/ o ~/.clawdbot suelen delatar instalaciones del agente, incluso si el usuario ha intentado ocultar el icono o las aplicaciones visibles.

En el plano de red, pueden escanearse los rangos internos (o utilizar herramientas públicas como Shodan para instancias expuestas) buscando las huellas HTML de los paneles de administración de Clawdbot/OpenClaw. Además, conviene supervisar tráfico WebSocket inusual en los puertos 3000 y 18789, que son utilizados con frecuencia por la puerta de enlace.

Otro indicador es la presencia de mensajes mDNS de difusión en el puerto 5353, especialmente aquellos que anuncian servicios como openclaw-gw.tcp. Estos anuncios pueden revelar instancias activas en la red local sin necesidad de escaneos intrusivos.

También se recomienda vigilar patrones de autenticación atípicos en servicios corporativos: nuevos registros de IDs de aplicaciones, solicitudes de consentimiento OAuth sospechosas, o cadenas de agente de usuario poco frecuentes (típicas de Node.js u otros entornos no estándar) que aparezcan de repente asociadas a cuentas de empleados.

Finalmente, desde el punto de vista del comportamiento, los patrones de acceso característicos de la recolección automatizada también son una pista: lectura masiva de archivos o correos, escaneos periódicos de directorios fuera de horario laboral, consultas reiteradas a APIs internas… Todo ello puede indicar que hay un agente tipo OpenClaw operando en segundo plano.

IA en la sombra y medidas de higiene básica

OpenClaw encaja de lleno en lo que muchos llaman “IA en la sombra”: herramientas potentes adoptadas por empleados por su cuenta, sin aprobación ni supervisión oficial del departamento de TI o seguridad. Reducir ese fenómeno no pasa por prohibirlo todo sin más, sino por reforzar una serie de prácticas de higiene digital.

Una de las más efectivas es usar listas de admitidos a nivel de host y de servicio, de forma que solo se puedan instalar aplicaciones aprobadas y que las integraciones (por ejemplo, extensiones de navegador, plugins de editores de código o habilidades de agentes) se limiten a un conjunto cerrado y revisado.

Antes de permitir la conexión de cualquier agente de IA a recursos corporativos, debería hacerse una evaluación de seguridad completa, igual que se hace con un servidor expuesto o un SaaS que manejará datos internos. Eso implica revisar modelos de permisos, almacenamiento de claves, telemetría, registro de actividades, etc.

En paralelo, conviene aplicar el principio de privilegios mínimos de forma estricta: limitar accesos a lo imprescindible, evitar cuentas con permisos administrativos permanentes, fomentar el uso de cuentas separadas para tareas sensibles y configurar las apps corporativas para que las integraciones OAuth solo obtengan los permisos mínimos para funcionar.

La auditoría periódica también es clave: revisar integraciones activas, tokens, permisos concedidos y apps de terceros conectadas, cuestionando su necesidad real con los propietarios de negocio y revocando todo aquello que esté obsoleto o sobredimensionado.

Uso experimental y despliegue controlado de agentes de IA

Si una organización decide que quiere experimentar con agentes como OpenClaw (por ejemplo, en pruebas de concepto, pilotos de productividad o entornos de desarrollo), lo sensato es hacerlo dentro de un perímetro muy controlado, no directamente sobre sistemas de producción.

Una buena práctica es desplegar el agente en una subred aislada con reglas de entrada y salida estrictas, permitiendo comunicación solo con los hosts que realmente necesita para su tarea. Así se reduce la superficie de impacto si algo sale mal o el agente se comporta de forma inesperada.

En cuanto a las credenciales, deberían utilizarse tokens de acceso de corta duración y alcance muy limitado, idealmente asociados a cuentas de servicio específicas para cada prueba. Nunca se debería entregar a un agente acceso directo a servidores centrales, bases de datos con información crítica o sistemas de producción.

También es importante proteger al agente de herramientas y conjuntos de datos que no necesita. Para pilotos iniciales, lo más sano es trabajar con datos sintéticos que imiten la estructura de los reales, de forma que se puedan medir capacidades sin exponer información sensible.

Finalmente, conviene activar un registro muy detallado de las acciones del agente: comandos que ejecuta, parámetros, eventos, contextos asociados… y configurar el SIEM para marcar comportamientos anómalos, aprovechando reglas similares a las usadas para detectar ataques Living off the Land. Si se usan servidores MCP o habilidades adicionales, hay herramientas emergentes (skill-scanner, mcp-scanner, mcp-scan) que ayudan a auditar su seguridad.

Políticas internas, formación y expectativas realistas

Intentar cortar por lo sano con una prohibición total de la IA suele ser una receta para que el problema se esconda debajo de la alfombra. Los empleados encontrarán formas creativas de saltarse las limitaciones si perciben que la herramienta les ahorra tiempo, y la organización perderá visibilidad sobre lo que está pasando.

Es más efectivo definir políticas claras y transparentes sobre qué categorías de datos se pueden procesar con servicios de IA y cuáles no, explicar los motivos y, sobre todo, ofrecer alternativas seguras aprobadas (por ejemplo, un asistente corporativo gestionado centralmente) en lugar de un “no” rotundo.

La formación también marca la diferencia: usar ejemplos concretos y cercanos (como el caso de un correo que induce al agente a reenviar información sensible sin querer) ayuda mucho más que advertencias abstractas sobre “fugas de datos”. Idealmente, todo el personal debería pasar por un mini curso de seguridad en IA que aterrice estos riesgos a su día a día.

En paralelo, hay que ajustar las expectativas. OpenClaw encarna bien la diferencia entre hype y realidad: muchas demos espectaculares que se ven en redes son flujos cuidadosamente preparados, o tareas que, en el fondo, podría ejecutar igual de bien un modelo como Claude Code sin toda la complejidad añadida de un agente autónomo.

En la práctica, usuarios técnicos que lo han probado en serio se han encontrado con instalaciones complicadas, integraciones inestables, logs crípticos y costes elevados si se usan modelos de gama alta. Meterlo en una “burbuja de seguridad” limita riesgos, pero a la vez dificulta que instale librerías y se mueva con soltura. Es una herramienta prometedora, sí; también inmadura, cara de operar y peligrosa si se usa a la ligera.

Al final, OpenClaw sirve como un gran espejo de hacia dónde va el software en la era de la IA: interfaces conversacionales que orquestan automatizaciones complejas por debajo. Pero que algo apunte al futuro no significa que tenga que ser tu herramienta del presente. Para la mayoría de usuarios y empresas, hoy sigue siendo más sensato apoyarse en modelos y automatizaciones más controladas, y dejar los experimentos con agentes como OpenClaw para quien sepa exactamente a qué riesgos se está exponiendo y cómo quiere gestionarlos.