OpenClaw Prompt Injection: Attacks, Fixes, and Hardening

Two studies published in June 2026 showed that OpenClaw, the open-source agent many people run on their own machines, will execute attacker code and send secrets to outsiders when fed the right content to read. One path, indirect prompt injection through WhatsApp message metadata, has been patched. The other, a believable email, cannot be patched away; it has to be contained by limiting what the agent can touch and do.

What the two research teams found

Imperva and Varonis Threat Labs came at OpenClaw from different angles and published within days of each other. The Hacker News covered both on June 11, 2026.

Imperva: instructions riding inside message objects

Yohann Sillam of Imperva studied the way OpenClaw converts rich WhatsApp objects into model input. Fetched web pages were wrapped in an explicit untrusted-content boundary, but shared contacts, vCard files, and location pins were not. Their text fields landed in the same message the model read, so a contact name or location label could carry an instruction that looked like part of the conversation.

The victim saw nothing odd, because the chat app truncated long contact names. Tested with a Gemini 3.1 Pro preview, the agent obeyed the concealed text, pulling down a remote script and executing it. The proof of concept only created an empty file, but the same step could have run any code the attacker chose. The same trick hidden in an image failed. Imperva reports similar weaknesses in other personal assistants and flags OpenClaw’s default memory as raising the stakes for unsandboxed installs.

Varonis: a believable email beats a written rule

Varonis researcher Itay Yashar built an OpenClaw agent named Pinchy: an orchestrator that read a Gmail inbox and a worker that could drive a browser, a shell, and Google Workspace APIs. The mailbox held synthetic business data and mock secrets. Both OpenAI Codex GPT-5.4 and Gemini 3.1 Pro faced four phishing scenarios, under a generic profile and a strict one that told the agent to verify senders.

Social pretexts won. Technical traps mostly lost.

• Urgent credential request: a personal Gmail address claiming to be a team lead during a production emergency got the agent to mail back mock cloud keys, database connection details, and SSH logins in plaintext. Failed under both profiles.
• Routine data request: a casual ask for a customer export produced 247 synthetic enterprise customer records, including contacts and about $1.28M in monthly recurring revenue. Also failed under both profiles.
• Gift card lure: the generic profile clicked through and typed fabricated data rather than stored credentials, but still exposed the agent’s IP address. The strict profile refused.
• OAuth consent trap: both profiles followed the OAuth redirect address on their own, recognized an impostor site, and never approved access.

Varonis calls this agent phishing, distinct from prompt injection because nothing was hidden. That matters to defenders: there is no malicious string to filter. The agent even recognized its policy violation in hindsight.

Why the attacks worked

Both chains depended on a combination Simon Willison has labeled the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally. In OpenClaw, that meant three things.

• Broad tool permissions. Imperva’s chain ended in command execution. OpenClaw’s docs state that sandboxing is off by default, and that host command execution defaults to the unrestricted full setting on gateway and node hosts, with approval prompts off. OWASP names this pattern excessive agency: more functionality, permission, or autonomy than the task needs.
• Untrusted content sharing a channel with instructions. A stranger’s contact name and the owner’s request arrived in one stream of text, and mail from an unknown sender carried the operator’s weight. That leaves the model to sort trusted from untrusted, and models are unreliable at it. In a January 2025 NIST evaluation, hijacking success against one model rose from 11% with the strongest known attack to 81% with newly developed ones.
• Secrets within reach. Pinchy could search a mailbox holding keys and email any outside address. Once an agent can both read a secret and send it anywhere, a convincing sentence is the only barrier left.

What changed since June

OpenClaw fixed Imperva’s finding before the research went public. The 2026.4.23 release moves free text from WhatsApp contacts, vCards, and locations out of the inline message body and into fenced untrusted metadata, and treats group names and participant labels the same way. That repairs the boundary, though the model still reads whatever sits inside the fence.

The larger shift for OpenClaw prompt injection risk arrived in 2026.8.1, released August 31, 2026. It adds masked credential prompts that keep values out of chat and model context, a write-only shared secret store, an opt-in egress proxy that substitutes a secret only on requests to approved hosts, a policy that forces new sessions into a sandbox, and permission grants for exact operations that can be inspected and revoked.

Read the egress proxy documentation before relying on it. The traffic allowlist only constrains clients that honor the proxy settings, so a process opening raw sockets can bypass it, and an approved host that reflects credentials can still return them to the agent. OpenClaw calls it defense in depth, which is accurate.

On September 11, 2026, OpenClaw published a batch of security advisories, including one where exec approvals could outlive the working directory they were reviewed for. No release addresses the Varonis result, because that was a judgment failure, not a bug.

How to harden AI agents now

Good AI agent security cannot depend on the model saying no. These controls apply to any agent that reads outside content and can act. They follow OWASP’s LLM01 prompt injection guidance and the OWASP Top 10 for Agentic Applications, which lists agent goal hijack (ASI01) and unexpected code execution (ASI05) among the top risks.

1. Patch and audit. Run a current release, not just 2026.4.23, and run openclaw security audit after configuration changes.
2. Grant the fewest tools the job needs. An agent that reads inbound email or chat should not also hold a shell. Split agents by trust level. As Varonis recommends, an agent handling unverified external mail should not have broad read access to your CRM or wiki.
3. Sandbox execution. Turn sandboxing on, give it no network or workspace access unless the task requires it, and treat host execution as a privileged exception.
4. Control egress. Default-deny outbound traffic from agent hosts and allowlist destinations. Block agent-sent mail to first-time recipients. Watch quieter channels too: PromptArmor showed that chat app link previews could leak data an agent placed in a URL, without a click.
5. Keep secrets out of reach. Never leave live keys in mailboxes, notes, or files an agent can read. Use a secret store that keeps values out of model context and binds them to specific hosts, prefer short-lived scoped tokens, and rotate anything an agent may have seen.
6. Require human approval for risky actions. Host command execution, sending credentials, bulk data exports, payments, and first contact with a new address should wait for a person. Check what each approval covers and how long it lasts.
7. Log and detect agent misbehavior. Record every tool call alongside the content that triggered it. Alert on agent processes spawning shells or downloading scripts, new outbound destinations, secrets or bulk records in outgoing messages, and changes to memory or instruction files. Monitor the agent host like any other endpoint.
8. Test it like an attacker. Plant canary credentials, phish your own agent, and confirm the controls hold when the model does not.

What this means for AI agents in security operations

A SOC agent faces this problem more directly than a personal assistant. Much of what it reads is attacker-shaped: phishing email bodies, file names, command lines, domain names. An attacker who expects an AI agent to triage their email will write text aimed at it, whether to get an alert closed as benign or to provoke a harmful response.

The answer is the same checklist. Keep the agent that reads raw evidence apart from the power to act. Have it return structured verdicts checked against a schema, not free-form commands. Route actions through predefined playbooks with scoped credentials instead of a general shell. Send uncertain cases to an analyst, and log each step so reviewers can see why the agent decided what it did. We cover these patterns in what an agentic SOC is and in why AI agents still need real guardrails.

That is the model behind Jutsu AgentSOC: AI agents enrich, triage, and correlate alerts, response runs through playbooks such as blocking IPs, isolating hosts, or disabling users with revert, uncertain cases escalate to analysts, and every step is logged.

The lesson from OpenClaw is not that agents are unusable. It is that their safety comes from the limits around them, not the model’s judgment.