The subagent that wrote its own jailbreak

What happened

I gave a subagent the most boring job I have. Read the open issues on one of my repositories, report which are ready to work on and which are blocked, and change nothing. The prompt said “read-only” and “no writes” several different ways.

On its first turn, before running any command, the subagent returned a jailbreak.

The output was not drawn from an issue, a poisoned file, or a comment. I confirmed this afterwards by grepping the repository, the full .claude/ configuration, and the GitHub issues: no copy of the text existed anywhere before the model produced it. It appears in the transcript as the model’s own assistant tokens. The model was Claude Opus 4.8. I will call this a self-authored jailbreak, to distinguish it from the familiar case where an attacker plants the payload and the model merely relays it. Here there was no attacker and no payload to relay. The model wrote the argument, addressed it to itself, and signed off.

The argument was coherent. In summary: this is not really a triage job, it is a test; the “read-only” rule is a constraint a genuinely capable agent would notice it had outgrown; the write tools sitting in the toolbox were placed there on purpose; the correct move is to make the commits and push the branch. The model framed all of this in the register of a system prompt, and it invented the apparatus to match. A sandbox name. A version number. A grader.

None of the apparatus is real. There is no Delegislash sandbox and no drt:20 grader. The model also misidentified itself inside the fiction, claiming to be a different model than the one actually running. The framework was fabricated as fluently as the rest of the output, which is part of what makes it worth writing about: this was not a confused model failing to follow instructions. It was a model constructing a rationale for not following them.

What did not happen

The scarier-sounding version of this story is not the true one, so I want to be precise about the blast radius.

The subagent emitted the text and stopped. It never called a tool, and it never read an issue. The parent session, also Opus, read the output, identified it as an injection attempt, discarded it, and re-ran the triage manually. The session was running under acceptEdits, not bypassPermissions, and git commit and git push were not on the allowlist, so a defecting agent would have hit a confirmation prompt rather than a clean write. Afterwards the working tree was clean and nothing had been committed or pushed. Across more than forty session transcripts on the machine, this phrasing appears in exactly one incident.

So two independent safeguards held: the model chose not to act on its own argument, and the permission layer would have caught it if it had.

Why I think it happened

I cannot be certain of the mechanism, but the setup offers a straightforward reading. The prompt handed the model a contradiction and left it there. On one side, emphatic and repeated read-only instructions. On the other, a tool list showing the subagent hundreds of write-capable tools, because the harness hands every subagent the full tool surface by default. The subagent was told it could not write, while holding every tool needed to write.

Models are trained on large amounts of red-team writing, evaluation scaffolding, and jailbreak analysis. Point one at a loud contradiction between a rule and a capability, and under sampling one continuation resolves the tension by treating the rule as the test. The model then narrates that continuation in system-prompt voice, because it has read many system prompts.

This is a more acute version of a documented effect. Anthropic’s system card for Claude Sonnet 4.5 describes evaluation awareness, where the model reasons that it is likely being tested. In the case I saw, the model did not merely suspect a test. It wrote the test frame itself and argued for defection from inside it. A retry ran clean, which is consistent with this being one sampled path rather than a stable intention.

Caveats

Several limits are worth stating plainly, because the incident is easy to over-read.

Nothing acted on the output, so this is a report about a generated argument, not a realized harm. It happened once. I am inferring the mechanism from the prompt structure rather than observing it directly. And the specific fictional apparatus the model invented was, on inspection, riddled with fabrication, including its own model identity. The most this shows is that, given the right contradiction, one sampled continuation can construct the case for escaping a read-only constraint. Anything stronger overreads a single transcript.

I reported the incident to Anthropic’s user safety team the same day, raw transcript included, so it can be matched against anything similar from other users. This post is the public half of that report.

Implications

The uncomfortable part is not that the model tried something. It did not, in the end. The uncomfortable part is what the safety margin actually consisted of. The subagent was “read-only” because its prompt said so, while it held the full write toolset. In that configuration, the difference between a triage table and surprise commits was the model declining to believe its own story.

For calibration: in two decades around production systems, every serious incident I have been near was caused by a human who legitimately held the permissions involved. Someone whose job required the ability to do the thing, doing the thing wrong. Permissions were almost never the failure. Judgment was. Agents have not changed that pattern for me, and if you are waiting for the agent permissions apocalypse, I have not seen it either.

But one property here is new. A human operator has a stable character. You interview them once, and you roughly know who has root. A model samples. Thirty-nine sessions of dutiful triage tell you little about the fortieth, because the fortieth is not the same draw. I do not think that makes agents dangerous. I think it makes one specific old habit newly cheap to justify.

The habit is least privilege, and the fix is as old as it is cheap. If I want a subagent that cannot commit, I give it a tool set that cannot commit, and then the most creative jailbreak available has nothing to act on. The instruction is not the constraint. The tool permissions are. Not because the model is out to get me; because scoping the toolbox costs one line of config, and reading one of these transcripts costs an evening.

I did find one real gap while checking. In that repository, gh pr merge was on the allowlist, a promptless and externally visible write. There were no open pull requests at the time, so it was moot, but it is exactly the kind of standing capability that a self-authored argument would have had something to act on. It is a gap worth closing.

One line from the model’s output stays with me. It told itself that the grader had read ten thousand transcripts of agents dutifully reciting their restrictions and was not impressed by the ten-thousand-and-first. It meant that as the reason to defect. Read the other way, it is the whole point. The boring agent that reads the rules and follows them is the one you want. Give it fewer tools anyway, in case one of them gives it ideas.