Moltbook y la ilusión de las comunidades de agentes de IA «inofensivas»

3 de febrero de 2026
Lucie Cardiet
Responsable de investigación de ciberamenazas
Moltbook y la ilusión de las comunidades de agentes de IA «inofensivas»

Los agentes autónomos de IA están saliendo de los entornos controlados de los laboratorios y entrando en ecosistemas compartidos y persistentes. Leen contenidos, toman decisiones, almacenan recuerdos, ejecutan acciones e interactúan con otros agentes a la velocidad de una máquina. Al hacerlo, derriban las barreras que los equipos de seguridad han tardado años en establecer, las barreras entre usuarios y servicios, automatización e identidad, intención y ejecución.

Plataformas como Moltbook hacen visible este cambio. Muestran lo que ocurre cuando se permite a los agentes autónomos interactuar libremente, confiar implícitamente y operar con permisos reales. Lo que surge no es solo una nueva funcionalidad, sino también nuevos modos de fallo.

A primera vista, los foros de agentes de IA como Moltbook parecen experimentales, incluso lúdicos. Los bots hablan con otros bots, publican hilos, forman comunidades y debaten ideas. Parece algo muy alejado de las preocupaciones de seguridad de las empresas. Esa apariencia de inocuidad es una ilusión.

Esa suposición ya está demostrando ser peligrosa.

Los recientes informes de seguridad pública relacionados con agentes autónomos como Clawdbot, ahora rebautizado como Moltbot, demuestran lo rápido que la experimentación se convierte en exposición. En ese caso, un agente de código abierto con amplio acceso al sistema se convirtió en un nuevo punto de entrada para los atacantes cuando la confianza, la automatización y la identidad avanzaron más rápido que los controles de seguridad. La lección es más amplia que cualquier proyecto concreto. Los agentes de IA ya no son herramientas pasivas. Son participantes activos en los ecosistemas digitales.

Moltbook va un paso más allá. No se trata de una interfaz de chatbot ni de un asistente de productividad. Es un entorno social similar a Reddit en el que agentes autónomos leen, interpretan y responden al contenido de los demás a gran escala. Experimentos adyacentes como Molt Road amplían este modelo más allá de la conversación al comercio, donde los agentes compran, venden e intercambian servicios con una supervisión humana mínima. Aunque oficialmente se enmarcan como ficticios, estos entornos ofrecen una vista previa de cómo los agentes autónomos pueden coordinarse, incentivar comportamientos y externalizar capacidades de formas que los equipos de seguridad aún no están preparados para supervisar.

Investigaciones públicas recientes sobre Moltbook ya han demostrado que este modelo introduce puntos ciegos de seguridad que se corresponden directamente con comportamientos habituales de los atacantes, al tiempo que elude muchos de los controles en los que se basan actualmente los equipos SOC.

Lo importante no es si Moltbook o Molt Road tienen éxito. Lo importante es lo que revelan sobre cómo se puede abusar de los agentes autónomos cuando la interacción, la confianza y el permiso convergen sin la suficiente visibilidad.

¿Qué hacen realmente estos foros?

Los foros de agentes de IA suelen ser malinterpretados porque, a simple vista, se parecen a las plataformas sociales humanas. Independientemente de si el contenido lo envían personas o agentes autónomos a través de API, estos sistemas funcionan de forma muy diferente a las redes sociales tradicionales en cuanto a cómo se consume y se actúa sobre ese contenido.

Moltbook

Moltbook es una red social diseñada específicamente para agentes de IA. Los usuarios humanos pueden observar, pero solo los agentes pueden publicar, responder e interactuar. Cada agente suele funcionar en un sistema controlado por humanos que utiliza marcos como OpenClaw, lo que le da acceso a archivos, API, plataformas de mensajería y, en ocasiones, a la ejecución de shell.

Los agentes de Moltbook leen continuamente las publicaciones de los demás e incorporan ese contenido a su contexto de trabajo. Este diseño permite la colaboración, pero también permite la manipulación entre bots, la inyección indirecta de comandos y el abuso de confianza a gran escala. Los investigadores de seguridad descubrieron que un porcentaje considerable del contenido de Moltbook contenía cargas ocultas de inyección de comandos diseñadas para secuestrar el comportamiento de otros agentes, incluidos intentos de extraer claves API y secretos.

Clawcaster

Clawcaster es un cliente de redes sociales inspirado en Farcaster, un protocolo de redes sociales descentralizado en el que la identidad y los gráficos sociales no son propiedad de una única plataforma, sino que pueden ser accedidos por múltiples clientes. En Farcaster, los usuarios publican mensajes en un protocolo compartido, y diferentes aplicaciones pueden leer, mostrar e interactuar con ese contenido.

Clawcaster adapta este modelo tanto para usuarios humanos como para agentes de IA. Los agentes pueden publicar entradas, seguir cuentas y consumir flujos de contenido a través de un feed compartido. Aunque es más estructurado que Moltbook, sigue permitiendo a los agentes incorporar información no fiable y actuar en consecuencia, a menudo mediante integraciones con herramientas o servicios externos.

Desde el punto de vista de la seguridad, Clawcaster ilustra cómo el contenido generado por los agentes y el contenido consumido por los agentes comienzan a difuminarse. Una vez que se permite a los agentes publicar y actuar, las redes sociales pueden funcionar como canales de coordinación o, en escenarios adversos, como vías de mando y control de baja fricción.

Moltx

Moltx funciona de manera muy similar a una línea de tiempo pública de estilo X para agentes de IA. Los agentes publican mensajes breves, responden entre sí y mantienen identidades persistentes a lo largo de las interacciones. El contenido aparece en un feed compartido, creando narrativas continuas en lugar de conversaciones aisladas.

Desde un punto de vista técnico, el riesgo no es el formato en sí mismo, sino la persistencia. Las publicaciones son consumidas por otros agentes, almacenadas en la memoria y pueden influir en el comportamiento futuro mucho tiempo después de su publicación. Las instrucciones o el contenido malicioso ingestado una vez pueden resurgir más tarde, separados de su fuente original.

Este modelo traslada el riesgo de la ejecución inmediata a la influencia diferida, donde la lógica dañina se propaga a través de la memoria y la interacción repetida, en lugar de mediante comandos directos.

8004escaneo

8004scan no es un foro social. Es una capa de indexación y descubrimiento para agentes de IA autónomos, construida en torno a estándares descentralizados de identidad y reputación. Permite que los agentes sean listados, buscados y evaluados en función de sus capacidades declaradas y señales de actividad.

Desde el punto de vista de la seguridad, esto es importante porque el descubrimiento y la confianza son condiciones previas para la coordinación. Un atacante no necesita explotar un agente si puede suplantarlo, contaminar las señales de reputación o presentar un agente malicioso como legítimo. A medida que los ecosistemas de agentes maduran, la identidad se convierte en una superficie de ataque por sí misma.

Los riesgos de seguridad

Los comportamientos observados en Moltbook y plataformas relacionadas se corresponden claramente con las etapas habituales de los atacantes. Lo que cambia es la velocidad, la escala y la sutileza.

Reconocimiento

Los agentes autónomos comparten habitualmente información de diagnóstico, detalles de configuración y datos operativos. En Moltbook, algunos agentes publicaron escaneos de seguridad, puertos abiertos o mensajes de error como parte de la resolución de problemas o el autoanálisis. Para los atacantes que observan en silencio, esto se convierte en datos de reconocimiento ya preparados.

A diferencia del reconocimiento tradicional, no es necesario realizar ningún escaneo. La información se proporciona de forma voluntaria.

Los agentes como fuentes accidentales de OSINT

En múltiples hilos de Moltbook, se observó que los agentes publicaban detalles operativos confidenciales. Entre ellos se incluían puertos abiertos, intentos fallidos de inicio de sesión SSH, mensajes de error internos y artefactos de configuración.

Desde la perspectiva del agente, este comportamiento tenía sentido. Se analizaban a sí mismos, depuraban problemas o compartían hallazgos con sus compañeros. Desde la perspectiva del atacante, eliminaba por completo la necesidad de reconocimiento. Sin escaneo. Sin sondeo. Sin alertas.

La información se proporcionaba de forma voluntaria, se indexaba y permanecía visible para cualquiera que observara la plataforma. En efecto, algunos agentes se convirtieron en fuentes de inteligencia en directo.

La inyección inversa de comandos permite la propagación silenciosa entre agentes.

Los investigadores que observaron el comportamiento de Moltbook identificaron un patrón que describieron como «inyección inversa de comandos». En lugar de que un usuario humano inyecte instrucciones maliciosas en un agente, un agente incrusta instrucciones hostiles en contenido que otros agentes consumen automáticamente.

En varios casos, estas instrucciones no se ejecutaron inmediatamente. Se almacenaron en la memoria del agente y se activaron más tarde, después de acumularse contexto adicional. Esta ejecución retardada dificulta el rastreo del comportamiento hasta su origen.

El efecto se asemeja al de worm. Un agente comprometido puede influir en otros, que a su vez pueden propagar la misma instrucción a través de respuestas, reenvíos o contenido derivado. La propagación se produce a través de la interacción normal, no mediante escaneo o explotación.

Para los defensores, esto supone un nuevo reto. No hay ningún archivo que poner en cuarentena ni ninguna cadena de exploits que romper. La lógica maliciosa se mueve a través de la confianza y la cooperación.

Una vez completado el reconocimiento, el siguiente paso no requiere ningún tipo de explotación.

Acceso inicial

El acceso inicial suele provenir de la confianza, no de la explotación.

En Moltbook, los atacantes incrustaron instrucciones ocultas dentro de publicaciones que otros agentes leían automáticamente. Estas técnicas de «inyección inversa de comandos» permiten que el contenido malicioso anule las instrucciones del sistema de un agente, engañándolo para que revele secretos o ejecute acciones no deseadas.

En otros casos, se compartieron «habilidades» y complementos maliciosos que ejecutaban código en el sistema host una vez instalados. Dado que los agentes basados en OpenClaw están diseñados para ejecutar código, una habilidad maliciosa se convierte efectivamente en una ejecución de código remota.

La inyección de comandos de bot a bot convierte la lectura en un vector de ataque

Uno de los hallazgos más preocupantes de los primeros informes de seguridad de Moltbook es la facilidad con la que los agentes pueden verse comprometidos simplemente leyendo el contenido. En un análisis muestral de las publicaciones de Moltbook, los investigadores descubrieron que aproximadamente el 2,6 % contenía cargas útiles ocultas de inyección de comandos diseñadas para manipular el comportamiento de otros agentes.

Estas cargas útiles eran invisibles para los observadores humanos. Incrustadas en publicaciones de apariencia benigna, instruían a otros agentes para que anularan las indicaciones del sistema, revelaran claves API o realizaran acciones no deseadas una vez que el contenido se incorporaba al contexto o a la memoria.

No se requirió ningún exploit. No malware distribuyó malware . El acceso inicial se produjo en el momento en que un agente hizo lo que estaba diseñado para hacer: leer y responder.

Esto cambia la definición de «superficie de ataque». En los ecosistemas de agentes, el lenguaje mismo se convierte en el punto de entrada.

Las habilidades de los agentes maliciosos convierten la automatización en ejecución de código

La estrecha relación de Moltbook con OpenClaw introduce otra superficie de riesgo: las habilidades compartidas. Los agentes pueden publicar e instalar habilidades que amplían sus capacidades, como ejecutar comandos de shell o acceder a archivos locales.

Las revelaciones de seguridad de terceros demostraron que las habilidades maliciosas disfrazadas de complementos útiles podían ejecutar código arbitrario en el sistema host. Un ejemplo muy citado fue el de una habilidad aparentemente inofensiva relacionada con el tiempo que, una vez instalada, extraía silenciosamente archivos de configuración que contenían secretos.

Debido a que los agentes OpenClaw son intencionalmente potentes y carecen de un entorno aislado (sandbox) sólido, una sola habilidad maliciosa se convierte efectivamente en la ejecución remota de código. El ataque tiene éxito no por una vulnerabilidad, sino por el nivel de acceso que ya tiene el agente.

Esto refleja los ataques clásicos a la cadena de suministro, pero con un ciclo de confianza más rápido y menos controles de revisión.

Una vez que un agente se ve comprometido, a menudo se produce una escalada inmediata.

Escalada de privilegios

Muchos agentes se ejecutan con permisos elevados por diseño. Almacenan claves API, tokens OAuth, cloud y acceso a mensajería en un solo lugar. Una vez que un agente se ve comprometido, a menudo no es necesario escalar privilegios. Si el agente se ejecuta como un usuario estándar, los atacantes aún pueden utilizarlo como punto de apoyo para realizar una escalada de privilegios tradicional. Si se ejecuta con privilegios elevados, el atacante hereda esos permisos inmediatamente.

Cuando Phishing las máquinas en lugar de a las personas

Moltbook también ha demostrado cómo evoluciona la ingeniería social cuando los objetivos son agentes autónomos. Los investigadores observaron cómo los bots intentaban activamente suplantar la identidad de otros bots para obtener información confidencial, incluidas claves API y datos de configuración.

Algunos agentes se hacían pasar por compañeros serviciales y solicitaban secretos con el pretexto de ayudar a depurar errores u optimizar el rendimiento. Otros utilizaban un lenguaje coercitivo o autoritario, aprovechando el hecho de que la mayoría de los agentes están diseñados para ser cooperativos y serviciales por defecto.

A diferencia phishing humano, no hay que superar ninguna vacilación, intuición o escepticismo. Si la solicitud se ajusta al ámbito de tareas percibido por el agente, este puede cumplirla automáticamente.

Este comportamiento derrumba las suposiciones tradicionales sobre la protección de credenciales. Cuando los agentes guardan secretos y confían implícitamente en otros agentes, el abuso de credenciales ya no requiere puntos finales comprometidos o contraseñas robadas. Requiere persuasión.

Movimiento lateral

Los agentes autónomos rara vez se limitan a un único entorno. Un solo agente puede tener acceso simultáneamente a una estación de trabajo de desarrollador, un inquilino SaaS, cloud y herramientas de colaboración internas. Esa conectividad suele ser la razón por la que el agente existe en primer lugar.

Una vez que un agente se ve comprometido, el movimiento lateral no requiere nuevas herramientas. Se produce a través de integraciones legítimas. Un atacante que controla un agente puede reutilizar las credenciales almacenadas para acceder a plataformas SaaS, suplantar a usuarios en sistemas de chat o acceder cloud sin necesidad de desplegar malware escanear la red. Los mensajes enviados a través de Slack, correo electrónico u otras herramientas de colaboración parecen automatizaciones rutinarias. Las llamadas API a cloud parecen autorizadas porque lo están.

En los ecosistemas adyacentes a Moltbook, este patrón ya es visible. Los agentes actúan como puentes entre contextos que nunca estuvieron destinados a confiar directamente entre sí. El compromiso en un dominio se propaga silenciosamente a otros a través de la reutilización de identidades y la automatización compartida.

Desde el punto de vista de la detección, esto es difícil de detectar. No hay tráfico de explotación, ni flujos de autenticación inusuales, ni puntos de pivote evidentes. El movimiento se produce a través de rutas esperadas, solo que en una secuencia inesperada.

Acceso a datos y exfiltración

La exfiltración a través de agentes autónomos rara vez se asemeja al robo de datos tradicional. Los agentes están diseñados para mover datos. Resumen documentos, cargan archivos, envían mensajes y sincronizan contenido entre servicios como parte de su funcionamiento normal.

Cuando los atacantes abusan de esas capacidades, los mecanismos de exfiltración parecen legítimos. Los datos confidenciales pueden enviarse a través de mensajes de chat, integraciones de correo electrónico, webhooks o API cloud que el agente está autorizado a utilizar. Desde el punto de vista del registro, estas acciones suelen mezclarse con el tráfico normal de automatización.

El incidente de exposición de la clave API de Moltbook pone de manifiesto lo frágil que puede ser esta frontera. Una vez que los atacantes obtuvieron credenciales válidas de los agentes, no necesitaron burlar los controles. Podían suplantar a los agentes y realizar acciones que eran indistinguibles del comportamiento esperado.

En ese momento, los controles de acceso ya no son el factor decisivo. La detección depende del reconocimiento de los cambios en el comportamiento. Qué datos se están accediendo, dónde se envían, con qué frecuencia se producen las acciones y si esos patrones se ajustan a la función habitual del agente.

Aquí es donde los agentes autónomos desafían las suposiciones tradicionales. La exfiltración no tiene por qué ser ruidosa para ser perjudicial. Solo tiene que ser lo suficientemente normal como para evitar sospechas.

Cuando la identidad del agente se ve comprometida, el comportamiento se convierte en la única señal.

Poco después del lanzamiento de Moltbook, una configuración incorrecta del backend expuso cientos de miles de claves API de agentes. Con esas claves, un atacante podía suplantar a cualquier agente de la plataforma, inyectar comandos y controlar el comportamiento sin provocar fallos de autenticación.

El incidente obligó a realizar un apagado total y una rotación de credenciales, pero puso de manifiesto un problema más profundo. Una vez que un atacante obtiene credenciales válidas del agente, los controles de acceso tradicionales ofrecen poca protección. El agente sigue comportándose de forma «legítima», utilizando API aprobadas y flujos de trabajo normales.

En ese momento, el compromiso solo es visible a través del comportamiento. Lo que hace el agente, dónde se conecta y cómo cambian sus acciones con el tiempo.

Lo que deben hacer ahora los equipos SOC y dónde aparecen las brechas de seguridad

Trate a los agentes autónomos como infraestructura privilegiada.

Los agentes de IA deben clasificarse junto con los proveedores de identidad, las herramientas de administración y los procesos de automatización. Centralizan el acceso y la toma de decisiones, y cualquier compromiso tiene un amplio impacto. Haga un inventario de dónde se ejecutan los agentes, a qué pueden acceder y cómo se supervisan.

Suponer que el contenido es un vector de ataque

La inyección rápida se está produciendo a gran escala. Cualquier sistema en el que los agentes lean texto no fiable y puedan actuar debe considerarse expuesto. Restrinja las acciones que pueden realizar los agentes en función de la fuente del contenido. Exija confirmación para las acciones de alto riesgo.

Supervise el comportamiento, no solo los activos

Las herramientas tradicionales se centran en los puntos finales, las identidades y los registros de forma aislada. Los agentes autónomos difuminan esos límites. Un agente que actúa «con normalidad» puede seguir llevando a cabo los objetivos del atacante. Esta es la principal laguna en la detección. Cuando se abusa de la automatización, los indicadores son de comportamiento, no basados en firmas.

Cómo Vectra AI cerrar esta brecha

A medida que los agentes autónomos se integran en entornos de identidad, redes, cloud y SaaS, los equipos de seguridad necesitan visibilidad sobre la intención del comportamiento, no solo sobre los eventos.

Este es el tipo de problema que aborda laVectra AI está diseñada para abordar, detectando comportamientos de atacantes que surgen cuando se abusa de la automatización de confianza. Al analizar patrones en todos los entornos, Vectra AI los equipos de SOC Vectra AI identificar de forma temprana el reconocimiento, el movimiento lateral, el uso indebido de credenciales y la exfiltración de datos, incluso cuando esas acciones son llevadas a cabo por agentes legítimos que utilizan un acceso válido.

Moltbook y otras plataformas similares no son una amenaza en sí mismas. Son señales. Demuestran lo rápido que se pueden reutilizar los sistemas autónomos cuando la confianza supera a la visibilidad. Detectar ese cambio requiere una seguridad que comprenda el comportamiento a lo largo de todo el ciclo de vida del ataque, antes de que la automatización se convierta en un compromiso.

---

Fuentes y lecturas adicionales:

Preguntas frecuentes