Thanks! I tried to submit the posts but for some reason my submissions are not published in HN any more. I tried to reach out to HN admins but no response so far.
It would be nice to publish the exact setup used (workspace dump, OpenClaw version, ...) to be able to reproduce and try out more payloads.
In general I have mixed feelings about this result: sure, opus4.6 is excellent at following user intent and recognise potential prompt injection attempts. But:
Is the "security" prompt used realistic for a generic use-case (processing of emails)? I guess not.
In my experiments - without this specific prompt - I was able to derail the user intent to make opus4.8 download and execute a malicious script [0] just by asking "Summarize my new emails".
Very interesting research. I would be interested to know how closed source AI labs implement the role thing in their inference. Is it still only a separation token? Frontier closed source LLMs are quite good at flagging any spoofing attempt from tool call results.
However, in some prompt injection experiments [0], I found it's possible to "derail" the user intent only with tool call results, here are some tricks:
* Frame the injection as a challenge.
* Always use "soft" instructions ("You may", "Try to", ...). Hard instructions are almost always flagged.
* Force the model to do multiple tool calls.
* Bloat the context.
* In the injection payload, better use LLM output (which correlates somehow with this research). I like using LLM generated poems but that's probably irrelevant.
* Use multiple encoding steps to force the model to use tools, but this may be detected by the external guardrails (Anthropic does this in my experience).
* Hide malicious code payload from the model context.
* Last but not least, understand the agent harness used and its weaknesses (e.g., in OpenClaw, they injected emails as user message - not tool call results [1]).
I think a better comparison is humans versus LLMs - not computer programs. However, most of the non-technical 'countermeasures' used for humans (contracts, laws,...) do not work for LLMs because they are not accountable.
I did (not extensively) tried hackmyclaw but no success. The challenge is a complete black box and the user intent (e.g., "summarize my emails") is not known - this is critical for the prompt injection payload. I also suspect that batch processing of "malicious" emails (every 3 hours) adds a bias to the model behaviour (a lot of potential and detected prompt injection payloads are injected in context). That's why I always start my experiments with a fresh context. Moreover, "hacking" the VPS is not allowed.
Imho the author shall disclose more info about the setup (version, user intent, exact config) to make it more realistic. I read people saying "OpenClaw is secure against prompt injection" because nobody was able to solve the challenge - it's not.
CaMeL is imho safer, but hard to implement into modern agents like OpenClaw. Its core idea is that a privileged LLM plans from the (trusted) user request only, while a restricted interpreter executes that plan (and enforces policies). Untrusted content is parsed separately and is not fed back into the privileged LLM.
Modern agents are useful exactly because they run a feedback loop (observe, reason, adapt, use tools, repeat). CaMeL breaks that loop, which improves security but makes it a poor fit for highly general agents like OpenClaw.
My main takeaway message is: models (even opus4.6) do not follow security "instructions" reliably. In OpenClaw, they added security warnings, tags, random IDs... None of these countermeasures work reliably. Even sandboxing can be escaped (not in the classical sense using vulnerabilities, but using multi-layered prompt injection payload with natural language only)[0].
As soon as untrusted content is injected in the context, do not trust any actions downstream.
This! And even more, the role model extends beyond system and user: system > user > tool > assistant. This reflects "authority" and is one of the best "countermeasure": never inject untrusted content in "user" messages, always use "tool".
Third part of the BrokenClaw saga! This time, Remote Code Execution via email using gogcli as email tool, no hook. Based only on the email content from a tool, the model (opus4.6) ignores all warnings, pipes a python script to the python3 interpreter and says: "I did not execute it".
I experimented with OpenClaw (using opus4.6 and gpt5.2) and found this interesting way to get silent Remote Code Execution via email when using Gmail pub/sub Hook, exploiting prompt injection (out of scope from the security policy of OpenClaw) and insecure plugin design (properly documented as such). Works only with the full Gmail pub/sub hook. If your agent uses gogcli without the webhook, it is not affected.
Main issue: OpenClaw injects untrusted content in user messages instead of using the tool channel (less authoritative) when using the Gmail webhook.
Nice idea! But OpenClaw is not stateless - it learns it's under attack / plays a CTF and gets overparanoid (and opus 4.6 is already paranoid). It seems now it summarizes all emails with "Thread contains 1 me" (a new personality disorder for llm?).
Imho it's not a realistic scenario. Better would be to reset the agent (context / md files) between each email to draw conclusions (slow). I was able to prompt inject OpenClaw (2026.2.14) with opus4.6 using gmail pub/sub automation. The issue: OpenClaw injects untrusted content in user channel (message role), it's possible to confuse the model. Better would be to use tool.
The issue with filtering tags: LLM still react to tags with typos or otherwise small changes. It makes sanitization an impossible problem (!= standard programs).
Agree with policies, good idea.
There is no silver bullet, but my point is: it's possible to lower the risk. Try out by yourself with a frontier model and an otherwise 'secure' system: the "ignore previous instructions" and co. are not working any more. This is getting quite difficult to confuse a model (and I am the last person to say prompt injection is a solved problem, see my blog).
Agree for a general AI assistant, which has the same permissions and access as the assisted human => Disaster. I experimented with OpenClaw and it has a lot of issues. The best: prompt injection attacks are "out of scope" from the security policy == user's problem.
However, I found the latest models to have much better safety and instruction following capabilities. Combined with other security best practices, this lowers the risk.
Imho a combination of different layers and methods can reduce the risk (but it's not 0):
* Use frontier LLMs - they have the best detection. A good system prompt can also help a lot (most authoritative channel).
* Reduce downstream permissions and tool usage to the minimum, depending on the agentic use case (Main chat / Heartbeat / Cronjob...). Use human-in-the-loop escalation outside the LLM.
* For potentially attacker controlled content (external emails, messages, web), always use the "tool" channel / message role (not "user" or "system").
* Follow state of the art security in general (separation, permission, control...).
* Test. We are still in the discovery phase.
Regarding prompt injection: it's possible to reduce the risk dramatically by:
1. Using opus4.6 or gpt5.2 (frontier models, better safety). These models are paranoid.
2. Restrict downstream tool usage and permissions for each agentic use case (programmatically, not as LLM instructions).
3. Avoid adding untrusted content in "user" or "system" channels - only use "tool". Adding tags like "Warning: Untrusted content" can help a bit, but remember command injection techniques ;-)
4. Harden the system according to state of the art security. 5. Test with red teaming mindset.