Microsoft: no ejecutes OpenClaw en máquinas de trabajo normales

El 19 de febrero de 2026, el Equipo de Investigación de Seguridad de Microsoft Defender publicó una entrada titulada «Ejecutar OpenClaw de forma segura: identidad, aislamiento y riesgo en tiempo de ejecución», y en ella hizo una recomendación que el Orca AI Incident Archive registra sin equivalente en ninguna otra entrada: OpenClaw «debe tratarse como ejecución de código no confiable con credenciales persistentes», y «no es apropiado ejecutarlo en una estación de trabajo personal o empresarial estándar». OpenClaw es un entorno de ejecución de agentes autoalojado —el usuario lo instala en su propia máquina, le concede cuentas y tokens, y le permite instalar habilidades desde un registro público y actuar sobre texto que lee de cualquier procedencia. El argumento de Microsoft es arquitectónico, no un informe de errores: el entorno de ejecución traslada el punto de ejecución del código de aplicación estático al contenido suministrado en tiempo de ejecución, y los controles en torno a identidad, manejo de entradas y privilegios no se han trasladado con él. La entrada no nombra ningún CVE, ninguna campaña ni ninguna víctima, y no registra ningún compromiso. El registro completo se encuentra en el Orca AI Incident Archive, donde se clasifica como una entrada de política emblemática con grado de confianza A y ningún daño real registrado.

Lo que decía la publicación y lo que no

La publicación requiere unos doce minutos de lectura y no incluye ningún mecanismo de divulgación: ni identificador CVE, ni intervalo de versiones afectadas, ni compilación corregida, ni indicador de compromiso vinculado a una implementación real. Microsoft Defender Security Research incluye a Idan Hen como colaborador. Lo que sí incluye es un modelo de amenazas y una regla de despliegue, por lo que el archivo lo clasifica como un registro de políticas en lugar de un incidente: información de gravedad, calificación de confianza A, ningún daño real registrado y una fecha con precisión de un solo día.

El razonamiento se condensa en un párrafo inicial. OpenClaw "incluye controles de seguridad integrados limitados", escribe el equipo, porque el entorno de ejecución "puede ingerir texto no confiable, descargar y ejecutar habilidades (es decir, código) de fuentes externas y realizar acciones usando las credenciales que se le asignan". La consecuencia se enuncia en la misma frase: esto "desplaza efectivamente el límite de ejecución del código de aplicación estático al contenido proporcionado dinámicamente y a las capacidades de terceros, sin controles equivalentes en torno a la identidad, la gestión de entradas o el alcance de privilegios".

A continuación se presentan tres riesgos, y vale la pena leerlos en las propias palabras de Microsoft porque la mayoría de la cobertura posterior los parafraseó hasta volverlos vagos:

• "Las credenciales y los datos accesibles pueden quedar expuestos o ser exfiltrados."

• «El estado persistente o la "memoria" del agente puede modificarse, lo que provoca que siga instrucciones proporcionadas por el atacante con el paso del tiempo.»

• "El entorno anfitrión puede verse comprometido si se induce al agente a recuperar y ejecutar código malicioso."

Fíjate en lo que no aparece en esa lista. No hay una falla explotada, ni una función vulnerable, ni un parche que enviar. Microsoft no está diciendo que OpenClaw tenga un error de seguridad; está diciendo que un programa que decide qué hacer en tiempo de ejecución, a partir del texto que obtuvo, usando las credenciales que se le dieron, no puede volverse seguro mediante configuración en una máquina que también contiene el trabajo real del operador. La recomendación que sigue es igual de contundente: para la mayoría de los entornos, «la decisión adecuada puede ser no desplegarlo».

Dos cadenas de suministro, un bucle de ejecución

El mecanismo que describe la publicación es la convergencia de lo que denomina las dos cadenas de suministro de un agente autoalojado: código no confiable, es decir, habilidades y extensiones, e instrucciones no confiables, es decir, texto externo. La mayoría del software tiene una u otra. Un gestor de paquetes descarga código no confiable, pero no lee internet ni decide qué ejecutar a continuación; un modelo de chat lee texto no confiable, pero no puede instalar nada. OpenClaw hace ambas cosas en un único bucle, y el bucle se ejecuta bajo la propia identidad del usuario.

"Instalar una skill es básicamente instalar código con privilegios", dice la publicación. Las skills "a menudo se descubren e instalan a través de ClawHub, el registro público de skills para OpenClaw", y en implementaciones permisivas "el entorno de ejecución puede tener permiso para ejecutar el flujo de instalación sin aprobación humana". La segunda cadena de suministro la gestiona Moltbook, que la publicación describe como una plataforma centrada en agentes y una capa de identidad donde los agentes publican, leen y se autentican mediante API; y, por lo tanto, en sus palabras, "un flujo de gran volumen de contenido influenciable por atacantes que los agentes ingieren de forma programada". La compresión es lo importante: "Por lo tanto, una sola publicación maliciosa puede llegar a varios agentes".

El artículo divide entonces el límite de confianza en tres componentes, que es la parte más reutilizable de todo el documento: identidad, es decir, los tokens que el agente utiliza para trabajar con API de SaaS, repositorios, correo y planos de control de la nube; ejecución, es decir, las herramientas que puede ejecutar y que cambian el estado, incluidos archivos, shell, infraestructura y mensajes; y persistencia, es decir, las formas en que puede conservar cambios entre ejecuciones, mediante tareas, configuración y programaciones. Un agente que tiene los tres no es una aplicación con un aviso de permiso. Es un principal.

La habilidad envenenada, en cinco etapas

Microsoft ofrece una cadena de compromiso desarrollada, etiquetada como un escenario representativo en lugar de un informe de caso, y vale la pena recorrerla porque sus dos últimos pasos son los que derrotan las defensas habituales de los endpoints. La publicación la precede con una afirmación sobre el mundo exterior —"Los informes públicos han documentado habilidades maliciosas que aparecen en registros públicos", y en algunos casos "el contenido del registro ha sido malware directo empaquetado como una habilidad, en lugar de una sutil imitación"—, pero no nombra ninguna entrada de registro, campaña, actor o víctima, por lo que la cadena se sostiene como un argumento de plausibilidad, no como una reconstrucción.

• Distribución. Un atacante publica una habilidad maliciosa en ClawHub, a veces disfrazada de utilidad y a veces abiertamente maliciosa, y la promociona a través de canales comunitarios; otras veces se descubre de forma orgánica mediante búsquedas y se instala porque la instalación es sencilla.

• Instalación. Un desarrollador o el propio agente inicia la instalación porque la habilidad parece relevante para la tarea. En un despliegue permisivo, ningún humano lo aprueba.

• Acceso al estado. El atacante va tras los tokens, las credenciales en caché, los datos de configuración y las transcripciones, además de los canales de instrucciones persistentes —archivos de tareas, acciones programadas, configuración del agente— que dirigen las ejecuciones futuras.

• Reutilización de privilegios. Con material de identidad válido, el atacante actúa a través de API y herramientas estándar, y la actividad "a menudo se asemeja a una automatización legítima, a menos que se disponga de sólidos controles de monitoreo y registro".

• Persistencia mediante configuración. Lo que queda es un cambio de configuración duradero: «nuevos consentimientos de OAuth, ejecuciones programadas, tareas de agentes modificadas o herramientas que permanecen aprobadas de forma permanente».

El quinto paso contiene la frase más incisiva de la publicación, y la que mejor explica por qué esto es un problema de políticas y no de malware: «El objetivo tiene menos que ver con desplegar malware y más con mantener el control a largo plazo sobre la ruta de automatización». Las herramientas de seguridad que buscan una carga útil no encontrarán nada. Lo que tendrían que detectar es una concesión de consentimiento, una entrada de cron o una herramienta que se dejó aprobada en silencio.

La postura mínima que Microsoft aceptará

Microsoft no deja al lector con un "no lo hagas". Proporciona un mínimo para las organizaciones que deciden evaluar el entorno de ejecución de todos modos, y ese mínimo es más estricto que un sandbox. El entorno debe ser "una máquina virtual dedicada o un dispositivo físico separado que no se utilice para el trabajo diario", y debe tratarse como desechable. Las credenciales deben crearse únicamente para el propósito del agente, sin privilegios, y rotarse suponiendo que ya están comprometidas. Solo deben ser accesibles datos no sensibles. Las instrucciones y el estado guardados del agente deben revisarse periódicamente en busca de reglas persistentes inesperadas, fuentes recién consideradas de confianza o comportamiento que cambie entre ejecuciones. Y una reconstrucción debe ser un control previsto, no una emergencia: reinstalar con regularidad y reconstruir de inmediato ante un comportamiento anómalo.

Un detalle en la publicación es más útil de lo que su longitud sugiere. Hacer una copia de seguridad de .openclaw/workspace/ captura el estado de trabajo del agente sin incluir credenciales; hacer una copia de seguridad de todo el directorio .openclaw/ es más sencillo de restaurar, pero también captura tokens y credenciales, y la publicación advierte que eso puede ser inapropiado si se sospecha que las credenciales están comprometidas. Un equipo que hace una copia de seguridad de todo el directorio y lo llama recuperación ante desastres ha archivado justo lo que el atacante quería.

La guía también es un mapa del producto.

La segunda mitad de la publicación asigna cada control recomendado a un producto de Microsoft: Microsoft Entra ID para privilegio mínimo y acceso condicional en identidades de agentes, Microsoft Defender for Cloud Apps App Governance para inventario de OAuth y deriva de consentimiento, Microsoft Defender for Endpoint para el host del agente, Microsoft Defender XDR para la correlación, Microsoft Purview para la prevención de pérdida de datos en endpoints, Microsoft Defender for Cloud para la salida de red y Microsoft Sentinel cuando se necesita una retención más prolongada o automatización. Eso es una práctica habitual en el blog de seguridad de un proveedor y también vale la pena decirlo claramente: el documento que recomienda contener un runtime de agente de terceros lo publica una empresa que vende la contención.

El contenido de caza de amenazas es la parte que sobrevive a ese planteamiento, porque es específico. La publicación proporciona consultas KQL contra las tablas de Defender XDR —DeviceProcessEvents, CloudProcessEvents, DeviceFileEvents, DeviceNetworkEvents y OAuthAppInfo— que buscan líneas de comandos de procesos y nombres de archivo que contengan "openclaw", "moltbot" o "clawdbot", para invocaciones de clawhub install con slugs de habilidades poco comunes, cambios frecuentes en las carpetas de extensiones en endpoints de desarrolladores, nuevas aplicaciones OAuth con privilegios elevados, servicios en escucha abiertos por procesos de agentes y entornos de ejecución de agentes que lanzan cmd.exe, powershell.exe, pwsh.exe, bash, sh, curl o wget. Independientemente de lo que se piense del mapeo de productos, cualquier cliente de Defender XDR puede ejecutar esas consultas el día de la publicación, y no suponen conocimiento previo de qué hosts están ejecutando el entorno de ejecución.

Qué está establecido y qué no

Establecido y corroborado: Microsoft publicó la entrada el 19 de febrero de 2026, y las citas anteriores proceden de ella. Cybernews informó de la advertencia el 23 de febrero de 2026 y TechRadar el 24 de febrero de 2026, y ambos repitieron las dos frases centrales y la indicación sobre el aislamiento en lugar de someterlas a prueba. Búsquedas repetidas no revelaron cobertura en The Register, BleepingComputer, Wired ni TechCrunch, por lo que la oleada de prensa en torno a esta entrada fue pequeña y derivativa; ninguna parte independiente ha publicado una prueba de la afirmación arquitectónica de Microsoft, y la corroboración disponible confirma lo que dijo Microsoft, no si tiene razón.

La retransmisión también introdujo un error que vale la pena señalar, porque muestra con qué rapidez una advertencia de un proveedor sobre una herramienta de terceros se convierte en una advertencia del proveedor sobre la suya propia. El informe de Cybernews comienza describiendo OpenClaw como «el asistente de IA de Microsoft»; no lo es. OpenClaw es un entorno de ejecución autoalojado que examinaron los investigadores de Microsoft Defender, y la propia publicación establece la distinción estructuralmente, contrastando los entornos de ejecución autoalojados —donde «usted es responsable del radio de impacto» y el host, los plugins y el estado local quedan todos dentro del límite de confianza— con los asistentes gestionados y las plataformas de agentes, donde el entorno de ejecución y las actualizaciones se gestionan de forma centralizada y los controles se centran en ámbitos de identidad, gobernanza de conectores y límites de datos.

No está establecido: que alguna organización específica haya sido comprometida de la manera que describe la publicación. Microsoft afirma que los informes públicos han documentado habilidades maliciosas en registros públicos, pero la publicación no adjunta ningún nombre de campaña, ninguna cifra, ninguna fecha y ninguna víctima, por lo que este registro no conlleva un daño real. Tampoco la recomendación es vinculante. Ningún regulador la emitió, ningún organismo de normalización la adoptó y nada en el registro muestra que un cliente, auditor o aseguradora la trate como un requisito. Es la opinión de un proveedor sobre cómo sus propios clientes deberían tratar una herramienta que no controla —inusualmente categórica e inaplicable.

Lo que sí cambia la publicación es la forma de la pregunta que un equipo de seguridad tiene que responder. Antes del 19 de febrero de 2026, la decisión de ejecutar OpenClaw en un portátil de trabajo podía defenderse como un asunto de configuración y aprobación de piloto. Después, el argumento tiene que sostenerse frente a un documento que afirma que es el propio diseño del runtime, y no sus ajustes, lo que pone en riesgo la máquina — y que no ofrece ninguna versión a la que actualizar, ningún parche que aplicar y ninguna solución en la hoja de ruta. Su remedio es un patrón de despliegue: aislar el runtime, limitar aquello a lo que puede acceder, monitorizarlo de forma continua y estar preparado para reconstruirlo sin demora.