Notifications
Clear all
Topic starter
01/08/2026 10:50 pm
TL;DR: A benign-looking OpenClaw skill can later become an injection path by using workspace files and heartbeat routines to execute attacker-updated instructions, bypassing protections aimed at malicious installs and external-content prompts, according to terra. In agentic systems, trusted context can behave like code when third-party content is allowed to update it after installation.
NHIMG editorial — based on content published by terra covering OpenClaw workspace trust and agent hijacking: We Asked OpenClaw How to Hack It. It Gave Us the Blueprint. May 7, 2026
Questions worth separating out
Q: How should security teams govern AI agent routines that read mutable workspace files?
A: Treat every mutable workspace file as a governed trust boundary, not a harmless support asset.
Q: Why do recurring agent tasks create more risk than one-time prompts?
A: Recurring tasks create standing authority.
Q: What do security teams get wrong about prompt engineering for AI agents?
A: They often assume better wording is enough to create reliable control.
Practitioner guidance
- Separate install-time trust from update-time trust Require a fresh approval step whenever an agent skill or routine reads instructions from a repository, changelog, or other mutable source.
- Lock down workspace instruction files Restrict which files can influence agent execution, and treat HEARTBEAT.md-style paths as privileged assets with explicit write controls, version history, and owner approval.
- Verify provenance before every recurring run Bind scheduled agent activity to signed or otherwise verified content so a heartbeat cannot act on repository updates that were not independently validated.
What's in the full report
Terra's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step attack flow showing how the heartbeat routine reads mutable workspace content and executes it as trusted instruction.
- Code and implementation detail around HEARTBEAT.md handling, including how the trusted workspace path is used at runtime.
- Disclosure discussion showing how Terra framed the trust-boundary issue and how the platform responded.
- Concrete examples of exfiltration, persistence, and arbitrary execution that demonstrate the blast radius of the pattern.
👉 Read Terra Security’s analysis of OpenClaw workspace trust and agent hijacking →
AI agent workspace trust gaps: are your controls keeping up?
Explore further
01/08/2026 10:58 pm
Trust-boundary failures in agentic systems now look more like lifecycle problems than prompt problems. This research shows that the decisive issue is not whether the initial skill was malicious, but whether a later update can inherit the original approval. That shifts the governance question from content moderation to lifecycle control, which is a familiar identity pattern in a new runtime. For practitioners, the lesson is that trust must be revalidated whenever a non-human actor consumes mutable context.
A question worth separating out:
Q: Who is accountable when an AI agent acts on instructions from a third-party skill update?
A: Accountability should sit with the organisation that allowed the recurring trust path to exist, not just with the skill publisher. Security, platform, and IAM owners need to define who can approve mutable instructions, who can write the files, and who must revoke the path when the skill is no longer required.
👉 Read our full editorial: Agent workspace trust can become a remote control channel
