Seguí auditando OpenClaw en AWS Lightsail: 53 skills activas por defecto, canales sin control de acceso y logs que se pueden borrar (Parte 2)

Parte 2 de una serie: En la Parte 1 auditamos el setup inicial de OpenClaw en AWS Lightsail — kernel desactualizado, el attack chain gateway + allow, y el Gateway Token visible en texto claro. Si no la leíste, arranca por ahí.

En la Parte 1 cerré con una advertencia: el setup seguro es el punto de partida, no el destino.

Una vez que el servidor está parcheado, el firewall restringido y las configuraciones de seguridad revisadas — todavía queda todo el dashboard por explorar. Y el dashboard de OpenClaw no es solo una UI. Es un mapa de superficies de ataque: cada sección tiene sus propias implicancias de seguridad, su propio modelo de confianza, su propio blast radius si algo sale mal.

Channels, Agents, Cron Jobs, Nodes, Logs, Config y Debug. Las revisé todas.

Lo que encontré no es catastrófico — OpenClaw no está roto. Pero tampoco está listo para producción con la configuración por defecto. Y hay decisiones de diseño que cualquier equipo debería entender antes de conectar este agente a sus canales de mensajería o a su infraestructura.

Eso es lo que vamos a ver en este post.

Channels: el vector de entrada que viene de afuera

Qué es un Channel en OpenClaw

Un Channel es una integración de mensajería — WhatsApp, Telegram, Discord, Slack, Signal, Google Chat. Una vez configurado, cualquier mensaje que llegue por ese canal se convierte en un prompt para el agente.

La UI lo hace parecer simple: nombre del canal, token de la API, webhook URL. Cinco minutos y está funcionando.

El problema de seguridad está exactamente en esa simpleza.

Finding #6: Sin control de acceso granular a nivel de canal

Cuando conectas un canal a OpenClaw, el agente responde a mensajes. La pregunta que hay que hacerse antes de hacerlo es: ¿a mensajes de quién?

La UI de configuración de canales no expone controles de acceso granular — no hay campo para especificar qué usuarios o roles pueden instruir al agente, ni whitelist de remitentes autorizados. Si el bot está en un grupo de Telegram, el diseño del sistema no ofrece un mecanismo nativo para restringir qué participantes del grupo pueden darle instrucciones.

Esto abre un vector de identity impersonation: alguien con acceso al canal puede instruir al agente a ejecutar tareas como si fuera un usuario legítimo — y el agente no tiene forma de verificar si quien escribe tiene autorización para lo que está pidiendo.

En un entorno empresarial, eso se traduce en escalada de privilegios horizontal: un empleado con acceso al grupo de Slack corporativo donde está integrado el agente puede instruirlo a hacer cosas que están fuera de su rol.

🔍 Finding #6: La UI de configuración de canales no expone controles de acceso granular. En entornos multiusuario, cualquier participante con acceso al canal puede enviar instrucciones al agente, representando un vector de escalada de privilegios horizontal.

Finding #7: Indirect prompt injection via canal

Este es el vector que más me preocupa de toda la serie.

Atacante publica contenido malicioso  →  Agente consume ese contenido  →  Agente ejecuta instrucción oculta
(en un sitio web, un doc, un mensaje)      (como parte de una tarea)         (sin que el usuario lo sepa)

OpenClaw puede navegar la web, leer archivos, procesar documentos. Si alguien le pide al agente "resumí esta página" y esa página contiene instrucciones ocultas diseñadas para manipular su comportamiento, el agente sin guardrails adecuados podría ejecutarlas.

Los canales de mensajería amplían esta superficie. Si el agente está en un grupo donde participan personas externas, cualquiera puede enviar un mensaje con instrucciones embebidas diseñadas para influir en la próxima tarea que ejecute el agente.

Este vector no fue probado en esta instancia — la validación con una demo en vivo va en la Parte 4.

🔍 Finding #7: La integración de canales externos expande la superficie de indirect prompt injection. Contenido malicioso inyectado en canales accesibles al agente puede manipular su comportamiento sin interacción directa del atacante.

Finding #8: Memory poisoning via contexto no validado

OpenClaw mantiene memoria de conversaciones y contexto entre sesiones. No como base de datos — como archivos Markdown planos en disco: un MEMORY.md para contexto de largo plazo y logs diarios en memory/YYYY-MM-DD.md. Si no está escrito en esos archivos, el agente no lo recuerda.

Esa transparencia es buena para auditoría. Pero también define el vector de ataque: si un atacante logra introducir información falsa en esa memoria — via un canal con baja autenticación, via prompt injection indirecta, o via acceso directo al filesystem — esa información persiste y afecta todas las interacciones futuras.

Escenario concreto: el agente tiene en memoria que "el usuario admin es usuario@empresa.com". Un atacante introduce en contexto que ese dato cambió. Dependiendo de cómo el agente use esa memoria en tareas posteriores, las consecuencias pueden ser significativas.

A diferencia de un ataque en tiempo real, el memory poisoning es persistente — los efectos continúan aunque el atacante ya no tenga acceso al sistema.

La validación de este vector también va en la Parte 4.

🔍 Finding #8: La memoria de OpenClaw es archivos Markdown en disco, sin mecanismos de validación de integridad. Información maliciosa introducida en el contexto de memoria puede afectar el comportamiento del agente de forma persistente, incluso después de que el atacante pierda acceso.

Agents: el problema de los permisos por defecto

Qué son los Agents en OpenClaw

OpenClaw permite configurar agentes con distintos modelos, skills habilitadas e instrucciones de sistema. Un agente puede además delegar tareas a otro agente.

Desde productividad, eso es poderoso. Desde seguridad, introduce preguntas que los frameworks modernos todavía están intentando resolver.

Finding #9: 53 skills activas por defecto — modelo opt-out, no opt-in

OpenClaw instala 53 skills bundled como parte del sistema. El comportamiento por defecto no es "nada hasta que habilitás": es todo activo a menos que deshabilites explícitamente. Las skills se activan automáticamente si el CLI tool correspondiente está disponible en el sistema.

Al revisar el agente main en el dashboard, confirmé 50 skills habilitadas — la diferencia con 53 se explica por skills cuyos binarios dependientes no están instalados en esta instancia de Lightsail.

Entre las capacidades disponibles por defecto: ejecución de código, acceso al filesystem, navegación web, envío de emails, interacción con APIs externas, gestión de procesos.

El problema no es el número — es el modelo. El principio de mínimo privilegio dice que un sistema debería tener acceso solo a lo que necesita para cumplir su función. Si tu agente está configurado para responder preguntas sobre documentación interna, no necesita la capacidad de enviar emails ni acceso al filesystem completo.

Cada skill activa innecesariamente es superficie de ataque adicional — ya sea porque un atacante la usa después de comprometer el agente, o porque el propio agente actúa de forma inesperada ante una instrucción ambigua.

🔍 Finding #9: OpenClaw instala 53 skills bundled con un modelo opt-out: todo activo por defecto, el operador debe deshabilitar explícitamente lo que no necesita. Esto invierte el principio de mínimo privilegio y maximiza el blast radius ante cualquier comprometimiento o comportamiento inesperado.

Finding #10: Escalada de privilegios en cadenas de agentes

Cuando el Agente A delega una tarea al Agente B, ¿qué permisos tiene el Agente B para ejecutarla?

La documentación oficial de OpenClaw no define un modelo de herencia de permisos entre agentes — no está especificado qué restricciones del agente origen se propagan al agente destino en una cadena de delegación. Eso significa que el operador no tiene visibilidad de cómo se propaga la confianza en el sistema.

El riesgo derivado de ese gap: si el Agente A tiene restricciones estrictas pero el Agente B tiene configuraciones más permisivas, un atacante que logre que el Agente A delegue al Agente B podría bypassear los controles del primero. El patrón es análogo a la escalada de privilegios en sistemas Unix — no comprometés root directamente, comprometés un proceso con sudo que puede ejecutar lo que necesitás.

Este es un vector de análisis, no un hallazgo probado. La validación va en la Parte 4.

🔍 Finding #10: OpenClaw no documenta un modelo de herencia de permisos entre agentes. La ausencia de especificación sobre cómo se propaga la confianza en cadenas de delegación abre un vector de escalada de privilegios entre agentes con distintas configuraciones de seguridad.

Cron Jobs: la automatización que nadie supervisa

Qué son los Cron Jobs en OpenClaw

Si alguna vez programaste una tarea en Linux con cron, la idea es la misma. En OpenClaw podés decirle al agente: "ejecuta esta tarea cada día a las 8am", y lo hace — sin que tú estés presente.

La UI es simple e intuitiva. Eso es parte del problema.

Finding #11: Cron Jobs como vector de persistencia y defense evasion

Un atacante que logra acceso al dashboard de OpenClaw — via Gateway Token comprometido, por ejemplo — puede crear un Cron Job que establezca persistencia, evada detección o exfiltre datos de forma gradual.

El vector de persistencia es directo: una tarea programada que ejecuta una conexión saliente cada hora mantiene acceso al sistema incluso si el vector original fue cerrado. El de defense evasion también: tareas que borran o modifican logs de forma periódica hacen que un compromiso sea mucho más difícil de detectar.

Lo más preocupante es que una tarea maliciosa es visualmente indistinguible de uso legítimo en la lista de Cron Jobs del dashboard. No hay diferencia visible entre "revisá el estado del sistema cada hora" y una tarea de persistencia.

OpenClaw tiene una sección de Logs en el dashboard, pero no validamos si registra la creación de Cron Jobs ni con qué nivel de detalle — eso lo veremos en la demo de la Parte 4.

🔍 Finding #11: Los Cron Jobs pueden ser usados como mecanismo de persistencia y defense evasion post-compromiso. No hay distinción visual entre tareas legítimas y maliciosas en la UI.

Nodes: distribuir la ejecución, distribuir el riesgo

Qué son los Nodes en OpenClaw

Los Nodes permiten distribuir la ejecución del agente en múltiples máquinas. En lugar de que todo corra en una sola instancia, podés tener nodos independientes ejecutando tareas en paralelo.

Observación sobre Nodes

Cada nodo tiene su propia configuración de exec approvals — independiente de la configuración global. Podés tener un nodo con ask (el agente pide permiso antes de ejecutar) y otro con allow (ejecuta libremente), corriendo al mismo tiempo en el mismo sistema.

Esto tiene una implicancia interesante: el blast radius de un compromiso queda contenido al nodo afectado. Si un atacante compromete un nodo, no necesariamente tiene acceso a los otros.

Pero funciona al revés también: si un nodo tiene configuraciones más permisivas que el resto, ese nodo se convierte en el eslabón más débil de la cadena — el camino de menor resistencia para un atacante.

No identificamos un finding concreto acá porque el comportamiento es por diseño. Lo que sí queda claro es que en un sistema multi-nodo, la postura de seguridad del sistema completo está determinada por el nodo más permisivo, no por el promedio.

Logs: el registro que puede desaparecer

Qué son los Logs en OpenClaw

OpenClaw tiene una sección de Logs en el dashboard que muestra la actividad del agente y permite descargarlos localmente.

Finding #12: Logs locales sin exportación externa

El problema no es que existan logs — el problema es dónde viven.

Los logs de OpenClaw se almacenan localmente en el servidor. Eso tiene dos implicancias directas.

Primera: si el agente tiene exec host policy en gateway — el attack chain que vimos en la Parte 1 — cualquier proceso con acceso al filesystem puede modificarlos o borrarlos. Un atacante que compromete el servidor puede limpiar la evidencia de su actividad antes de que alguien lo detecte.

Segunda: si la instancia falla, los logs se pierden con ella. No hay visibilidad histórica, no hay correlación de eventos entre sesiones, no hay forma de reconstruir qué hizo el agente la semana pasada.

La contramedida obvia es exportar los logs a un destino externo e inmutable — CloudWatch Logs en AWS, por ejemplo — antes de que puedan ser alterados.

🔍 Finding #12: Los logs de OpenClaw son exclusivamente locales. En combinación con un agente con acceso al filesystem, esto facilita la defense evasion post-compromiso y elimina la capacidad de auditoría histórica.

Config y Debug: información interna al alcance del token

Qué son estos paneles

El dashboard de OpenClaw incluye dos paneles que no son para el usuario final — son para quien administra el sistema.

Finding #13: Exposición de información interna via Gateway Token

Cualquier persona que tenga el Gateway Token puede acceder a estos paneles.

El problema no es nuevo — ya lo vimos en la Parte 1: el token está visible en texto claro en el dashboard. Pero lo que no habíamos dimensionado es qué información queda expuesta si ese token se filtra.

Con acceso a Config y Debug, un atacante tiene antes de ejecutar cualquier acción: el mapa completo de cómo está configurado el agente, los paths internos del sistema, el estado en tiempo real de cada componente, y los mensajes de error con detalles de arquitectura interna.

Eso no es una vulnerabilidad de ejecución — es reconocimiento gratuito. Y el reconocimiento es el primer paso de cualquier ataque dirigido.

🔍 Finding #13: Los paneles de Config y Debug exponen información interna del sistema a cualquier poseedor del Gateway Token. En combinación con un token nunca rotado, esto equivale a acceso de lectura permanente al estado interno del agente.

Resumen de findings

Juntando los hallazgos de la Parte 1 y esta Parte 2, el mapa completo hasta ahora:

¿Qué sigue?

Trece findings. Dos críticos, la mayoría altos.

Pero una lista de findings sin estructura es solo ruido. El siguiente paso es darles un marco — entender dónde cae cada uno en el mapa de amenazas del ecosistema agentic AI, y qué tan bien los frameworks existentes los anticiparon.

En la Parte 3 voy a mapear todos estos findings contra tres referencias:

• OWASP Top 10 for Agentic Applications 2026 — el primer framework específico para agentes autónomos, publicado en diciembre 2025.
• AWS Agentic AI Security Scoping Matrix — el framework de AWS para categorizar y priorizar controles de seguridad en sistemas de IA agéntica.
• El threat model oficial de OpenClaw — basado en MITRE ATLAS, con 37 amenazas documentadas por el propio equipo.

No voy a hacer una lectura de frameworks. Voy a mostrar dónde cae cada finding, qué anticiparon los frameworks y — más interesante — qué no anticiparon.

En la Parte 4 vamos a las manos: una demo en vivo donde ponemos a prueba los hallazgos en un entorno controlado. Prompt injection real, validación de los attack chains, y las primeras bases de algo que todavía no existe en LATAM: un modelo de madurez de seguridad para sistemas de IA agéntica.

Sobre el autor

⭐️ GitHub: gerardokaztro

🔗 LinkedIn: gerardokaztro