Parte 1 de una serie: Setup seguro, hallazgos reales y superficie de ataque de un agente autónomo de IA en AWS Lightsail.
AWS acaba de anunciar la disponibilidad general de OpenClaw en Amazon Lightsail — un agente de IA autónomo, open-source y self-hosted que puede conectarse a WhatsApp, Telegram, Discord y ejecutar tareas de forma independiente: correr código, gestionar archivos, navegar la web.
La comunidad está encendida probándolo. Yo también lo hice — pero con el sombrero de Cloud Security Engineer.
En este post no te voy a explicar cómo usarlo como asistente. Te voy a mostrar qué encontré mientras lo configuraba desde una perspectiva de seguridad, qué decisiones tomé y por qué.
¿Qué es OpenClaw exactamente?
Antes de hablar de seguridad, alineemos conceptos.
Un LLM (como Claude o GPT) recibe un prompt y devuelve texto. Eso es todo.
Un agente autónomo es diferente: tiene acceso a herramientas (terminal, browser, APIs), decide en qué orden usarlas, interpreta los resultados y actúa — sin que vos le indiques cada paso. El LLM es el "cerebro", pero el agente es el sistema completo que actúa en el mundo real.
OpenClaw es exactamente eso: un agente que corre en tu servidor, usa un LLM (en este caso via Amazon Bedrock) como motor de razonamiento, y puede ejecutar tareas de forma autónoma a través de canales de mensajería.
Esa autonomía es lo que lo hace poderoso. Y también lo que lo hace interesante desde seguridad.
El setup en Lightsail
AWS empaquetó OpenClaw como blueprint en Lightsail — lo que significa que podés tener una instancia corriendo en minutos sin configuración manual.
Lo que vi en el wizard (y lo que me llamó la atención)
El keypair de SSH:Lightsail te da dos opciones: que AWS genere el keypair, o que vos subas el tuyo.
La recomendación de seguridad es clara: generá el tuyo localmente.
ssh-keygen -t ed25519 -C "openclaw-sandbox"¿Por qué? Cuando AWS genera el keypair, la clave privada se crea en sus servidores y viaja hasta vos para que la descargues. Ese momento de transmisión es un riesgo evitable. Si lo generás vos, la clave privada nunca sale de tu máquina.
La analogía: la clave pública es el candado que ponés en el servidor. La clave privada es la llave que solo vos tenés. Cualquiera puede ver el candado, nadie más puede abrirlo.
El firewall (Security Group):💡 Recordá: siempre
chmod 400sobre tu clave privada. Si tiene permisos644, otros usuarios del sistema pueden leerla — y el propio cliente SSH te va a advertir.
Por defecto, Lightsail dejó abiertos los puertos 80, 443 y 22 a 0.0.0.0/0 — cualquier IP del mundo.
Para un sandbox personal eso es innecesario. Cambié las tres reglas para restringirlas solo a mi IP:
curl ifconfig.me # obtené tu IP públicaMenos superficie de ataque expuesta = menos blast radius si algo sale mal.
Primer hallazgo: el SO desactualizado
Al conectarme por SSH, el mensaje de bienvenida fue directo:
44 updates can be applied immediately.
31 of these updates are standard security updates.
El blueprint de AWS llegó con 31 parches de seguridad sin aplicar. Incluyendo un parche de kernel y actualización de intel-microcode.
¿Por qué importa el kernel? Porque es el núcleo del SO — controla memoria, procesos y permisos. Vulnerabilidades de kernel conocidas como Dirty Pipe o Spectre/Meltdown permiten escalar privilegios o leer memoria de otros procesos.
En un servidor que corre contenedores Docker (como OpenClaw), un kernel sin parchear puede ser explotado para un container escape — salir del contenedor aislado y tomar control del host completo.
La solución es simple:
sudo apt update && sudo apt upgrade -y
sudo reboot
🔍 Finding #1: Blueprint de OpenClaw en Lightsail desplegado con kernel y librerías del sistema desactualizadas. Cualquier cliente que lo use en producción sin aplicar parches queda expuesto a CVEs conocidas.
Lo más interesante: los Security Settings de OpenClaw
Después del setup, OpenClaw te presenta 5 configuraciones de seguridad. Acá es donde la cosa se pone interesante.
1. File & folder protection → Status: ✓ Protected
- Browser remote control → Status: ✓ Disabled
- Exec host policy → Status: ~ Not set (defaults to sandbox)
- Shell command approval → Status: ~ Unrestricted
- Access token → Status: ~ Never rotated
Setting 3: Exec host policy
Este controla dónde el agente ejecuta comandos de shell.
sandbox(default): los comandos corren dentro de un contenedor Docker aislado.gateway: los comandos corren directamente en el SO del servidor.
La diferencia de blast radius es enorme. Con gateway, si el agente es comprometido, el atacante tiene acceso directo al filesystem, variables de entorno, el IAM role — todo.
Setting 4: Shell command approval
Este controla si el agente pide permiso antes de ejecutar un comando.
deny: bloquea todos los comandos de shell.allow: los ejecuta libremente sin preguntar.
El attack chain que no podés ignorar
Acá está el escenario más peligroso, y es completamente posible si no configurás bien:
exec host policy: gateway + shell command approval: allowSi a esto le sumás un ataque de prompt injection — donde alguien inserta instrucciones maliciosas en contenido que el agente consume (un email, un archivo, una página web) — el atacante puede tomar control del servidor sin que vos te enteres.
Este encadenamiento de configuraciones débiles se llama attack chaining, y es exactamente el tipo de análisis que hay que hacer antes de poner un agente en producción.
🔍 Finding #2: La combinación de
exec host policy: gateway+shell command approval: allowelimina todas las capas de aislamiento del agente. En producción, esto representa un riesgo crítico.
Setting 5: El Gateway Token visible en el dashboard
El Gateway Token es la "contraseña" del agente — quien lo tiene, controla OpenClaw completamente.
El problema: está visible en texto claro en el dashboard.
Cualquier screenshot del dashboard, cualquier grabación de pantalla, cualquier persona que mire por encima de tu hombro — compromete el acceso al agente.
AWS recomienda rotarlo frecuentemente y no hardcodearlo en archivos de configuración. Pero el hecho de que sea visible por defecto en la UI es un diseño que hay que tener en cuenta.
🔍 Finding #3: El Gateway Token se muestra en texto claro en el dashboard. En combinación con un dashboard expuesto a internet, esto representa exposición directa de credenciales.
IPv6 habilitado por defecto
Un detalle que pasa desapercibido: el blueprint viene con dual-stack (IPv4 + IPv6) habilitado por defecto.
El problema de seguridad: muchas reglas de firewall están escritas pensando en IPv4. El tráfico IPv6 puede pasar desapercibido si no revisás ambas familias de protocolos en tus controles.
Si no vas a usar IPv6, deshabilitalo. Superficie innecesaria.
¿Qué tiene instalado este blueprint?
Entre los servicios que se reiniciaron después del apt upgrade, apareció uno interesante:
systemctl restart apache2.serviceEl dashboard de OpenClaw corre sobre Apache2. Eso significa que Apache es otra superficie de ataque a considerar — con sus propias CVEs y configuraciones a revisar.
Un atacante que conozca vulnerabilidades de Apache podría intentar bypassear la autenticación del gateway sin necesitar el token.
Resumen de findings
| # | Finding | Severidad |
|---|---|---|
| 1 | Blueprint desplegado con kernel y librerías desactualizadas (31 security updates pendientes) | Alta |
| 2 | Combinación gateway + allow elimina aislamiento y aprobación de comandos | Crítica |
| 3 | Gateway Token visible en texto claro en el dashboard | Alta |
| 4 | IPv6 habilitado por defecto sin posibilidad de deshabilitarlo en el wizard | Media |
| 5 | Apache2 como servidor web sin hardening documentado | Media |
Recomendaciones de configuración segura
Si vas a deployar OpenClaw en un entorno real:
- Generá tu keypair localmente — nunca dejes que el provider lo genere por vos.
- Restringí el firewall a IPs conocidas desde el primer momento.
- Aplicá parches inmediatamente después del deploy — no confíes en que el blueprint está actualizado.
- Mantené
exec host policyensandbox— el aislamiento de Docker es tu primera línea de defensa. - Configurá
shell command approvalendenyo con aprobación explícita — human in the loop para acciones irreversibles. - Rotá el Gateway Token regularmente y nunca lo expongas en screenshots.
- Deshabilitá IPv6 si no lo usás.
- No expongas el dashboard a internet — si necesitás acceso remoto, usá una VPN o un túnel seguro.
¿Por qué importa esto?
Los agentes autónomos de IA están llegando a producción en empresas de toda LATAM. OpenClaw es solo el primero de muchos.
La mayoría de los equipos que los van a deployar no están pensando en la superficie de ataque, en el blast radius de una configuración incorrecta, o en cómo un prompt injection puede encadenarse con una misconfiguration para comprometer un servidor completo.
Ese gap es exactamente donde los Cloud Security Engineers tenemos que estar.
¿Qué sigue?
En la Parte 2 voy a explorar las superficies que no tocamos hoy: Channels (la integración con WhatsApp/Telegram), Agents, Cron Jobs, y cómo cada una expande la superficie de ataque del sistema.
También voy a analizar el modelo de amenazas completo usando OWASP Top 10 for Agentic Applications 2026 y el Agentic AI Security Scoping Matrix de AWS.
Tienes preguntas o encontraste algo diferente en tu deploy? Dejame un comentario — estoy armando el threat model completo para la parte 2.Sobre el autor
Gerardo Castro es AWS Security Hero y Cloud Security Engineer con foco en LATAM. Fundador y Lead Organizer del AWS Security Users Group LatAm. Cree que la mejor forma de aprender seguridad en la nube es construyendo cosas reales — no memorizando frameworks. Escribe sobre lo que construye, lo que encuentra, y lo que aprende en el camino.⭐️ GitHub: gerardokaztro
🔗 LinkedIn: gerardokaztro
Comentarios