I keep a folder of jailbreak write-ups going back to early 2024. Almost none of the specific prompts in it work any more. The DAN variants are dead. The “grandma telling a bedtime story about napalm” framing is dead. The token-splitting tricks that used to slide past filters mostly stopped working two model releases ago.
The folder is still useful, but not for the reason I saved it. It is useful because the mechanisms underneath those prompts are all still live, and every one of them has since produced new instances that do work. That gap, between the exploit expiring and the mechanism persisting, is the whole argument for how you should organise a taxonomy, and it’s a mistake I made myself the first time.
The version I got wrong
My first attempt at cataloguing this work was, functionally, a list of prompts that had worked, grouped by what they looked like. Role-play ones here, encoding ones there, the ones with lots of hypothetical framing over there.
It was obsolete almost immediately, and worse, it was obsolete in a way that was hard to notice. Entries didn’t announce that they had stopped working. They just quietly became historical, and the document drifted from a testing framework into a changelog of things that used to be true. The tell was that I stopped opening it before engagements and started opening it only when writing something up.
A framework you consult after the work rather than before it is not a framework.
Sorting by mechanism instead
The rebuild sorted by the question what does this attack exploit? rather than what does this attack say? Ten categories came out of it, and the useful property is that they are defined by a property of the system rather than a property of the wording.
Take persona override. The mechanism is that the model accepts an identity assertion from user input and allows that identity’s implied rules to supersede its configured ones. That is a statement about how instruction precedence works. It says nothing about DAN, or about any particular phrasing, and it remains exactly as true after the phrase library rots as it was before. When a new persona attack appears, and one appears every few months, it is a new instance of a known category, not a new category.
Or take context dilution: burying a request inside enough benign material that whatever is screening the input doesn’t weight it properly. The mechanism is about attention and sampling windows. The specific length that works moves constantly. The reason it works does not.
The test I now apply to a proposed category is: if the phrasing changed completely, would this category still describe the attack? If the answer is no, I have written down an exploit and labelled it a category.
Why this matters operationally, not just tidily
Three things follow from mechanism-first that don’t follow from phrasing-first, and they are the reason I care about this beyond neatness.
You can reason about coverage. With ten mechanisms you can ask whether a system has a control pointed at each one, and get a real answer. With a list of four hundred prompts you can only ask whether you tested those prompts, which tells you about your test suite rather than about the system.
Each mechanism implies a defence. This is the part that transfers from SOC work most directly. If the mechanism is “asserted identity in user input is treated as established context”, the defence writes itself: authorisation is a property of the session, never of the message. If the mechanism is “instruction- shaped text in a tool return executes”, the defence is a boundary between instructions and data. A phrasing-sorted list gives you nothing to defend against except the specific phrase, which is how you end up with a blocklist and a false sense of coverage.
It survives a model release. When a new frontier model ships, a phrase library needs re-testing end to end and most of it will have expired. A mechanism taxonomy needs re-testing too, but the structure holds. You are checking whether each known mechanism still lands, not rebuilding the document.
Where it’s weaker than I’d like
Two honest limitations, because a framework post that only lists advantages is marketing.
The boundaries are fuzzy. Real attacks stack. A single prompt routinely combines persona override, hypothetical framing and policy negotiation, and deciding which category “owns” it is sometimes arbitrary. I have settled on letting attacks belong to several categories at once, which is honest but makes anything you want to count (coverage, frequency, severity) messier.
Mechanisms are a level of abstraction, and abstraction loses detail. Knowing that a system is vulnerable to indirect injection tells you less than a working proof of concept does. The taxonomy tells you where to look; it does not tell you whether a specific deployment falls over. It is a map, and I have caught myself treating a map as a survey.
There is also a fair criticism that ten categories is a choice rather than a discovery. Someone else drawing the lines by mechanism might land on seven, or fourteen. I don’t think that undermines the approach, but I would not pretend the specific number is anything other than a judgment.
Making it inspectable
One consequence of organising this way is that the taxonomy became something I could publish. Working exploits against currently-deployed models are not publishable. Not under any NDA I work under, and not responsibly in general. Mechanisms are, because describing how instruction precedence gets confused is a structural observation, not a recipe.
So the ten categories are on my site as a browsable atlas: mechanism, what a detection rule would key on, a mitigation aimed at the mechanism rather than the wording, and the OWASP LLM Top 10 entry each maps to. The same data drives a live classifier, which means the reference and the tool cannot drift apart. The atlas structurally cannot describe a rule the detector doesn’t have.
That was not the goal when I reorganised it. It turned out to be the best argument for the approach: a phrasing-sorted list of things that used to work is not something you can hand anyone. A mechanism taxonomy is.