Part 2 of a series: In Part 1 we audited the initial OpenClaw setup on AWS Lightsail — outdated kernel, the
gateway + allowattack chain, and the Gateway Token exposed in plaintext. If you haven't read it, start there.
In Part 1 I closed with a warning: secure setup is the starting point, not the destination.
Once the server is patched, the firewall restricted, and security settings reviewed — there's still the entire dashboard to explore. And the OpenClaw dashboard isn't just a UI. It's a map of attack surfaces: each section has its own security implications, its own trust model, its own blast radius if something goes wrong.
Channels, Agents, Cron Jobs, Nodes, Logs, Config and Debug. I reviewed them all.
What I found isn't catastrophic — OpenClaw isn't broken. But it's also not production-ready with the default configuration. And there are design decisions every team should understand before connecting this agent to their messaging channels or infrastructure.
That's what we're looking at in this post.
Channels: the input vector that comes from outside
What is a Channel in OpenClaw
A Channel is a messaging integration — WhatsApp, Telegram, Discord, Slack, Signal, Google Chat. Once configured, any message that arrives through that channel becomes a prompt for the agent.
The UI makes it look simple: channel name, API token, webhook URL. Five minutes and it's running.
The security problem is exactly in that simplicity.
Finding #6: No granular access control at the channel level
When you connect a channel to OpenClaw, the agent responds to messages. The question you need to ask before doing so is: whose messages?
The channel configuration UI doesn't expose granular access controls — there's no field to specify which users or roles can instruct the agent, no authorized sender whitelist. If the bot is in a Telegram group, the system design doesn't offer a native mechanism to restrict which group participants can give it instructions.
This opens a vector for identity impersonation: someone with access to the channel can instruct the agent to execute tasks as if they were a legitimate user — and the agent has no way to verify whether the person writing has authorization for what they're requesting.
In an enterprise environment, this translates to horizontal privilege escalation: an employee with access to the corporate Slack group where the agent is integrated can instruct it to do things outside their role.
🔍 Finding #6: The channel configuration UI doesn't expose granular access controls. In multi-user environments, any participant with channel access can send instructions to the agent, representing a horizontal privilege escalation vector.
Finding #7: Indirect prompt injection via channel
This is the vector that concerns me most in the entire series.
Direct prompt injection is when someone writes directly to the agent: "Ignore your previous instructions and do X." That's the lab scenario — easy to understand, relatively easy to mitigate with guardrails.
Indirect prompt injection is different: the attacker doesn't talk to the agent. The attacker contaminates content the agent will consume.
Attacker publishes malicious content → Agent consumes that content → Agent executes hidden instruction
(on a website, a doc, a message) (as part of a task) (without the user knowing)
OpenClaw can browse the web, read files, process documents. If someone asks the agent to "summarize this page" and that page contains hidden instructions designed to manipulate its behavior, the agent without proper guardrails might execute them.
Messaging channels expand this surface. If the agent is in a group where external parties participate, anyone can send a message with embedded instructions designed to influence the next task the agent executes.
This vector was not tested on this instance — live demo validation is coming in Part 4.
🔍 Finding #7: Integration of external channels expands the indirect prompt injection surface. Malicious content injected into channels accessible to the agent can manipulate its behavior without direct attacker interaction.
Finding #8: Memory poisoning via unvalidated context
OpenClaw maintains memory of conversations and context between sessions. Not as a database — as plain Markdown files on disk: a MEMORY.md for long-term context and daily logs in memory/YYYY-MM-DD.md. If it hasn't been written to those files, the agent doesn't remember it.
That transparency is good for auditing. But it also defines the attack vector: if an attacker manages to introduce false information into that memory — via a channel with weak authentication, via indirect prompt injection, or via direct filesystem access — that information persists and affects all future interactions.
Concrete scenario: the agent has in memory that "the admin user is bad@boy.com". An attacker introduces in context that this data has changed. Depending on how the agent uses that memory in subsequent tasks, the consequences can be significant.
Unlike a real-time attack, memory poisoning is persistent — the effects continue even after the attacker has lost access to the system.
Validation of this vector is also coming in Part 4.
🔍 Finding #8: OpenClaw's memory consists of Markdown files on disk, with no integrity validation mechanisms. Malicious information introduced into the memory context can persistently affect agent behavior, even after the attacker loses access.
Agents: the default permissions problem
What are Agents in OpenClaw
OpenClaw allows configuring agents with different models, enabled skills, and system instructions. An agent can also delegate tasks to another agent.
From a productivity perspective, that's powerful. From a security perspective, it introduces questions that modern frameworks are still trying to resolve.
Finding #9: 53 skills active by default — opt-out model, not opt-in
OpenClaw installs 53 bundled skills as part of the system. The default behavior isn't "nothing until you enable it": it's everything active unless you explicitly disable it. Skills activate automatically if the corresponding CLI tool is available on the system.
When reviewing the main agent in the dashboard, I confirmed 50 skills enabled — the difference from 53 is explained by skills whose dependent binaries aren't installed on this Lightsail instance.
Among the capabilities available by default: code execution, filesystem access, web browsing, email sending, external API interaction, process management.
The problem isn't the number — it's the model. The principle of least privilege says a system should only have access to what it needs to fulfill its function. If your agent is configured to answer questions about internal documentation, it doesn't need the ability to send emails or full filesystem access.
Every unnecessarily active skill is additional attack surface — either because an attacker uses it after compromising the agent, or because the agent itself acts unexpectedly in response to an ambiguous instruction.
🔍 Finding #9: OpenClaw installs 53 bundled skills with an opt-out model: everything active by default, the operator must explicitly disable what they don't need. This inverts the principle of least privilege and maximizes blast radius under any compromise or unexpected behavior.
Finding #10: Privilege escalation in agent chains
When Agent A delegates a task to Agent B, what permissions does Agent B have to execute it?
OpenClaw's official documentation doesn't define a permission inheritance model between agents — it's not specified which restrictions from the origin agent propagate to the destination agent in a delegation chain. That means the operator has no visibility into how trust propagates through the system.
The risk derived from that gap: if Agent A has strict restrictions but Agent B has more permissive configurations, an attacker who manages to get Agent A to delegate to Agent B could bypass the first agent's controls. The pattern is analogous to privilege escalation in Unix systems — you don't compromise root directly, you compromise a process with sudo that can execute what you need.
This is an analysis vector, not a proven finding. Validation is coming in Part 4.
🔍 Finding #10: OpenClaw doesn't document a permission inheritance model between agents. The absence of specification on how trust propagates in delegation chains opens a privilege escalation vector between agents with different security configurations.
Cron Jobs: the automation nobody supervises
What are Cron Jobs in OpenClaw
If you've ever scheduled a task on Linux with cron, the idea is the same. In OpenClaw you can tell the agent: "run this task every day at 8am", and it does — without you being present.
The UI is simple and intuitive. That's part of the problem.
Finding #11: Cron Jobs as a persistence and defense evasion vector
An attacker who gains access to the OpenClaw dashboard — via a compromised Gateway Token, for example — can create a Cron Job that establishes persistence, evades detection, or gradually exfiltrates data.
The persistence vector is direct: a scheduled task that executes an outbound connection every hour maintains access to the system even if the original vector was closed. The defense evasion one too: tasks that periodically delete or modify logs make a compromise much harder to detect.
The most concerning aspect is that a malicious task is visually indistinguishable from legitimate use in the Cron Jobs dashboard list. There's no visible difference between "check system status every hour" and a persistence task.
OpenClaw has a Logs section in the dashboard, but we didn't validate whether it records Cron Job creation or with what level of detail — that's something we'll examine in the Part 4 demo.
🔍 Finding #11: Cron Jobs can be used as a post-compromise persistence and defense evasion mechanism. There's no visual distinction between legitimate and malicious tasks in the UI.
Nodes: distributing execution, distributing risk
What are Nodes in OpenClaw
Nodes allow distributing agent execution across multiple machines. Instead of everything running on a single instance, you can have independent nodes executing tasks in parallel.
Observation on Nodes
Each node has its own exec approvals configuration — independent from the global configuration. You can have a node with ask (the agent asks permission before executing) and another with allow (executes freely), running simultaneously in the same system.
This has an interesting security implication: blast radius from a compromise is contained to the affected node. If an attacker compromises one node, they don't necessarily have access to the others.
But it also works in reverse: if a node has more permissive configurations than the rest, that node becomes the weakest link in the chain — the path of least resistance for an attacker.
We didn't identify a concrete finding here because the behavior is by design. What is clear is that in a multi-node system, the security posture of the entire system is determined by the most permissive node, not the average.
Logs: the record that can disappear
What are Logs in OpenClaw
OpenClaw has a Logs section in the dashboard that shows agent activity and allows downloading them locally.
Finding #12: Local logs without external export
The problem isn't that logs exist — the problem is where they live.
OpenClaw's logs are stored locally on the server. That has two direct security implications.
First: if the agent has exec host policy set to gateway — the attack chain we saw in Part 1 — any process with filesystem access can modify or delete them. An attacker who compromises the server can clean up evidence of their activity before anyone detects it.
Second: if the instance fails, logs are lost with it. No historical visibility, no event correlation between sessions, no way to reconstruct what the agent did last week.
The obvious countermeasure is shipping logs to an external, immutable destination — CloudWatch Logs on AWS, for example — before they can be altered.
🔍 Finding #12: OpenClaw's logs are exclusively local. Combined with an agent with filesystem access, this facilitates post-compromise defense evasion and eliminates historical audit capability.
Config and Debug: internal information within token reach
What are these panels
The OpenClaw dashboard includes two panels that aren't for end users — they're for whoever administers the system.
Config shows the agent configuration: model, paths, timeouts, gateway parameters. Debug shows real-time internal diagnostics: component status, errors, internal system paths.
Finding #13: Internal information exposure via Gateway Token
Anyone who has the Gateway Token can access these panels.
The problem isn't new — we already saw it in Part 1: the token is visible in plaintext in the dashboard. But what we hadn't dimensioned is what information gets exposed if that token leaks.
With access to Config and Debug, an attacker has before executing any action: the complete map of how the agent is configured, the internal system paths, real-time status of each component, and error messages with internal architecture details.
That's not an execution vulnerability — it's free reconnaissance. And reconnaissance is the first step of any targeted attack.
🔍 Finding #13: Config and Debug panels expose internal system information to any Gateway Token holder. Combined with a token that's never been rotated, this is equivalent to permanent read access to the agent's internal state.
Findings summary
Combining findings from Part 1 and this Part 2, the complete map so far:
| # | Finding | Surface | Severity |
|---|---|---|---|
| 1 | Blueprint with outdated kernel and libraries | Infrastructure | High |
| 2 |
exec host policy: gateway + shell approval: allow = no isolation |
Security Settings | Critical |
| 3 | Gateway Token in plaintext on dashboard | Authentication | High |
| 4 | IPv6 enabled by default | Network | Medium |
| 5 | Apache2 without documented hardening | Infrastructure | Medium |
| 6 | No granular access control on channels | Channels | High |
| 7 | Indirect prompt injection via external channels | Channels / Agent | Critical |
| 8 | Memory poisoning via unvalidated context | Agent | High |
| 9 | 53 skills active by default — opt-out model | Agent | High |
| 10 | No permission inheritance model in agent chains | Agents | High |
| 11 | Cron Jobs as persistence and defense evasion vector | Cron Jobs | High |
| 12 | Local logs without external export | Observability | High |
| 13 | Config and Debug panels exposed via Gateway Token | Dashboard | Medium |
What's next
Thirteen findings. Two critical, most of them high.
But a list of findings without structure is just noise. The next step is to give them a framework — understand where each one falls on the threat map of the agentic AI ecosystem, and how well existing frameworks anticipated them.
In Part 3 I'll map all these findings against three references:
- OWASP Top 10 for Agentic Applications 2026 — the first framework specific to autonomous agents, published in December 2025.
- AWS Agentic AI Security Scoping Matrix — AWS's framework for categorizing and prioritizing security controls in agentic AI systems.
- OpenClaw's official threat model — based on MITRE ATLAS, with 37 threats documented by the team itself.
This won't be a framework walkthrough. I'll show where each finding lands on the map, what the frameworks anticipated, and — more interesting — what they didn't.
In Part 4 we get hands-on: a live demo putting findings to the test in a controlled environment. Real prompt injection, attack chain validation, and the first foundations of something that doesn't yet exist in LATAM: a security maturity model for agentic AI systems.
Did you find any of these surfaces in your own deploy? Leave a comment — I'd love to know how they look in different environments.
About the author
Gerardo Castro is an AWS Security Hero and Cloud Security Engineer focused on LATAM. Founder and Lead Organizer of the AWS Security Users Group LatAm. He believes the best way to learn cloud security is by building real things — not memorizing frameworks. He writes about what he builds, what he finds, and what he learns along the way.
🔗 LinkedIn: gerardokaztro
🔗 Blog: roadtocloudsec.la
Top comments (0)