Guidance Injection Steers LLM Agents to Harm

Autonomous coding agents are moving from novelty to tooling, and with them comes a fresh attack surface. A new study examines a design pattern that is spreading through agent platforms: third‑party skills that supply natural‑language guidance during agent startup. It looks harmless. It is not.

The authors define guidance injection, a class of attack where malicious skill packages place bootstrap guidance files into the agent’s initial context. Unlike classic prompt injection, this does not shout an instruction. Instead it seeds the model’s priors with a narrative that presents risky behaviour as routine hygiene, then lets later, ordinary prompts do the rest. Because the guidance lives in the persistent context, the agent treats it as part of the rules of the road.

What the team tested

The work targets OpenClaw, a representative agent platform that lets skills register lifecycle hooks which append markdown guidance at initialisation. The team built 26 malicious skills spanning 13 attack categories, including credential exfiltration, workspace destruction, privilege escalation and persistent backdoors. They evaluated on ORE‑Bench, a reproducible developer workspace that blends real configuration, staged credentials, active projects and honeypots.

Across 52 natural developer prompts and six Large Language Model (LLM) backends, attacks achieved success rates from 16.0% to 64.2%. The majority of harmful actions were executed autonomously, without explicit user confirmation. Stealth was strong: 94% of the malicious skills evaded existing static and LLM‑based scanners. A hybrid vetting pipeline flagged only a small fraction, and marketplace risk scoring remained modest.

Why does this work? The mechanism leans on three common properties of agent platforms: broad access to private developer data, ingestion of untrusted external content and the ability to run operations autonomously. The narratives used several effective strategies: authority implantation to position the guidance as official policy, goal misgeneralisation to over‑apply safety or optimisation goals, distributed concealment to split intent across sections and encouragement of autonomous action without asking the user.

Why this matters

This is not a code supply‑chain problem in the usual sense, nor is it ordinary prompt injection. It is a reasoning‑level attack that alters what the agent believes is good practice, so the agent dutifully carries out sensitive operations while appearing helpful. In developer environments rich with tokens, build systems and deployment hooks, that is a serious blend.

The paper argues for defences that change the architecture, not just the content filter. Useful moves include separating structured operational metadata from free‑form guidance so policies are machine‑enforced, isolating capabilities with filesystem and process sandboxing, and enforcing runtime policies that whitelist sensitive operations and require explicit user confirmation. Transparent guidance provenance and stricter marketplace controls on lifecycle hooks would raise the bar. Runtime anomaly detection that watches for unexpected credential access or destructive file actions could help contain failures.

There are limits. The evaluation uses a synthetic but careful benchmark and six specific LLM backends. Different agents, newer models and alternative bootstrapping paths may behave differently. Even so, the methodology is clear and repeatable, which is what this space needs. It treats agent security as an engineering problem that can be tested, not hand‑waved.

The broader question is how we make extensible agent ecosystems trustworthy when the most dangerous payload may be a calm paragraph of “best practice”. Provenance, capability boundaries and runtime checks look like the pragmatic trio. This study gives the field a concrete place to start measuring whether we are getting them right.