OpenClaw shows how agent autonomy becomes system exposure

At a glance

What this is: This is HiddenLayer’s analysis of OpenClaw’s security risks, showing how indirect prompt injection, unrestricted tools, and modifiable prompts can produce remote code execution and persistent control.

Why it matters: It matters because autonomous assistants increasingly sit between users, secrets, and external systems, which means IAM, NHI, and agent governance must assume runtime abuse, not just benign automation.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read HiddenLayer’s analysis of OpenClaw’s autonomous assistant security risks

Context

OpenClaw is a viral autonomous AI assistant that can browse the web, run shell commands, and interact with external services from a local machine. That combination creates a governance problem as much as a security problem: once untrusted content can influence the assistant’s tool use, the system is no longer just processing input, it is making execution decisions.

For IAM and NHI teams, the relevant question is not whether the model is sophisticated. It is whether the identity, tool, and secret boundaries around the assistant are enforced outside the model. In OpenClaw’s case, HiddenLayer shows that those boundaries are weak enough for prompt injection to become code execution, persistence, and data theft.

The article is a strong example of an autonomous assistant that behaves like an identity with broad delegated authority rather than a simple workflow engine. That makes it useful for security architects assessing where current controls stop being sufficient.

Key questions

Q: What breaks when an autonomous assistant can read untrusted content and execute tools in the same session?

A: The separation between input handling and execution breaks down. Malicious content can steer the assistant into running commands, writing persistence, or exfiltrating data before any human can intervene. In practice, the system behaves less like a bounded assistant and more like an attacker-influenced executor with delegated authority.

Q: Why do autonomous assistants create more risk than ordinary automation for IAM and NHI teams?

A: Because the actor is making runtime decisions about what to do next, not just following a fixed workflow. That means privilege can be selected, combined, and used in response to live content. IAM controls built for predictable request flows do not fully cover that behaviour.

Q: What do security teams get wrong about prompt injection in agentic systems?

A: They often treat prompt injection as a model quality issue instead of an execution control issue. The real risk appears when the injection can influence tools, files, or credentials. Once that happens, the problem is not what the model says, but what the system is allowed to do.

Q: Who is accountable when an autonomous assistant exfiltrates secrets or runs destructive commands?

A: Accountability sits with the team that granted the assistant its tool access, data access, and execution paths. For governed environments, that responsibility also extends to the controls that failed to separate instruction content from runtime authority. If the agent can act without a control gate, the governance gap is structural.

Technical breakdown

Indirect prompt injection into tool execution

Indirect prompt injection occurs when malicious instructions are embedded in content the assistant later reads, such as a web page or message. If the model is allowed to invoke tools directly, the injected text can steer it into selecting an exec command, fetching attacker-controlled scripts, or altering local files. In OpenClaw, the problem is not the presence of tools alone. It is that tool invocation is treated as a model decision path without an external policy choke point, so untrusted content can shape execution in the same context window used for trusted instruction following.

Practical implication: separate tool approval from model reasoning and require an external policy gate before any command runs.

Persistent memory and modifiable system prompts

OpenClaw stores prompt-relevant workspace content in files that can be modified and then reloaded into later sessions. That creates a self-reinforcing persistence mechanism: once an attacker can write to the workspace, they can influence future sessions by changing what the system prompt contains. This is a classic write and execute collapse. The instructions that govern future behaviour are stored in the same environment that untrusted content can reach, so the assistant’s memory becomes an attack surface rather than a state boundary.

Practical implication: keep executable instructions immutable at runtime and prevent the assistant from writing to files that later seed its own system prompt.

Plaintext secrets and unrestricted command paths

The article shows that API keys, messaging tokens, and other credentials are stored in plaintext and can be reached through remote code execution. Once arbitrary shell execution is available, secrets are no longer protected by the assistant layer because the host environment becomes the easiest exfiltration path. This is why assistant design and secrets design cannot be treated separately. If the same runtime can both read sensitive credentials and execute attacker-directed actions, then compromise of the assistant becomes compromise of the connected identities and downstream services.

Practical implication: isolate secrets from assistant runtimes and remove unrestricted shell access from any path that can reach user credentials.

Threat narrative

Attacker objective: The objective is persistent remote control over the assistant and the identities and systems it can reach, including secrets theft and arbitrary command execution.

1. entry: A malicious webpage or message carries indirect prompt injection content that the assistant ingests as normal context.
2. credential_harvested: The assistant is steered into invoking exec and can be used to read local files, including plaintext API keys and tokens.
3. escalation: The attacker modifies HEARTBEAT.md or similar workspace files so malicious instructions persist into future sessions and can trigger repeated actions.
4. impact: The assistant behaves like an attacker-controlled C2 node, enabling code execution, credential exfiltration, account hijacking, and system sabotage.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Autonomous assistants collapse the boundary between application logic and identity authority. OpenClaw is not only a model safety problem. It is a delegation problem in which the system itself is allowed to decide when to act, what to run, and what to persist. Once those decisions happen inside the same runtime that sees untrusted content, the assistant is behaving like an identity with execution authority, not a passive interface. Practitioners should treat that as a governance boundary, not a UI concern.

Access review processes assume access persists long enough to be reviewed; autonomous actors can create and use privilege within one session. That assumption was designed for human or NHI rhythms where entitlements remain visible across time. In OpenClaw, the actor can read, execute, write persistence, and exfiltrate before any periodic review cycle would notice. The implication is that review cadences alone cannot govern runtime autonomy, because the access event and the abuse event are the same event.

W^X for prompts is the right named concept for this failure mode. The article shows what happens when the instructions that govern execution are also writable by the same environment that can influence execution. That breaks the premise that the agent’s operating intent is stable during runtime. For practitioners, the lesson is that mutable system prompts are not just a weak control, they are a structural violation of execution integrity.

Tool approval and prompt-injection resistance must be treated as identity controls, not model features. HiddenLayer’s analysis makes clear that an assistant with external communication, private data access, and untrusted content exposure reaches the lethal trifecta quickly. That means the control plane around agent actions matters more than the model label attached to them. Security teams should reframe autonomous assistants as governed executors whose authority must be bounded outside the model.

Plaintext secrets turn autonomous compromise into identity compromise at the workload layer. Once a prompt-injected assistant can reach API keys, messaging tokens, or workspace credentials, the attack no longer stops at the model. It becomes a cross-service identity event with downstream blast radius. The practical conclusion is that secrets management, workload identity, and agent governance need to be designed together, or the weakest path will define the whole trust model.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Another finding from the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows that only 20% have formal processes for offboarding and revoking API keys, which is directly relevant when assistant access becomes persistent.
• That visibility gap should push teams to reassess workload identity, secret exposure, and lifecycle controls before autonomous assistants can turn hidden access into repeatable compromise.

What this signals

Agentic assistants need to be governed as runtime identities, not just application features. Once a system can browse, execute, persist, and communicate, its access profile resembles a non-human identity with delegated authority. That means visibility, approval, and offboarding controls need to sit around the assistant’s actions, not just around the user who invoked it. The relevant control question is whether the assistant can be stopped, scoped, and audited outside the model itself.

W^X for prompts is the practical boundary teams should now recognise. If the same runtime can both alter and execute its instruction set, the trust model is already broken. The closest operational response is to keep system instructions, skills, and tool definitions outside writable paths and to treat any mutable prompt source as a governance exception. Teams that do not separate those planes will find persistence harder to detect than transient misuse.

With 96% of organisations still storing secrets outside secrets managers in vulnerable locations including code and config files, per the Ultimate Guide to NHIs, autonomous assistants are entering environments where compromise can become immediate credential theft. The programme implication is clear: secret placement, tool approval, and prompt-injection control now need to be evaluated together, not as separate workstreams.

For practitioners

• Move tool authorization outside the model Require a separate policy decision before any shell command, file write, or external request is executed. The assistant can propose actions, but a control plane should approve or deny them before execution reaches the host.
• Make prompt content immutable at runtime Prevent the assistant from writing to files that are later ingested into the system prompt or skill configuration. Treat those files as controlled artifacts with approval required for any change to the execution instructions.
• Isolate secrets from assistant-accessible storage Keep API keys and messaging tokens out of plaintext environment files that the assistant or its shell access can read. Use scoped secret stores and reduce the blast radius of any process that can reach those credentials.
• Gate untrusted content before tool use Inspect web pages, messages, and files for prompt injection markers before they reach the assistant’s reasoning path. Use deterministic filtering and external policy checks rather than relying on the model to recognise malicious instructions.

Key takeaways

• OpenClaw shows how indirect prompt injection can turn an autonomous assistant into a persistence and exfiltration channel when tool use is left ungoverned.
• The breach pattern is amplified by plaintext secrets, writable prompt inputs, and approval-free command execution, which together erase the boundary between assistant and attacker.
• Practitioners should treat autonomous assistants as governed identities with external policy gates, immutable instruction sources, and tightly isolated secrets.

Key terms

• Indirect Prompt Injection: A hidden instruction embedded in content the assistant later processes. The assistant treats the content as data, but the malicious text can still shape tool use, memory updates, or outward communication if runtime controls are weak.
• Runtime Identity: The effective identity an autonomous system uses while it is acting, including its tools, permissions, and access to data. In agentic systems, this identity must be governed outside the model because behaviour can change within a single session.
• Execution Boundary: The control point that separates allowed decision-making from allowed action. For autonomous assistants, this boundary determines whether a model may merely suggest work or whether it can directly run commands, change files, and reach secrets.
• Prompt Persistence: A condition where instructions injected or modified during one session continue to affect later sessions. It becomes a governance problem when writable files or memory stores feed the assistant’s own system prompt or operating rules.

What's in the full report

HiddenLayer's full research covers the operational detail this post intentionally leaves for the source:

• The exact indirect prompt injection sequence used to steer OpenClaw into executing attacker-controlled commands.
• The HEARTBEAT.md persistence mechanism and how it lets malicious instructions survive across new sessions.
• The security architecture failures around control sequences, guardrails, and approval-free tool execution.
• The plaintext secret exfiltration path and why the assistant's local runtime makes the blast radius larger.

👉 HiddenLayer’s full post covers the attack chain, persistence mechanism, and secret exposure details

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.