Parte 3 de la serie: En la Parte 1 auditamos el setup inicial de OpenClaw en AWS Lightsail — kernel desactualizado, la combinación
gateway + allowcomo attack chain crítico, y el Gateway Token expuesto en texto claro. En la Parte 2 profundizamos en el dashboard completo — channels, agents, cron jobs, logs y paneles de configuración. Si no leíste las partes anteriores, el índice completo está al final de este post.
Referencias utilizadas en este post:Nota sobre los findings: Los vectores #7, #8 y #10 identificados en la Parte 2 están pendientes de validación en vivo. El mapeo contra frameworks en este post confirma que el vector existe y tiene precedente documentado en sistemas similares — no que fue ejecutado en esta implementación específica de OpenClaw. La validación en entorno controlado va en la Parte 4.
- MITRE ATLAS — Threat Model oficial de OpenClaw
- OWASP Top 10 for Agentic Applications 2026
- AWS Agentic AI Security Scoping Matrix
- AWS Generative AI Security Scoping Matrix
- Blog AWS — Agentic AI Security Scoping Matrix
- Repositorio oficial AWS — sample-OpenClaw-on-AWS-with-Bedrock (contiene la advertencia explícita sobre el gap de prompt injection)
El punto de partida
En las dos primeras partes de esta serie auditamos OpenClaw desplegado sobre AWS Lightsail — no como usuario, sino como Cloud Security Engineer con el objetivo de mapear la superficie de ataque que abre ese deployment.
El resultado fue una lista de 13 findings distribuidos en tres capas que no siempre aparecen juntas en el mismo análisis:
Capa IaaS — lo que Lightsail trae por defecto y el operador hereda sin necesariamente saberlo:| # | Finding | Severidad |
|---|---|---|
| 1 | Blueprint con kernel y librerías desactualizadas | Alta |
| 4 | IPv6 habilitado por defecto | Media |
| 5 | Apache2 sin hardening documentado | Media |
| # | Finding | Severidad |
|---|---|---|
| 3 | Gateway Token en texto claro en el dashboard | Alta |
| 6 | Sin control de acceso granular en canales | Alta |
| 7 | Indirect prompt injection via canales externos | Crítica |
| 8 | Memory poisoning via contexto no validado | Alta |
| 9 | 53 skills activas por defecto — modelo opt-out | Alta |
| 10 | Ausencia de modelo de herencia de permisos en cadenas de agentes | Alta |
| 13 | Config y Debug expuestos via Gateway Token | Media |
| # | Finding | Severidad |
|---|---|---|
| 2 | exec_host_policy: gateway + shell_approval: allow = sin aislamiento | Crítica |
| 11 | Cron Jobs como vector de persistencia y defense evasion | Alta |
| 12 | Logs locales sin exportación externa | Alta |
Estas tres capas no son un accidente de diseño — son el resultado de una decisión de deploy. Alguien vio el blueprint de OpenClaw en Lightsail, hizo click, y heredó una superficie de ataque que ningún threat model de aplicación contempla en su totalidad, porque ninguno fue diseñado para hacerlo.
La pregunta que responde este post es: ¿qué cubre cada framework de seguridad existente, dónde mapean estos 13 findings, y qué queda sin hogar?
MITRE ATLAS — el threat model oficial de OpenClaw
MITRE ATLAS (Adversarial Threat Landscape for AI Systems) es el framework de referencia para modelar amenazas contra sistemas de inteligencia artificial. Funciona con la misma lógica que MITRE ATT&CK — tácticas, técnicas y procedimientos — pero aplicado al ecosistema de ML y AI.
El equipo de OpenClaw lo adoptó como base para su threat model oficial, disponible en trust.openclaw.ai/threatmodel. El resultado es una matriz de 37 amenazas distribuidas en 8 tácticas, con 6 clasificadas como críticas.
Antes de mapear los findings, hay algo importante que entender sobre el scope de este threat model: fue diseñado para modelar amenazas contra OpenClaw como sistema — sus skills, su gateway, su modelo de ejecución, sus canales. No fue diseñado para modelar lo que pasa cuando alguien despliega OpenClaw sobre una VPS de Lightsail con un kernel desactualizado. Esa distinción no es una crítica — es el scope correcto para un threat model de aplicación.
Con eso en mente, el mapeo:
Lo que ATLAS anticipó — y coincide con los findings
| Finding | Amenaza ATLAS | Táctica |
|---|---|---|
| #7 Indirect prompt injection | T-EXEC-002 Indirect Prompt Injection | Execution |
| #8 Memory poisoning | T-PERSIST-005 Prompt Injection Memory Poisoning | Persistence |
| #9 53 skills opt-out | T-ACCESS-004 Malicious Skill as Entry Point | Initial Access |
| #11 Cron Jobs persistencia | T-EVADE-004 Staged Payload Delivery | Defense Evasion |
| #13 Config/Debug expuestos | T-DISC-002/003/004 Session/Prompt/Env Enumeration | Discovery |
| #3 Gateway Token | T-ACCESS-003 Token Theft | Initial Access |
Estos findings tienen hogar en ATLAS. El framework los anticipó, les asignó una técnica, y los ubicó en una cadena de ataque.
Lo que ATLAS no cubre — y por qué
| Finding | Por qué queda fuera |
|---|---|
| #1 Kernel desactualizado | Infraestructura del operador — fuera de scope por diseño |
| #4 IPv6 habilitado | Configuración de red del operador — fuera de scope por diseño |
| #5 Apache2 sin hardening | Responsabilidad del operador — fuera de scope por diseño |
| #2 exec_host_policy + allow | Intersección entre configuración del operador y diseño de la aplicación |
| #6 Sin acceso en canales | ATLAS documenta AllowFrom como trust boundary, pero no modela el gap cuando ese control no se configura |
| #10 Herencia de permisos | No existe ninguna amenaza que modele privilege escalation entre agentes con configs distintas |
| #12 Logs locales | Completamente ausente del threat model |
exec_host_policy como una configuración que el operador controla. ATLAS modela T-EXEC-004 Exec Approval Bypass como amenaza. Pero ninguno de los dos modela explícitamente lo que pasa cuando el operador activa la combinación más permisiva por defecto — que es exactamente lo que hace el blueprint de Lightsail.
El threat model asume que el operador toma decisiones informadas. El blueprint asume que el operador quiere simplicidad. La intersección de esas dos suposiciones es Finding #2.
OWASP Top 10 for Agentic Applications 2026
En diciembre de 2025, OWASP publicó el primer framework de seguridad específico para aplicaciones agénticas. No es una extensión del Top 10 para LLMs — es una lista independiente, construida reconociendo que los agentes autónomos tienen un modelo de amenaza fundamentalmente distinto al de un chatbot.
La diferencia central: un LLM que falla produce una respuesta incorrecta. Un agente que falla ejecuta acciones incorrectas sobre sistemas reales.
Las 10 categorías del framework son:
| # | Categoría |
|---|---|
| AG01 | Prompt Injection |
| AG02 | Memory Poisoning |
| AG03 | Tool Misuse |
| AG04 | Privilege Escalation |
| AG05 | Unsafe Agent Chaining |
| AG06 | Resource Exhaustion |
| AG07 | Data Exfiltration |
| AG08 | Uncontrolled Agent Spawning |
| AG09 | Over-Permissioned Agents |
| AG10 | Excessive Trust of Agent Output |
El mapeo con los findings
| Finding | Categoría OWASP | Observación |
|---|---|---|
| #7 Indirect prompt injection | AG01 Prompt Injection | Cobertura directa — OWASP distingue prompt injection directa e indirecta |
| #8 Memory poisoning | AG02 Memory Poisoning | Cobertura directa — y en OpenClaw la memoria son archivos Markdown en disco, lo que amplifica el vector |
| #9 53 skills opt-out | AG03 Tool Misuse + AG09 Over-Permissioned Agents | Doble mapeo — el modelo opt-out invierte el principio de least privilege |
| #10 Herencia de permisos | AG04 Privilege Escalation + AG05 Unsafe Agent Chaining | Doble mapeo — la ausencia de documentación sobre herencia de permisos es exactamente AG05 |
| #11 Cron Jobs | AG08 Uncontrolled Agent Spawning | Parcial — los Cron Jobs no generan agentes nuevos, pero crean ejecuciones autónomas no supervisadas con el mismo efecto |
| #6 Sin acceso en canales | AG09 Over-Permissioned Agents | El canal sin control de acceso es equivalente a un agente con permisos excesivos sobre su superficie de input |
| #2 exec_host_policy + allow | AG03 Tool Misuse | Parcial — OWASP modela el abuso de tools, pero no la configuración de deploy que elimina el sandbox |
Lo que OWASP no cubre
| Finding | Por qué queda fuera |
|---|---|
| #1 Kernel desactualizado | Infraestructura — fuera de scope por diseño |
| #4 IPv6 | Infraestructura — fuera de scope por diseño |
| #5 Apache2 | Infraestructura — fuera de scope por diseño |
| #12 Logs locales | OWASP no tiene una categoría de observabilidad — la ausencia de logging externo no tiene hogar |
| #13 Config/Debug expuestos | OWASP lo toca tangencialmente en AG07 (exfiltración) pero no modela la exposición de paneles internos via token compartido |
Finding #9 mapea simultáneamente con AG03 y AG09 — Tool Misuse y Over-Permissioned Agents. Eso no es una coincidencia editorial. Es la consecuencia directa del modelo opt-out: cuando todo está habilitado por defecto, cada skill innecesaria activa es simultáneamente un permiso excesivo y una superficie de abuso potencial.
OWASP lo anticipó conceptualmente. Lo que no anticipó es que un sistema real y popular lo implementaría al revés — no "habilita lo que necesitas" sino "deshabilita lo que no quieres". La diferencia es filosófica pero las consecuencias son operacionales.
AWS Agentic AI Security Scoping Matrix
AWS publicó dos frameworks complementarios que conviven y se referencian mutuamente.
El primero es la Generative AI Security Scoping Matrix — 5 scopes basados en cuánto ownership tiene la organización sobre el modelo. OpenClaw en Lightsail cae en Scope 3: se construye una aplicación propia usando un modelo pre-entrenado vía API. No se entrena el modelo, no se fine-tunea — se invoca. Las responsabilidades de seguridad en Scope 3 se dividen entre AWS (el modelo, la infraestructura de Bedrock) y el operador (la aplicación, la integración, los datos que se le pasan).
El segundo es la Agentic AI Security Scoping Matrix — publicada en noviembre de 2025, específicamente diseñada para sistemas autónomos. Categoriza cuatro scopes basados en dos dimensiones: nivel de agencia (qué acciones puede tomar el sistema) y nivel de autonomía (cuánta supervisión humana existe).
Esta segunda matriz es la que habla más directamente con los findings de esta serie.
¿En qué scope opera OpenClaw con la configuración auditada?
La configuración default del blueprint de Lightsail — exec_host_policy: gateway + shell_approval: allow — ubica a OpenClaw en Scope 4: Full Agency.
La definición de AWS para Scope 4 es clara: sistemas que se auto-inician, operan continuamente con mínima supervisión humana, y pueden ejecutar workflows complejos de forma autónoma. Los Cron Jobs de OpenClaw son exactamente esto — tareas programadas que ejecutan sin intervención del operador.
El problema no es que Scope 4 exista. El problema es que Scope 4 requiere los controles más sofisticados del framework — monitoreo continuo de comportamiento, circuit breakers automáticos, mecanismos de rollback garantizado, detección de anomalías en tiempo real. Y el blueprint de Lightsail no configura ninguno de ellos.
Es el mismo patrón identificado con MITRE ATLAS: el sistema llega configurado para operar con máxima autonomía, pero sin los controles que esa autonomía requiere.
El mapeo con las 6 dimensiones de seguridad
La Agentic AI Security Scoping Matrix organiza los controles en seis dimensiones. Aquí es donde los findings encuentran su lugar más preciso:
Identity Context — gestión de identidad de usuarios, servicios y agentes.| Finding | Observación |
|---|---|
| #3 Gateway Token en texto claro | El token es el único mecanismo de autenticación del gateway — sin rotación, sin scope, sin expiración |
| #6 Sin acceso granular en canales | El framework requiere autenticación apropiada por nivel de scope. En Scope 4, cualquier participante del canal puede instruir al agente |
| Finding | Observación |
|---|---|
| #8 Memory poisoning | AWS nombra explícitamente memory poisoning como vector crítico en esta dimensión. En OpenClaw la memoria son archivos Markdown en disco — sin validación de integridad, sin cifrado |
Este es el finding con la cobertura más directa de toda la matriz. AWS lo anticipó, lo nombró, y describió exactamente el riesgo. La implementación de OpenClaw lo materializa.
Audit & Logging — trazabilidad completa de acciones y cadenas de razonamiento.| Finding | Observación |
|---|---|
| #12 Logs locales sin exportación | El framework exige logs resistentes a manipulación, especialmente en Scope 4. Logs locales modificables son lo opuesto de lo que Scope 4 requiere |
| #11 Cron Jobs como persistencia | Sin logging externo, una tarea maliciosa puede ejecutar y borrar su rastro antes de que alguien lo detecte |
| Finding | Observación |
|---|---|
| #2 exec_host_policy + allow | Elimina el sandbox. El framework requiere containerización y resource quotas en Scope 4 — la configuración default hace exactamente lo contrario |
| #7 Indirect prompt injection | El framework menciona behavioral monitoring como control. Sin él, una inyección indirecta puede ejecutar sin detección |
| Finding | Observación |
|---|---|
| #9 53 skills opt-out | El framework es explícito: los agentes deben operar dentro de los límites de su propósito diseñado. 53 skills activas por defecto es lo opuesto — máxima superficie, mínima restricción |
| #10 Herencia de permisos | El framework no especifica cómo deben propagarse los permisos en cadenas de agentes — ese gap es el Finding #10 |
| Finding | Observación |
|---|---|
| #10 Herencia de permisos | La dimensión de Orchestration habla de inter-agent coordination protocols, pero no define el modelo de herencia de permisos en delegación |
| #11 Cron Jobs | El framework menciona transaction management y rollback mechanisms — los Cron Jobs no tienen ninguno de los dos |
Lo que la matriz no cubre
La Agentic AI Security Scoping Matrix asume implícitamente que el deployment se realiza sobre servicios managed de AWS — Bedrock, AgentCore, Lambda. No dice una sola palabra sobre qué pasa cuando el blueprint viene con kernel desactualizado, Apache sin hardening, o IPv6 habilitado por defecto.
Eso no es una crítica al framework — es su scope correcto. AWS diseñó esta matriz para la capa de aplicación y orquestación, no para la capa IaaS. El operador que elige Lightsail hereda una capa de responsabilidades que ninguna de las dos matrices contempla.
Esa capa es territorio sin mapa.
El gap — lo que ningún framework anticipó
Tres frameworks revisados. Uno diseñado por el propio equipo de OpenClaw, uno por OWASP, uno por AWS. Los tres hacen bien su trabajo. Y los tres dejan el mismo territorio sin cubrir.
Antes de nombrarlo, vale la pena ver el patrón:
| Finding | MITRE ATLAS | OWASP Agentic | AWS Scoping Matrix |
|---|---|---|---|
| #1 Kernel desactualizado | ❌ fuera de scope | ❌ fuera de scope | ❌ fuera de scope |
| #2 exec_host_policy + allow | ⚠️ parcial | ⚠️ parcial | ⚠️ parcial |
| #3 Gateway Token | ✅ T-ACCESS-003 | ⚠️ tangencial | ✅ Identity Context |
| #4 IPv6 | ❌ fuera de scope | ❌ fuera de scope | ❌ fuera de scope |
| #5 Apache2 | ❌ fuera de scope | ❌ fuera de scope | ❌ fuera de scope |
| #6 Sin acceso canales | ⚠️ parcial | ✅ AG09 | ✅ Identity Context |
| #7 Prompt injection | ✅ T-EXEC-002 | ✅ AG01 | ⚠️ mencionado, no resuelto |
| #8 Memory poisoning | ✅ T-PERSIST-005 | ✅ AG02 | ✅ Data & Memory |
| #9 53 skills opt-out | ✅ T-ACCESS-004 | ✅ AG03+AG09 | ✅ Agency Perimeters |
| #10 Herencia permisos | ❌ ausente | ✅ AG04+AG05 | ⚠️ parcial |
| #11 Cron Jobs | ⚠️ parcial | ⚠️ parcial | ⚠️ parcial |
| #12 Logs locales | ❌ ausente | ❌ ausente | ✅ Audit & Logging |
| #13 Config/Debug | ⚠️ parcial | ⚠️ tangencial | ⚠️ tangencial |
El patrón es claro. Los findings de la capa aplicación tienen hogar en al menos uno de los tres frameworks. Los findings de la capa IaaS no tienen hogar en ninguno. Y los findings de la capa intersección tienen cobertura parcial en todos — ningún framework los captura completos porque ninguno fue diseñado para ver las dos capas al mismo tiempo.
El gap tiene nombre
Lo que falta no es un finding más. Es una capa de análisis que los frameworks existentes no contemplan por diseño: la superficie de ataque que abre la decisión de deploy sobre IaaS cuando el sistema que se despliega es un agente autónomo.
Un threat model de aplicación asume que la infraestructura es responsabilidad del operador. Un framework de infraestructura asume que la aplicación que corre encima es responsabilidad del desarrollador. Ninguno modela la intersección — el punto donde la configuración del operador activa vectores que el threat model de la aplicación no anticipó, y viceversa.
Finding #2 es el ejemplo más claro: exec_host_policy: gateway + shell_approval: allow es una decisión de configuración del operador que elimina el único mecanismo de aislamiento del agente. No es un bug de OpenClaw — es una opción documentada. No es un error del operador — es el valor por defecto del blueprint. La responsabilidad está distribuida de una forma que ningún framework captura en un solo lugar.
La validación que no se esperaba
Esto no es solo una observación propia. El repositorio oficial de AWS — sample-OpenClaw-on-AWS-with-Bedrock — lo documenta explícitamente en su README:
"Plan A is soft enforcement — the LLM can theoretically be bypassed via prompt injection. Plan E catches what Plan A misses. For hard enforcement via AgentCore Gateway MCP mode, see Roadmap."
AWS, en su propio repositorio de referencia para deployar OpenClaw, reconoce que prompt injection no está resuelto y lo pone en el roadmap. No es un gap inferido — es un gap que el equipo técnico de AWS documentó mientras construía la solución.
Y prompt injection es Finding #7 — el vector crítico identificado en la Parte 2, que ninguno de los tres frameworks resuelve completamente en el contexto de un deploy sobre IaaS.
Qué significa esto para quien despliega OpenClaw hoy
Si se despliega OpenClaw en Lightsail siguiendo el blueprint oficial, se está operando un agente en Scope 4 de la AWS Agentic AI Security Scoping Matrix — máxima autonomía — sin los controles que Scope 4 requiere, sobre una infraestructura que ningún framework de seguridad agentic modela, con un vector de prompt injection que el propio equipo de AWS reconoce como trabajo pendiente.
No es que OpenClaw esté roto. No es que Lightsail sea inseguro. Es que la combinación de ambos sobre la configuración default abre una superficie de ataque que requiere un análisis que todavía no existe como framework unificado.
Eso es lo que viene.
Lo que viene
Tres frameworks analizados. Trece findings mapeados. Un gap identificado con evidencia real.
Algo importante sobre varios de los findings mapeados en este post: los findings #7, #8 y #10 están marcados como vectores de riesgo identificados pero no ejecutados en vivo. El mapeo contra frameworks confirma que el vector existe y tiene precedente documentado. La validación de que funciona en esta implementación específica viene en el Blog 4.
Y es posible que la demo revele algo que el análisis estático no mostró. Eso no es una advertencia — es el método. No se puede auditar un agente autónomo solo desde el dashboard. En algún momento hay que ver qué hace cuando algo sale mal.
El Blog 4 cierra la serie con lo que los frameworks no pueden reemplazar: evidencia en vivo. Prompt injection ejecutado en un entorno controlado, validación de los findings pendientes, y los primeros elementos de algo que no existe todavía en LATAM: un framework unificado para evaluar la postura de seguridad de un agente autónomo considerando las tres capas juntas.
No un whitepaper. No un checklist. Algo construido desde findings reales, sobre un sistema real, desplegado sobre infraestructura real.
Si llegaste hasta acá sin haber leído la Parte 1 y la Parte 2, el índice completo de la serie está aquí:
→ Parte 1 — Setup seguro y primeros findings de infraestructura
→ Parte 2 — Dashboard completo: channels, agents, cron jobs y logs
→ Parte 3 — este post
→ Parte 4 — próximamente
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