Después de la publicación inicial de este artículo, el proyecto anteriormente conocido como Clawdbot y Moltbot completó otro cambio de marca y ahora se llama OpenClaw. La arquitectura agencial subyacente y las consideraciones de seguridad que se analizan aquí siguen siendo relevantes bajo el nuevo nombre.
---
Clawdbot se convirtió en uno de los agentes de IA de código abierto más comentados a principios de 2026, no porque fuera otro chatbot, sino porque cruzó una línea que muchas herramientas no habían cruzado. Combinaba grandes modelos de lenguaje con acceso directo y autónomo a sistemas operativos, archivos, credenciales y plataformas de mensajería.
Pero lo que los usuarios ganaron en productividad, los atacantes lo ganaron como una nueva superficie de ataque.
Y cuando Clawdbot cambió su nombre a Moltbot debido a problemas con la marca registrada, el perfil de riesgo volvió a cambiar. No porque el agente subyacente hubiera cambiado, sino porque la rápida popularidad chocó con la falta de preparación operativa. En la prisa por renombrar repositorios, dominios y cuentas sociales, aparecieron lagunas en la propiedad. Los atacantes se movieron más rápido que los administradores, secuestrando identidades abandonadas y explotando la confianza de la comunidad en cuestión de segundos.
El cambio del proyecto a OpenClaw vino acompañado de un renovado enfoque en el diseño centrado en la seguridad y de advertencias más claras sobre los riesgos del acceso autónomo al sistema, lo que indica que los responsables del mantenimiento reconocen ahora la brecha de seguridad que pusieron de manifiesto los primeros usuarios.
Ahora, la adopción explosiva de la herramienta juega a favor del atacante. Una ola de usuarios en rápido crecimiento está ansiosa por probarla, clonarla, integrarla y ejecutarla con amplios permisos antes de que se comprendan completamente las cuestiones de seguridad. Esa combinación, altos privilegios, adopción viral y confusión momentánea de identidad, convierte una herramienta de automatización ya de por sí sensible en un objetivo muy atractivo.
Clawdbot no está diseñado para estar expuesto de forma predeterminada. Si no te sientes cómodo fortaleciendo un servidor, entendiendo los límites de confianza del proxy inverso y ejecutando servicios de alto privilegio con controles de privilegio mínimo, esto no es algo que debas implementar en un VPS público.
El proyecto asume un nivel de madurez operativa que muchos usuarios subestiman, y la mayoría de los fallos reales observados hasta ahora se deben a la configuración, no a vulnerabilidades.
Esta no es una historia sobre un proyecto de IA fallido. Es una historia sobre cómo se forman los ataques modernos cuando la confianza, la automatización y la identidad avanzan más rápido que los controles de seguridad.
Para comprender por qué Clawdbot atrae a los atacantes tan rápidamente, es útil observar cómo funciona realmente el agente una vez que se ha implementado.
TL;DR
- Moltbot convierte la automatización en una superficie de ataque de alto privilegio cuando se expone o se configura incorrectamente.
- La mayoría de las vulnerabilidades en el mundo real se deben a errores de configuración y abuso de confianza, no a vulnerabilidades de día cero.
- Una vez comprometido, el agente permite el robo de credenciales, el movimiento lateral y el ransomware.
- Los agentes autónomos de IA deben tratarse como infraestructura privilegiada, no como herramientas de productividad.
- Si no puedes reforzar y supervisar la seguridad, no la expongas.
El resto de este artículo explica cómo Moltbot se convirtió tan rápidamente en un objetivo atractivo , cómo lo utilizan los atacantes en la práctica y qué significa esto para el futuro de la seguridad de la IA agencial. Los lectores que busquen orientación operativa pueden pasar directamente a la sección sobre refuerzo de la seguridad, situada hacia el final.
El agente de IA como superusuario persistente en la sombra
Clawdbot fue diseñado para ejecutarse en infraestructuras controladas por el usuario, ordenadores portátiles, servidores domésticos, cloud e incluso ordenadores de placa única. Puede ejecutar comandos de shell, leer y escribir archivos, navegar por la web, enviar correos electrónicos o mensajes de chat y mantener la memoria persistente entre sesiones. En la práctica, actúa como una capa de automatización con altos privilegios, que a menudo contiene claves API, tokens OAuth, credenciales de chat y, en ocasiones, acceso de nivel raíz. Este diseño colapsa múltiples límites de confianza en un único sistema. Las plataformas de mensajería, los sistemas operativos locales, cloud y las herramientas de terceros convergen a través de un agente autónomo. Una vez implementado, Clawdbot deja de ser solo una aplicación y pasa a formar parte de la estructura de seguridad del entorno.
Desde la perspectiva de un atacante, esto es ideal. Comprometa el agente una vez y herede todo a lo que pueda acceder, en todos los entornos.
Una vez que existe ese nivel de acceso, los atacantes no necesitan nuevas técnicas, simplemente reutilizan las que ya conocen a través de un intermediario mucho más capaz.
Cómo los atacantes abusan de Clawdbot en la práctica
Una vez que Clawdbot, ahora Moltbot, se implementa, la pregunta ya no es si se puede abusar de él, sino cómo. Ya se han informado algunas técnicas (exposición por configuración incorrecta y trucos de la cadena de suministro), mientras que otras, como la inyección de comandos, están bien documentadas en investigaciones y se vuelven realistas cuando los agentes pueden leer contenido no confiable y ejecutar herramientas.
Acceso inicial: donde el agente se convierte en el punto de entrada
La forma más habitual en que Clawdbot se ve comprometido no es a través de un exploit inteligente, sino por simple exposición. La interfaz de usuario de control es una interfaz administrativa diseñada para acceder a ella de forma local. En la práctica, algunos usuarios la hacen accesible accidentalmente desde la Internet pública debido a una configuración incorrecta, puertos abiertos o configuraciones de proxy inseguras.
Cuando eso ocurre, un panel de control administrativo local puede empezar a comportarse como un panel de control remoto.
Parte de la confusión proviene de cómo se expone la palabra expuesto . En la práctica, existen diferencias significativas:
- Conectado a Internet: accesible a través de una IP y un puerto públicos.
- Huella digital: detectable por Shodan o Censys porque la respuesta HTTP coincide con las firmas de Moltbot o Clawdbot, incluso si la autenticación está habilitada.
- Sin autenticar o eludido: se puede acceder a la interfaz de usuario de control sin un emparejamiento o credenciales válidos, a menudo debido a una configuración incorrecta. Este es un caso peligroso.
Esta distinción es importante. Una vez que se puede acceder a una interfaz administrativa desde la Internet pública, el descubrimiento se vuelve fácil. Los motores de búsqueda como Shodan pueden detectar estos sistemas rápidamente, convirtiendo un solo error de configuración en un problema generalizado.
Las capturas de pantalla públicas que muestran un gran número de resultados de Clawdbot pueden ser engañosas. Muchas representan sistemas que son visibles pero que siguen estando protegidos. El riesgo real reside en el pequeño número de casos en los que la autenticación es inexistente o ineficaz.
En esas situaciones, se puede acceder a la interfaz de usuario de control desde la Internet pública y los atacantes pueden ver los datos de configuración, acceder al historial de conversaciones o emitir comandos, dependiendo de cómo se haya configurado el agente.
Incluso cuando los usuarios creen que la autenticación está habilitada, los valores predeterminados inseguros y las configuraciones incorrectas del proxy han permitido a los atacantes eludirla por completo. No zero-day requiere zero-day . Una sola regla de reescritura o reenvío de encabezados puede derrumbar la frontera entre el acceso confiable y el no confiable. Una vez dentro, los atacantes heredan todo lo que el agente puede hacer.
No todos los accesos iniciales requieren exposición a la red o una configuración incorrecta.
Ingeniería social e inyección rápida
La capacidad de Clawdbot para leer correos electrónicos, mensajes de chat y documentos crea una nueva superficie de ataque en la que la carga útil es el lenguaje, no malware.
La inyección rápida se ha demostrado en investigaciones y configuraciones prácticas de agentes: un mensaje elaborado puede, en ocasiones, llevar a un agente a filtrar datos confidenciales o realizar acciones no deseadas, incluso cuando el atacante nunca toca directamente el host.
La defensa no consiste tanto en «corregir un error» como en limitar lo que el agente puede hacer, quién puede comunicarse con él y cómo gestiona el contenido no fiable.
Cuando los atacantes logran afianzarse en el host, el diseño local de Clawdbot crea una segunda vía más silenciosa para tomar el control.
Malware los datos de Clawdbot
malware los ladrones de información de los puntos finales no necesitan un exploit específico de Clawdbot para beneficiarse de las implementaciones de agentes. Si los tokens, los artefactos OAuth o el estado del agente se almacenan localmente, y especialmente si se almacenan en texto sin formato, entonces un compromiso rutinario del punto final puede escalar hasta el control del agente y de todos los servicios conectados a los que pueda acceder.
En otros casos, los atacantes nunca tocan directamente al host, sino que llegan a través de extensiones e integraciones de confianza.
Abuso de la cadena de suministro, complementos y extensiones maliciosas
El modelo de complementos de Clawdbot introduce otro vector de acceso inicial. Las extensiones se ejecutan como código en la misma máquina que el agente y heredan sus permisos. Un complemento malicioso, o uno legítimo comprometido, funciona como ejecución remota instantánea de código. El agente se convierte en el mecanismo de entrega.
Más allá del software principal, los atacantes también han abusado del ecosistema circundante. Recientemente se utilizó una extensión falsa de Clawdbot VS Code para instalar el troyano de acceso remoto ScreenConnect, aprovechando la confianza de los desarrolladores en el nombre del proyecto para obtener un control remoto total. La extensión parecía legítima, llevaba la marca correcta y se basaba en el momento oportuno y el reconocimiento del nombre, más que en una vulnerabilidad del software.
Este tipo de ataque se vuelve más eficaz durante los cambios de marca. Cuando los nombres de los proyectos, los repositorios y los dominios cambian rápidamente, los atacantes aprovechan la confusión para publicar repositorios o extensiones similares que parecen legítimos. La vulnerabilidad suele producirse antes de que se revise el código, ya que se da por sentada la confianza basándose en el nombre y el momento.
La defensa aquí no consiste tanto en aplicar parches como en verificar la identidad. Tras un cambio de marca, las instalaciones deben limitarse a la organización oficial de GitHub y al dominio del proyecto. Los repositorios recién creados o patrocinados merecen un escrutinio adicional, y los complementos o habilidades deben restringirse a listas de permisos seleccionadas.
Lo mismo se aplica a las herramientas de desarrollo. En el caso de las extensiones de editor, compruebe el editor, revise el historial y la cadencia de actualización, y compruebe los hash o las firmas cuando estén disponibles. En este ecosistema, la confianza en la cadena de suministro forma parte del límite de seguridad.
Una vez instalada una extensión maliciosa, no se requiere ningún otro exploit y el control se establece de inmediato.
Comando y control: convertir al agente en el canal C2
Si un atacante obtiene acceso a la interfaz de usuario de control o a cualquier canal que pueda ejecutar herramientas, Clawdbot se convierte en sí mismo en el marco de comando y control. A través de la interfaz de control o la API, pueden emitir comandos de shell, recopilar resultados y operar de forma interactiva. El riesgo no es que Moltbot rompa mágicamente la seguridad por sí mismo, sino que un agente comprometido ya tenga incorporadas vías de ejecución, persistencia y comunicación.
Abuso de integraciones legítimas
Clawdbot puede enviar mensajes a través de Slack, Telegram, correo electrónico y otras plataformas utilizando credenciales legítimas. Los atacantes pueden abusar de estas integraciones para extraer datos o recibir instrucciones, mezclándose perfectamente con el tráfico normal. Desde el punto de vista de la detección, esto parece un comportamiento de automatización esperado, no tráfico C2.
El intermediario en la capa cognitiva
Si un atacante puede modificar la configuración, las indicaciones o la memoria almacenada del agente (por ejemplo , después de obtener acceso al sistema de archivos), puede intentar influir en lo que ve el usuario y en lo que hace el agente.
En la práctica, esto podría significar modificar resúmenes, suprimir alertas o insertar instrucciones ocultas que se activen más tarde. Es mejor considerar esto como un posible resultado de un compromiso, no como una capacidad garantizada en una configuración debidamente aislada.
El control del agente también derriba las fronteras tradicionales de los privilegios.
Escalada de privilegios y abuso de credenciales
Si Clawdbot se ejecuta como un usuario estándar, los atacantes pueden utilizarlo para ejecutar técnicas tradicionales de escalada de privilegios. En muchas implementaciones, la escalada es innecesaria porque el agente ya se ejecuta con permisos elevados, especialmente en configuraciones contenedorizadas o de usuario único.
Clawdbot centraliza las credenciales por diseño. Las claves API, los tokens OAuth, las credenciales de chat, cloud y, en ocasiones, el acceso VPN se encuentran todos en un solo lugar. Una vez recopiladas, estas credenciales permiten a los atacantes suplantar la identidad de los usuarios, acceder cloud y moverse lateralmente sin volver a tocar el sistema original.
En entornos híbridos, este impacto se multiplica. Un agente comprometido que se ejecuta en un ordenador portátil puede exponer el acceso SaaS de la empresa. Uno que se ejecuta en la cloud tener permisos IAM que permiten a los atacantes crear infraestructura, acceder a almacenes de datos o manipular los procesos de CI/CD. El agente se convierte en un puente entre entornos que nunca estuvieron destinados a estar conectados directamente.
Una vez asegurado el acceso, los atacantes se centran en permanecer en el lugar sin ser detectados.
Persistencia: cuando el agente recuerda al atacante
Dado que los agentes suelen mantener el estado a largo plazo en el disco, un host comprometido puede convertir ese estado en persistencia. Si un atacante puede escribir en la memoria o la configuración del agente, puede dejar instrucciones o artefactos que sobrevivan a los reinicios y sigan causando acciones dañinas hasta que se reconstruya el sistema y se roten los secretos.
Dado que Clawdbot está diseñado para funcionar de forma continua y realizar tareas según un calendario, los atacantes pueden incorporar acciones recurrentes. La exfiltración de datos, la enumeración del sistema o las comunicaciones salientes pueden activarse automáticamente, sin necesidad de interacción adicional.
Con acceso al shell, los atacantes también pueden recurrir a métodos clásicos de persistencia, tareas programadas, scripts de inicio o puertas traseras adicionales. La diferencia es que Clawdbot suele ocultar estas acciones tras una automatización legítima, lo que dificulta el análisis forense.
El verdadero daño comienza cuando el agente comprometido se utiliza como puente hacia todo lo demás.
Movimiento lateral e impacto más amplio
A partir de un único agente comprometido, los atacantes pueden escanear redes internas, reutilizar credenciales y moverse lateralmente. Y dado que Clawdbot suele abarcar cloud personales, empresariales y cloud , el compromiso en un dominio a menudo conduce al compromiso en los tres.
Las credenciales robadas permiten a los atacantes acceder a plataformas SaaS, herramientas de colaboración interna y cloud . Pueden suplantar la identidad de los usuarios, enviar mensajes que parecen fiables y propagar aún más el acceso a través de canales sociales que los defensores rara vez supervisan como vías de ataque.
En el extremo más grave, los atacantes pueden utilizar Clawdbot para desplegar ransomware, destruir datos o sabotear operaciones. El agente ya tiene acceso a los archivos, derechos de ejecución y canales de comunicación. Cada acción destructiva es simplemente otra «tarea» que el asistente debe completar.
En conjunto, estos comportamientos ponen de manifiesto un cambio más amplio en la forma en que se desarrollan los ataques modernos.
Cuando la automatización se convierte en una superficie de ataque
Clawdbot captura tanto la promesa como el riesgo de la IA autónoma. Ofrece una potente automatización, pero esa misma autonomía crea una superficie de ataque de gran valor. Las interfaces expuestas, las entradas maliciosas y malware adaptado malware los atacantes reutilizar el agente para el comando y control, el abuso de privilegios, la persistencia y el movimiento lateral. Estas técnicas difuminan la línea entre las vías de intrusión tradicionales y el abuso impulsado por la IA, con un impacto que abarca los sistemas personales, cloud y las redes empresariales. Un agente comprometido puede permitir desde el robo de datos específicos hasta un ransomware a gran escala, dependiendo de a qué esté conectado.
Clawdbot/Moltbot debe abordarse como una infraestructura altamente privilegiada, y no como un experimento casual de fin de semana, ya que centraliza las credenciales y puede ejecutar acciones en todas las cuentas y dispositivos. La autenticación fuerte, la exposición restringida a la red y el manejo cuidadoso de los secretos son requisitos imprescindibles. Las organizaciones necesitan visibilidad sobre dónde se ejecutan estos agentes, aplicar segmentación y supervisar comportamientos anómalos, como acciones no solicitadas o comunicaciones inesperadas. La inyección rápida añade otra capa de riesgo, en la que el abuso puede ser invisible a menos que se supervise el comportamiento del agente.
Clawdbot se comporta como un superusuario en la sombra dentro del entorno. A medida que los agentes autónomos se vuelven más comunes, la lección es clara: la capacidad sin control es exposición. La responsabilidad ahora recae en los usuarios y los equipos de seguridad para proteger estos agentes antes de que los atacantes lo hagan por ellos.
Comprender este cambio es solo el primer paso. Para reducir el riesgo, es necesario tratar Moltbot como cualquier otro sistema privilegiado y aplicar controles deliberados en torno a la exposición, la identidad, la ejecución y la supervisión.
Cómo reducir el riesgo al ejecutar Moltbot
Los agentes autónomos no fallan con elegancia. Una vez implementados con un amplio acceso, los pequeños errores de configuración pueden tener un impacto desmesurado. El objetivo del endurecimiento no es hacer que Moltbot sea «seguro», sino limitar el radio de acción, reducir la exposición y hacer que el abuso sea detectable.
1. Lista de verificación para el endurecimiento de la línea base
2. Aislamiento del host y la infraestructura
- No exponga la interfaz de usuario de control a la red pública de Internet. Es preferible utilizar una VPN como Tailscale o WireGuard, o un túnel SSH a localhost. Aísle el agente de las cargas de trabajo de producción.
- No ejecute Moltbot en el mismo VPS que aloja servicios de backend, bases de datos o archivos personales.
- Endurezca SSH en cualquier VPS. Desactive la autenticación por contraseña y el inicio de sesión como root, utilice solo claves y habilite las reglas del cortafuegos, además de la limitación de velocidad o fail2ban.
- Ejecute el agente como usuario no root. Evite los contenedores con privilegios y nunca monte el sistema de archivos del host ni el socket de Docker.
- Aplique parches con regularidad. Instale las actualizaciones del sistema operativo, actualice las imágenes de contenedor y rote las claves de larga duración.
3. Control de la interfaz de usuario y configuración de la puerta de enlace
- Asigne la puerta de enlace y la interfaz de usuario de control a 127.0.0.1, a menos que sea estrictamente necesario el acceso remoto.
- Habilite la autenticación de la interfaz de usuario de control y verifique la configuración del proxy inverso para que los clientes remotos no sean tratados como localhost.
- Registrar y alertar sobre nuevos emparejamientos de dispositivos, cambios de configuración y eventos de ejecución de herramientas.
4. Canales e integraciones
- Utiliza listas de permisos estrictas para determinar quién puede enviar mensajes al bot. El valor predeterminado debe ser denegar por defecto.
- Desactive o limite las herramientas de alto riesgo, como el acceso al shell, la escritura de archivos y la automatización del navegador, a menos que sea absolutamente necesario.
- Utiliza cuentas separadas con ámbitos de privilegios mínimos para las integraciones, como cuentas de Gmail dedicadas, ámbitos restringidos para bots de Slack y tokens limitados de GitHub.
- Trate los códigos QR y los URI que vinculan dispositivos como contraseñas. No deje artefactos de emparejamiento en lugares accesibles para todo el mundo y, si quedan expuestos, cámbielos o vuelva a vincularlos.
- Prefiere las cuentas de bot por servicio y limita la exposición. Evita los servidores públicos de Discord y bloquea los mensajes directos a una lista de permitidos.
5. Secretos y tratamiento de datos
Estas son ubicaciones predeterminadas comunes que se deben auditar en su host. Trátelas como sensibles y bloquee los permisos:
Controles adicionales:
- Trata al agente como un gestor de secretos. Bloquea los permisos de los archivos y cifra el almacenamiento siempre que sea posible.
- Rote y revoque los tokens de forma agresiva tras cualquier sospecha de exposición. Prefiera los tokens OAuth de corta duración a las claves API de larga duración.
- Limite la retención del historial de conversaciones y los archivos adjuntos. Un valor predeterminado sencillo es de 7 a 14 días para los registros de sesión, que se rotan o eliminan semanalmente, con cifrado en reposo si se requiere una retención más prolongada.
6. Inyección rápida y contenido no confiable
- Asuma que cualquier correo electrónico, documento, página web o mensaje de chat puede contener instrucciones hostiles.
- No permita que texto no confiable active directamente comandos de shell o exportaciones de credenciales.
- Utiliza políticas de herramientas por canal. Por ejemplo, permite el resumen en el correo electrónico o Slack, pero rechaza las acciones de shell o escritura de archivos desde Telegram o Discord.
- Solicitar confirmación humana para acciones de alto riesgo, como ejecutar comandos, exportar archivos, cambiar la configuración o iniciar sesión.
- Considere la automatización del navegador como un riesgo elevado. Utilice un perfil de navegador independiente y sin sesión iniciada para el agente y nunca reutilice una sesión personal.
- Un patrón útil es el etiquetado del origen del contenido combinado con una política de herramientas por origen y la confirmación obligatoria para las herramientas de alto riesgo.
7. Supervisión y detección, cobertura mínima viable
Abreviatura de ATT&CK para defensores
- Acceso inicial: interfaz de usuario de control expuesta o abuso de la cadena de suministro.
- Ejecución: invocaciones de shell y herramientas
- Acceso a credenciales: tokens locales y archivos de configuración
- Persistencia: configuraciones modificadas, memoria o complementos
- Mando y control: canales de chat
- Exfiltración: cargas y webhooks
Señales mínimas a tener en cuenta
- Controla los fallos de autenticación de la interfaz de usuario, los emparejamientos de nuevos dispositivos y los cambios de configuración.
- Invocaciones de herramientas como ejecuciones de shell, lecturas y escrituras de archivos, automatización del navegador y cargas salientes.
- Cambios inesperados en el sistema de archivos en ~/.clawdbot/* y el espacio de trabajo del agente.
- Actividad de red, como nuevos dominios salientes, picos en la mensajería o tráfico inusual de webhooks.
- Señales del host, como registros del cortafuegos en los puertos Moltbot, eventos de inicio de sesión SSH y procesos secundarios inusuales.
8. Si sospecha que ha estado expuesto: respuesta rápida
- Detenga el servicio y conserve las pruebas. Realice una instantánea de la máquina virtual o del contenedor y recopile los registros del sistema, además de ~/.clawdbot/*.
- Rote y revoque credenciales. Reemplace tokens, revoque sesiones OAuth, rote claves SSH y vuelva a emitir claves API de larga duración.
- Invalida las rutas de acceso. Desactiva los canales expuestos, restablece las listas de permitidos y rota el emparejamiento o las contraseñas de la interfaz de usuario de control.
- Borrar el historial confidencial cuando sea necesario. Eliminar las transcripciones de las sesiones si contienen información secreta y, a continuación, aplicar un periodo de retención breve.
- Reconstruya si tiene dudas. Si se pudo acceder al host sin una autenticación sólida o se sospecha que se ejecutaron comandos, reconstruya a partir de una imagen limpia y vuelva a vincular los canales con cuidado.
- Puntos de persistencia posteriores a la comprobación, como servicios systemd, crontab, claves autorizadas SSH y complementos o extensiones instalados.
Qué llevarse
- Trata a Moltbot como una infraestructura privilegiada. Guarda secretos, ejecuta comandos y se comunica a través de canales de confianza.
- La mayoría de los fallos son problemas de configuración, no vulnerabilidades. Las interfaces de usuario de control público, la configuración deficiente de los proxies, los canales abiertos y las herramientas demasiado potentes son los responsables de la mayoría de los incidentes.
- La identidad forma parte de la superficie de ataque. Confíe solo en organizaciones, dominios y extensiones oficiales, especialmente durante los cambios de marca.
- Si no puedes reforzar la seguridad, no lo expongas. Mantén la interfaz de usuario de control en localhost o VPN, restringe los canales y exige confirmación para las acciones de riesgo.
Para defenderse contra este modelo, es necesario tener visibilidad del comportamiento, no solo de los activos. Aquí es donde entra en juego la Vectra AI se vuelve fundamental, ya que brinda a los equipos de seguridad la capacidad de detectar los comportamientos de los atacantes que surgen cuando se abusa de la automatización confiable en entornos de identidad, red, cloud e híbridos, antes de que esos comportamientos se conviertan en un compromiso total.
---
Fuentes:
- Guía oficial de seguridad de Moltbot/Clawdbot (fortalecimiento, proxy inverso, autenticación): https://docs.clawd.bot/gateway/security
- Sitio web oficial del proyecto: https://molt.bot (también https://clawd.bot)
- Repositorio/organización oficial de GitHub: https://github.com/moltbot/clawdbot (página de la organización: https://github.com/clawdbot/)
- Artículo educativo de Chirag (@mrnacknack) sobre errores comunes de configuración y rutas de inyección de comandos (utilizar como contexto secundario): https://x.com/mrnacknack/article/2016134416897360212 (véanse también los hilos de @theonejvo).
- Cobertura de Cointelegraph sobre casos expuestos y riesgo de fuga de credenciales (a través del espejo de TradingView): https://www.tradingview.com/news/cointelegraph:99cbc6b7d094b:0-viral-ai-assistant-clawdbot-risks-leaking-private-messages-credentials/
- Resumen de Binance News sobre el secuestro de GitHub/X y la confusión sobre la estafa de tokens: https://www.binance.com/en/square/post/01-27-2026-clawdbot-founder-faces-github-account-hijack-by-crypto-scammers-35643613762385
- Cronología de la comunidad DEV sobre el cambio de nombre y la ola de suplantaciones fraudulentas: https://dev.to/sivarampg/from-clawdbot-to-moltbot-how-a-cd-crypto-scammers-and-10-seconds-of-chaos-took-down-the-internets-hottest-ai-project-4eck
- Análisis de seguridad de Aikido de una extensión falsa de Clawdbot VS Code:malware
- Registro de cambios del proyecto (para realizar un seguimiento de los cambios relacionados con la seguridad): https://github.com/clawdbot/clawdbot/blob/main/CHANGELOG.md
- Informes secundarios sobre el interés de los ladrones de información en los ecosistemas Clawdbot/Moltbot (orientativos, no definitivos): https://www.infostealers.com/article/clawdbot-the-new-primary-target-for-infostealers-in-the-ai-era/