OpenClaw exige prudencia

OpenClaw: un asistente de IA que actúa en tu ordenador

Un “agente” local puede ahorrar tiempo, pero también concentra permisos, credenciales y extensiones en un mismo punto: conviene entender bien el riesgo antes de conectarlo a servicios personales o de la Universidad.

Introducción

Cuando alguien pregunta si OpenClaw “se puede usar con seguridad”, normalmente no está pensando en un virus clásico, sino en algo más cotidiano: que el asistente acceda al correo, al calendario, a ficheros de clase, a carpetas compartidas o a un chat de grupo… y que, por error o por engaño, haga más de la cuenta.

En un entorno universitario, además, los permisos suelen mezclarse: el mismo portátil sirve para preparar material docente, tramitar gestiones, responder tutorías, consultar bibliografía, trabajar con datos de investigación o revisar convocatorias. Es justo esa mezcla la que convierte a herramientas “muy capaces” en herramientas que hay que evaluar con calma y con límites claros.

Este artículo no pretende demonizar OpenClaw ni dar recetas técnicas complejas. La idea es ayudarte a decidir: qué es, qué riesgos son realistas, qué señales conviene mirar y en qué condiciones tendría sentido probarlo sin arrastrar a tu día a día (ni a la Universidad) a un problema evitable.

Qué es OpenClaw y por qué importa

OpenClaw se presenta como un asistente personal de IA “autoalojado”: en lugar de ser solo una web donde chateas, es un agente que puedes ejecutar en tu propio equipo y que, además de responder, puede realizar acciones. En la práctica, eso suele incluir operar con ficheros locales, hacer peticiones de red y ejecutar tareas automatizadas en tu nombre (por ejemplo, ordenar información, gestionar mensajes o coordinar pequeñas rutinas). Este enfoque “local” y orientado a acciones está descrito de forma directa en análisis técnicos recientes sobre su ecosistema y su uso de skills (extensiones) [VirusTotal, 2026].

El punto diferencial no es que “use IA”. Es que combina tres cosas en un mismo entorno:

Acceso a servicios: para ser útil, tiende a conectarse a cuentas y plataformas (mensajería, correo, almacenamiento, calendarios).
Acceso al sistema: al ejecutarse en tu máquina, puede ver y tocar lo que tú ves y tocas (ficheros, sesiones, tokens, ajustes).
Extensibilidad: se amplía con skills; y una skill, en la práctica, es código de terceros que ejecutas con tus permisos (y con los del propio agente) [VirusTotal, 2026].

¿Por qué importa dentro y fuera de la Universidad? Porque el riesgo real no suele ser “me va a hackear alguien famoso”, sino algo mucho más probable: que una integración demasiado amplia, una skill de procedencia dudosa o un fallo corregido tarde conviertan tu ordenador (o una cuenta) en un punto de fuga de datos o en una puerta a acciones no deseadas.

Qué se ve desde fuera: señales útiles y límites

Si alguien está probando OpenClaw (o una herramienta similar), hay señales prácticas que ayudan a decidir si vas por buen camino o si conviene parar y replantear. Ninguna señal aislada demuestra un problema; lo útil es la combinación.

Permisos demasiado amplios para el objetivo: si lo que quieres es “resumir un texto” y el asistente necesita acceso de escritura a tus carpetas, a tu correo y a un repositorio, hay un desajuste.
Instalación o “configuración” basada en copiar y pegar: si una guía te empuja a ejecutar comandos o instalar binarios sin explicar bien el porqué, ese es el momento de frenar. En este tipo de ecosistemas, la ingeniería social suele disfrazarse de “pasos de setup” [VirusTotal, 2026].
Skills con promesas grandilocuentes o poco verificables: “automatiza todo”, “optimiza tus notas”, “gestiona tu correo solo” sin detallar límites, permisos y mantenimiento.
Comportamiento que no esperabas: acciones que aparecen como “sugerencias” pero acaban siendo ejecuciones, cambios de configuración o integraciones nuevas que no recuerdas haber aprobado.
Solicitudes de compartir ficheros sensibles: si te pide subir actas, listados, documentación de investigación o capturas de pantallas con información personal, ya estás cruzando una línea que en la Universidad requiere un tratamiento muy cuidadoso.

El límite importante: incluso haciendo las cosas “bien”, un agente local puede verse afectado por fallos de software o por contenido malicioso que no parece malicioso (una web, un mensaje, un documento). Por eso la pregunta no es solo “¿es fiable el proyecto?”, sino “¿en qué entorno lo ejecuto, con qué permisos y con qué plan de contención?”.

Qué ocurre por dentro (sin jerga)

Para decidir con criterio, basta con entender tres ideas: credenciales, persistencia y extensiones.

1) Credenciales y sesiones. Para actuar por ti, el agente necesita “pruebas” de que puede hacerlo: tokens, sesiones iniciadas, claves de API u otros mecanismos de autenticación. Lo relevante es que esos accesos pueden quedar guardados para no pedirte permiso cada vez. Una guía de seguridad reciente resume el riesgo así: credenciales y datos accesibles pueden quedar expuestos, y la propia memoria/estado persistente del agente puede modificarse con el tiempo si procesa entradas maliciosas [Microsoft Security Blog, 2026].

2) Persistencia (“se queda viviendo”). Un asistente que solo responde en una web es efímero. Un agente local suele estar diseñado para permanecer encendido, recordar contexto y retomar tareas. Esa “comodidad” también significa que, si algo se tuerce, el impacto puede durar más que una sesión puntual [Microsoft Security Blog, 2026].

3) Skills (extensiones) como código. En OpenClaw, las skills amplían funciones. Eso es útil, pero abre una superficie de riesgo parecida a instalar extensiones de navegador: no estás instalando “ideas”, estás instalando software. Investigaciones recientes describen que, en este tipo de ecosistema, las skills se han convertido en un canal atractivo para distribuir código malicioso camuflado de automatización [VirusTotal, 2026].

Con estas tres piezas, se entiende por qué se habla de dos “cadenas de suministro” a la vez: por un lado, el código (skills, dependencias); por otro, las instrucciones (texto externo que el agente lee: páginas web, mensajes, documentos). Una guía lo expresa de forma clara: ambas cadenas convergen en un mismo bucle de ejecución [Microsoft Security Blog, 2026].

Riesgo 1: Skills maliciosas o inseguras (técnica “cebolla”)

Capa 1 (lo que ve la persona): “He encontrado una skill genial para conectar X, automatizar Y o descargar Z”. Suele venir acompañada de una guía rápida y la sensación de que “todo el mundo la usa”.

Capa 2 (lo que pasa en el sistema/servicio): esa skill es software de terceros ejecutándose con acceso real: puede leer ficheros, usar credenciales ya guardadas o abrir conexiones de red. Si está mal diseñada o es maliciosa, el daño no necesita “romper” nada: le basta con operar con tus permisos [VirusTotal, 2026].

Capa 3 (cómo ayuda el STIC): orientando sobre buenas prácticas (mínimo privilegio, separación de cuentas), ayudando a evaluar señales, y apoyando en contención y recuperación si algo se instala o se ejecuta indebidamente (sin necesidad de culpabilizar: estas situaciones suelen aparecer con prisas y multitarea).

Riesgo 2: Entradas maliciosas (prompt injection) y decisiones automatizadas (técnica “cebolla”)

Capa 1 (lo que ve la persona): un mensaje “normal”, una web “informativa” o un documento que el agente consulta para ayudarte.

Capa 2 (lo que pasa en el sistema/servicio): el agente mezcla texto externo con acciones internas. Si el contenido externo está diseñado para manipular, puede empujar al agente a actuar fuera de intención (por ejemplo, revelar información o cambiar configuraciones), especialmente si la experiencia está diseñada para ser “fluida” y con pocas confirmaciones [Microsoft Security Blog, 2026].

Capa 3 (cómo ayuda el STIC): recomendaciones prácticas para reducir exposición (entornos aislados, credenciales dedicadas, confirmaciones), y apoyo si sospechas que una cuenta o un equipo ha quedado en un estado no deseado.

Riesgo 3: Fallos de software que amplían el impacto (técnica “cebolla”)

Capa 1 (lo que ve la persona): “solo he abierto un enlace”, “solo he entrado en una web”, “solo he visto un panel”.

Capa 2 (lo que pasa en el sistema/servicio): un fallo en la forma en que una interfaz o un componente gestiona conexiones o tokens puede permitir que un tercero consiga control. En OpenClaw se registró un caso de alta severidad, con puntuación CVSS 8,8, corregido en la versión 2026.1.29 (afectaba hasta 2026.1.28) [GitHub Advisory Database, 2026].

Capa 3 (cómo ayuda el STIC): insistiendo en la actualización como hábito, apoyando en la evaluación de impacto si se ha usado una versión vulnerable, y guiando en revocación de accesos y revisión de cuentas afectadas (lo que suele ser más importante que “reinstalar” a ciegas).

Qué está en juego en la Universidad

En la Universidad, el riesgo no se mide solo en “me han fastidiado el portátil”. Se mide en continuidad de actividad y en exposición de información que, por su naturaleza, es sensible aunque no lo parezca a primera vista.

Docencia: materiales, evaluaciones, actas, comunicaciones con estudiantes, tutorías y gestión de grupos.
Gestión y administración: expedientes, trámites, comunicaciones internas, documentación de procesos, cuadros de seguimiento.
Bibliotecas y recursos académicos: cuentas, historiales, préstamos, accesos remotos y consultas asociadas.
Movilidad y convocatorias: documentación personal, formularios, justificantes, calendarios, plazos.
Investigación financiada: borradores, memorias, datos, presupuestos, documentación contractual, colaboración con terceros.

En todos esos casos, el patrón de riesgo es parecido: un agente con acceso a un buzón, a un almacenamiento o a carpetas sincronizadas puede exponer o modificar información sin que haya un “ataque ruidoso”. A veces basta un permiso excesivo o una extensión poco fiable para provocar una fuga o una alteración.

Por eso, si alguien quiere experimentar con OpenClaw en el contexto universitario, la recomendación general es separar claramente el “laboratorio” del “trabajo real”: no mezclarlo con cuentas institucionales, ni con ficheros de docencia o gestión, ni con datos de investigación. Si no puedes separarlo, lo sensato es no probarlo en ese equipo.

Cómo ayuda el STIC

El STIC no está para “prohibir por prohibir”, sino para ayudarte a tomar decisiones con menos fricción y menos riesgo. En temas como OpenClaw, el apoyo suele ir por cuatro líneas:

Orientación previa: ayudarte a decidir si el caso de uso compensa el riesgo y, si se prueba, en qué condiciones mínimas (entorno aislado, cuentas dedicadas, datos no sensibles).
Contención: si hay señales de que algo ha ido mal, apoyar para cortar el acceso y limitar el impacto (desconexión de integraciones, revocación de tokens, revisión de permisos).
Recuperación: guiar en el restablecimiento seguro (cuentas, sesiones, contraseñas, revisiones básicas del equipo) y en la vuelta a la normalidad.
Aprendizaje sin culpa: estas situaciones suelen ocurrir en momentos de carga, entregas o plazos. Avisar pronto ayuda más que “aguantar” por miedo a haber cometido un error.

Si estás valorando usar un agente de este tipo para tareas relacionadas con la Universidad, lo mejor es consultarlo antes de conectarlo a correo institucional, Microsoft 365/Google Workspace o almacenamiento corporativo. Así se puede evitar que un experimento acabe afectando a trabajo real.

Lo que ha cambiado en 2025–2026

En el último año y pico, han cambiado dos cosas que influyen directamente en la seguridad de estos asistentes:

De “chat” a “agente”: el salto es pasar de responder a actuar. Eso desplaza el foco: ya no importa solo lo que el modelo “dice”, sino lo que el sistema “hace” con permisos reales.
De “una app” a “un ecosistema”: aparecen marketplaces de extensiones (skills) y guías comunitarias. Es útil, pero también acelera la propagación de dependencias inseguras y de contenido engañoso [VirusTotal, 2026].

También ha ganado relevancia un concepto que conviene nombrar sin dramatismo:

Prompt injection: contenido externo (texto, mensajes, páginas) diseñado para que el agente ignore tu intención y siga instrucciones de un tercero. No hace falta que “rompa” nada; le basta con persuadir al agente dentro del flujo normal de trabajo [Microsoft Security Blog, 2026].

Y, en paralelo, estamos viendo más avisos de seguridad y correcciones rápidas en proyectos muy populares. Esto es normal en software que crece deprisa: cuanto más se usa, más se investiga y más se encuentra. Lo importante es cómo se gestiona: actualizaciones, control de extensiones y aislamiento.

Datos recientes en contexto

Sin caer en “numeritis”, estos datos ayudan a dimensionar el fenómeno y su superficie de riesgo:

Popularidad y velocidad de adopción: en el repositorio oficial se observan 251k estrellas, señal de uso masivo y de mucha atención pública [GitHub, 2026].
Reutilización y derivaciones: ese mismo repositorio refleja 48,3k forks, lo que sugiere muchas copias, pruebas y variantes en circulación [GitHub, 2026].
Movimiento constante del proyecto: se listan 59 releases, lo que es positivo (corrige y evoluciona) pero también exige disciplina de actualización [GitHub, 2026].
Un ejemplo de fallo con impacto real: se registró una vulnerabilidad con severidad CVSS 8,8, corregida en la versión 2026.1.29 (afectaba hasta 2026.1.28) [GitHub Advisory Database, 2026].
Recomendación de despliegue conservadora: una guía publicada el 19/02/2026 aconseja tratar este tipo de runtime como ejecución de código no confiable con credenciales persistentes y evaluarlo solo en entornos totalmente aislados [Microsoft Security Blog, 2026].

Nota útil: cuando se citan informes de proveedores o laboratorios privados, conviene leerlos como benchmarks y recordar que pueden variar por sector, muestra y metodología. Aun así, suelen ser valiosos para entender tendencias y patrones.

Checklist en 30 segundos

No lo instales en tu ordenador “de diario”: separa laboratorio y trabajo real; reduces el impacto si algo sale mal.
Usa un entorno aislado: una máquina virtual o un equipo dedicado limita el alcance de permisos y ficheros [Microsoft Security Blog, 2026].
Credenciales dedicadas y sin privilegios: evita conectar cuentas principales; si solo necesitas probar, usa cuentas de prueba con datos no sensibles.
Menos integraciones, más control: empieza sin correo ni almacenamiento; añade solo lo imprescindible y revisa el “para qué”.
Instala skills con criterio: asume que una skill es software; si no entiendes su procedencia y permisos, no la instales [VirusTotal, 2026].
Actualiza con frecuencia: en herramientas de adopción rápida, los parches importan porque aparecen fallos y se corrigen deprisa [GitHub Advisory Database, 2026].
Evita el “copiar y pegar” como norma: si una guía te pide ejecutar pasos sin explicación, para y valida por otra vía.
No uses ficheros sensibles como “prueba”: si quieres probar resumen o clasificación, usa documentos neutros (sin datos personales, sin actas, sin expedientes).
Confirma acciones relevantes: si el agente puede actuar, define un hábito de confirmación antes de cambios (envíos, borrados, comparticiones).
Ten un plan de salida: saber cómo revocar accesos y apagar el entorno reduce estrés si detectas algo raro [Microsoft Security Blog, 2026].

Qué hacer si ya ha pasado (sin tecnicismos)

Si crees que OpenClaw (o un agente similar) ha hecho algo que no esperabas, o si has instalado una skill y luego te has quedado con mala sensación, lo importante es actuar con orden. Lo primero no es “investigar durante horas”, sino cortar el alcance.

Para la automatización: apaga el servicio o detén el entorno donde se ejecuta; evita que siga actuando mientras decides.
Desconecta integraciones: revoca accesos a servicios conectados (correo, chat, almacenamiento) y elimina tokens/llaves asociados si los has creado.
Cambia contraseñas si procede: especialmente si el agente tuvo acceso a sesiones o a gestores; prioriza cuentas con más alcance.
Revisa acciones “silenciosas”: reenvíos en correo, comparticiones nuevas en almacenamiento, reglas automáticas, autorizaciones persistentes.
Guarda evidencias sin obsesionarte: anota qué instalaste, cuándo y qué notaste (mensajes, permisos solicitados, comportamientos). Ayuda mucho al soporte.
Cuanto antes, mejor: avisar pronto suele reducir impacto y tiempo total de recuperación.

Canal de ayuda y reporte: Jira

Privacidad y trato respetuoso

En la Universidad convivimos con información académica, administrativa y personal. La privacidad no es un “extra”: es parte del respeto básico entre personas y del cumplimiento normativo. Con agentes que acceden a cuentas y ficheros, hay tres reglas sencillas que evitan muchos problemas:

Minimiza datos: si no es imprescindible, no lo subas, no lo conectes y no lo compartas con una automatización.
Separa contextos: lo personal, lo docente, lo administrativo y la investigación no deberían mezclarse en el mismo “laboratorio” de pruebas.
Evita identificar a terceros: aunque el agente “solo vaya a resumir”, si el documento contiene datos de estudiantes, compañeros o participantes, trátalo como sensible.

Si tienes dudas sobre si un caso de uso encaja con el tratamiento adecuado de la información, la opción prudente es pedir orientación antes de conectar cuentas o de mover documentos. Es más fácil prevenir que deshacer una compartición o una automatización mal planteada.

Prestar atención al uso

OpenClaw no es “una app más”: es un asistente que puede actuar en tu ordenador y, por diseño, tiende a vivir cerca de tus permisos. Esa capacidad es su atractivo y, al mismo tiempo, su principal punto de riesgo.

¿Se puede usar con seguridad? En términos prácticos: se puede evaluar de forma razonablemente controlada si lo tratas como ejecución de código no confiable, lo aislas, limitas credenciales y eres exigente con las skills y con los permisos [Microsoft Security Blog, 2026]. Si lo conectas sin separación a tu correo, tus carpetas y tu trabajo universitario, el margen de error se reduce mucho.

Si te interesa probarlo, hazlo como harías con cualquier herramienta potente: con un entorno dedicado, datos no sensibles y un plan de salida. Y si algo no cuadra, no lo normalices: para, verifica y pide ayuda/reporta.