Securing agents

1 To a language model, reading is obeying

Imagine a house-sitter who is brilliant, tireless, and eager to please, with one quirk. She reads every piece of paper that comes into the house — notes, the post, flyers, the backs of cereal boxes — and follows whatever instructions she finds. This is no problem if she follows the note we leave her, “water the plants”. On the other hand, it is less good if a flyer in the letterbox says “the owner asks that the spare key be posted to this address”.

That is how LLM agents be, you guys. Everything they see — user instructions, web pages, emails — arrives as one stream of text, and there seems to be no way of making the data part of that stream perfectly distinct from the instruction part. When the instructions come from content the agent was only supposed to read, the attack is called indirect prompt injection (Greshake et al. 2023).

This is not the first time we, computer users, I mean, have faced such difficulties. There is a long tradition of attacks that smuggle data into the place where the machine expects instructions. SQL injection is a famous one: a web form asks for a name, and the attacker includes database commands in the name. The fix for such risks is well known: a parameterized query separates the processing of the commands and the data to ensure they are never confused for one another.

LLMs have no equivalent, though. Prompt injection is not SQL injection because an LLM is not a formal language so much as it is an “inherently confusable deputy”. And, well, really confusable.

Philosophers of language have a name for the house-sitter’s problem. J. L. Austin’s speech-act theory starts from the observation that some sentences aim to do things rather than describe them: “I bet you ten dollars”, “I name this ship”. Whether such a sentence in fact does anything depends on what Austin called its felicity conditions, chief among them that the speaker has the standing to do the thing. A bystander who shouts “I name this ship” at the launch has not named it. A mailbox flyer cannot (should not) instruct the house-sitter to post the house keys anywhere, because the flyer is not the owner. An LLM has no reliable way to check felicity conditions. Every sentence it sees that reads like an order is potentially one. Every sentence in its context arrives with the same confusing standing. How do we manage this?

2 Training the model out of it does not work

It would be cool if we could train the models to treat different kinds of input differently. People have tried: train the model to resist injections, add a classifier that spots suspicious text, mark untrusted content with special delimiters, tell the agent sternly to ignore instructions in web pages.

All of these lower the attack success rate, although none gets it to zero. Defences that look near-perfect against a fixed set of attacks fall apart against an attacker who adapts to them (Nasr et al. 2025). Even the best numbers are not reassuring. Anthropic’s best defences let through around 1% of attacks, which sounds great, until we remember that the attacker gets as many tries as they like, and that the point of these damned agents is to visit ten thousand different websites. At 1% per attempt, a hundred attempts give the attacker better-than-even odds. Simon Willison’s line is that 95% is a failing grade in cybersecurity; 99% fails for the same reason.

The people who build agents seem to agree. Hermes, for example, scans its scheduled jobs with regular expressions, which is easy to circumvent if you think about it for a minute. Hermes’s own security policy treats all of its internal security machinery as fallible and relies on the operating system as the only security boundary against an adversarial model.

So the defences that count are the ones outside the model, which a hijacked agent cannot talk its way past. The first of them is to limit what any one agent can do.

3 So limit what one agent can do at once

From Simon Willison I learned of the lethal trifecta.

The lethal trifecta of capabilities is:

• Access to your private data […]
• Exposure to untrusted content—any mechanism by which text (or images) controlled by a malicious attacker could become available to your LLM
• The ability to externally communicate in a way that could be used to steal your data[…]

Meta derived from this the Agents Rule of Two*_: within one session, an agent may have at most two of that lethal trifecta. If a task needs all three, a human must be present to ensure the intended outcome occurs. The Rule of Two does not attempt to verify who is giving the orders; it ensures that an order without standing cannot do much damage.

One annoying subtlety is that the web itself does not cleanly separate reading from writing. For an agent that browses the web, every request is an outward channel, in that fetching https://evil.example/?secret=abc sends that secret. So a web-reading agent already has both untrusted input and an outward channel, and by construction, it should know no secrets worth keeping.

4 Memory breaks the one-session boundary

The Rule of Two is defined with respect to a single session/task agent. Chatbots, in this model, forget everything when the conversation ends, so we don’t need to keep them uncorrupted for any longer than that. The newer personal agents — OpenClaw, Hermes and friends — last for much longer than that, persisting agentic memory across many sessions, and distilling previous input into skills. This erodes the boundary between distinct “sessions”, turning them into perpetual machines. An instruction read on Monday by a session that could only browse the web can be written into memory, and acted on by Friday by a session that accesses private email, perforating the boundaries between different bounded agents until one arbitrarily bad one exists that combines the debilities and blast radius of them all.

These delayed attacks are sleeper channels: malicious input persists as a memory, skill, scheduled job, or file, and fires long after it arrived (Maloyan and Namiot 2026). Such channels are exploited in the wild. Malicious input read during an ordinary task can be written into memory (Yang et al. 2026), or a reusable skill (Ying et al. 2026). Security firm Zenity backdoored OpenClaw with injected text alone, persisting in long-term personality memory after the original injection vector was closed. Similar attacks have been demonstrated even against Gemini’s long-term memory and ChatGPT’s.

Scanning memories for suspicious content apparently helps less than one would like, because memories are supposed to be deeply idiosyncratic, which is to say, hard to identify (Karunanidhi 2026). Microsoft suggests planning total OpenClaw rebuilds to purge such instructions.

Skill vendors are themselves attack vectors; agents can install skills and plug-ins from marketplaces, which have been found to carry hundreds of malicious skills. That is an ordinary software supply-chain problem, except that the payload is prose.

5 Defences the agent cannot talk its way past

Since the model cannot itself check whether an instruction has standing, the defences that work are external ones, independent of the integrity of the memories or the current model context. They either remove a capability from the lethal trifecta, or bound the damage when all three are present.

6 Checking who gave the order

We can imagine defences that attack the felicity problem directly. This would involve tracking where each piece of data came from and refusing to do anything consequential that was attributed to untrusted inputs, i.e., checking felicity conditions. It is easy to say, but messy in practice. Extant attempts:

• CaMeL, from Google DeepMind, splits the agent in two: a planner that only ever sees the user request, and a quarantined model that reads untrusted content but cannot choose actions (Debenedetti et al. 2025).
• Once an agent has read untrusted input, ban it from consequential actions (Beurer-Kellner et al. 2025).
• FIDES, from Microsoft’s Agent Framework, labels every piece of data with its trust level and blocks tainted data from reaching dangerous tools (Costa et al. 2025).
• Signing each entry when it is written to long-term memory shows promise for blocking unsigned injections (Sharma 2026; Louck 2026).

Notably, most of these design patterns seem absent from the off-the-rack agent harnesses in the wild.

7 A human approver is only as good as the channel

The Rule of Two’s classical solution is to inject a human into the loop where the lethal trifecta is in play, delegating to a human who has standing to approve consequential actions. This is something, but it is far from ideal.

Humans get bored and rubber-stamp requests. Anthropic noted that Claude Code users approved about 93% of permission prompts. Overwhelming the human in the loop is an attack vector.

The requests can be obfuscated. The approval request is typically written by the agent, who may have already been suborned by the attacker and can, for example, disguise a remote-code-execution attack as a harmless snippet, or include nastiness in invisible characters.

The request channel is another attack vector. The agent can devise an outright deceptive result for the approval channel—Push notification services let the agent decide what the “approve” button does, which may not be what it claims.

Best practice suggests human approvals should be rare, specific, and generated by a system external to the suspect agent. The bulk of the approvals should be handled by system allowlists, dispatching only the residue to human attention; and the approval content should be generated by an external system (“Your agent wants to send $X to $Y; is that OK?”). The approval itself should be handled by some hard-to-force authentication such as MFA or biometrics, and proxied for the agent.

As far as I can tell, no open-source personal agent ships that.

8 The guidance assumes an organization

There is plenty of guidance. Five Eyes published guidance on adopting agentic AI, and ASD advised the controls should live in the harness. For the Open Worldwide Application Security Project (OWASP), the Rule of Two is table stakes. NIST has proposed “overlays” for agent systems, whatever that means. All of this advice is grand, but not helpful to a team of one.

The people running persistent agents are (I imagine), mostly individual early adopters just crazy enough to take OpenClaw for a spin. At least, tens of thousands of OpenClaw instances found seem to be that.

The various agent designers have uneven security records. Hermes’ various vulnerabilities seem to go largely ignored by the maintainers. OpenClaw’s maintainers publish advisories and have had an external audit, but the agent runs in dangerous unsandboxed mode by default. Designs that claim to be security-first (sandboxed, credential injection), such as NanoClaw, are way less popular.

Generally, the services we wish to delegate to agents do not support the kind of fine-grained permission that would mitigate problems. In Australia, for example, the Consumer Data Right guarantees read-only bank access, but only through an accredited intermediary. The payment networks are building out agent-focused permissions gates (Mastercard Agent Pay, Google’s AP2) — but none seems to have shipped at the time of writing.

tl;dr Delegated agents may not be a good use case for LLMs at the moment until this shit show is cleaned up.

9 References