La escena es demasiado común: ves un asistente local, Open Source, que promete ayudarte con lo que más desgaste genera (mensajes, correo, agenda, archivos). Lo instalas y, en cuestión de minutos, sientes que recuperaste tu día. Moltbot, que hace muy poco todavía se llamaba Clawdbot, se volvió viral precisamente por eso, no es el típico chatbot que aconseja, sino un agente que actúa.

Y ahí aparece el detalle que casi nadie quiere mirar de frente, para que un bot opere, necesita permisos. Y cuando un agente hereda tus permisos, hereda tu alcance completo. En ciberseguridad a eso no le decimos “comodidad”, le decimos radio de impacto.

Lo que hace esto tan severo: el bot guarda y opera con tus secretos

En entornos empresariales el riesgo sube a otro nivel por dos razones: credenciales y sombra.

Token Security describe el patrón típico: el bot requiere acceso amplio (correo, calendario, documentos, mensajería) y puede almacenar configuración y credenciales localmente en texto plano, incluyendo rutas como ~/.clawdbot/ y ~/clawd/. Eso lo vuelve un objetivo natural: cualquier proceso con tu mismo usuario (o un infostealer que caiga en tu endpoint) puede leer esos secretos.

Y todavía más crítico: se recalca que no hay sandboxing por defecto, lo que en la práctica significa que el agente puede acceder a lo mismo que tú, salvo que tú lo aísles explícitamente.

El golpe silencioso: “Shadow AI” dentro de la empresa

Aquí es donde deja de ser un tema de “power users” y se vuelve un tema de dirección.

Token Security afirma que, en su análisis, el 22% de sus clientes tenían empleados usando Moltbot activamente (probablemente sin aprobación de TI).

Y pone un ejemplo que duele por lo real: conectar el bot a Slack/Teams corporativo, pero operar el chat del bot por WhatsApp/iMessage. El resultado es un puente práctico para que información interna (mensajes, archivos, roadmaps) termine resumida y enviada a un canal de consumo, por fuera de DLP (Data Loss Prevention – Prevención de Pérdida de Datos) y auditoría centralizada.

Lecciones ALIGO: cómo aprovechar el valor sin comprar el desastre

No se trata de demonizar el producto. Se trata de tratarlo como lo que es: una identidad privilegiada, 24/7.

Así que, si te quedas con 6 reglas, que sean estas:

• Aísla el bot: idealmente en VM o entorno separado; evita correrlo en tu host con permisos amplios.
• Cero panel público: nada de Gateways/UI expuestos porque es más cómodo; si necesitas remoto, que sea vía túnel VPN y con controles fuertes.
• Principio de mínimo privilegio: tokens separados por función, permisos mínimos, y revocación rápida si algo huele raro.
• Secretos como secretos: si hay credenciales en texto plano, asume que el endpoint es el perímetro y protégelo como tal
• Desconfía de “Skills” y complementos: la cadena de suministro es parte del producto; valida fuentes y evita instalar por hype.
• Política clara de Shadow AI: inventario, reglas de uso, y consecuencias. Si no lo defines, se define solo.

Moltbot no da miedo porque “sea IA”. Da miedo porque cumple: conecta, lee, ejecuta, envía. Y cuando algo así queda mal configurado o mal gobernado, la pérdida no es solo de datos: es de capacidad operativa.

Tres preguntas para dejar sobre la mesa:

Si tu bot tuviera tus permisos hoy, ¿qué podría exponer sin que te des cuenta?

Si tu Gateway/UI quedara público por un proxy mal montado, ¿cuánto tardaría alguien en encontrarlo?

En tu empresa, ¿quién está midiendo cuántos “empleados digitales” ya existen sin contrato ni auditoría?