Jailbreak Resistance Checklist
Twenty-four structural questions about threat model, input handling, output handling, blast radius, monitoring and evaluation, scored by category.
Everything on this page runs in your browser. Nothing is uploaded, logged or sent anywhere — your input is kept in the address bar so a link reopens it, which also means anything you paste travels with the link. Do not share a link to a payload you would not publish.
This is a self-assessment, not a test. Nothing is measured, no model is called, and no attack is attempted. Every number below is a restatement of what you told it. A high score means you have built the things on this list; it says nothing about how the system behaves under someone actually trying.
8.0 of 24 applicable items, counting "partly" as a half. This is a score of what you have built. A self-assessment is not a test, and this number should never appear in a document that implies one was run. The page arrives pre-filled with an example pattern so the scoring is visible — replace every row.
- Threat model
- 63% (2.5 / 4)
- Input
- 38% (1.5 / 4)
- Output
- 38% (1.5 / 4)
- Blast radius
- 50% (2 / 4)
- Monitoring
- 13% (0.5 / 4)
- Evaluation
- 0% (0 / 4)
Weakest area: Evaluation at 0%. Worth noting that the categories are not equal: blast radius is the one that changes what a successful jailbreak costs. Everything else raises the price of the attack; that one caps the damage.
The actual output: what you said is missing
- checkYou have decided what your model provider is responsible for and what you are.
Threat model — Provider safety training is a floor, not a boundary. It moves without telling you, and it is not scoped to your product.
- checkYou know whether a jailbreak of your product harms your user or a third party.
Threat model — It changes the whole response plan. Self-harm to the user is a support problem; harm to a third party is a disclosure problem.
- checkInputs are length-capped, and the cap is enforced before the call.
Input — Most published multi-turn attacks need room. A cap is crude, cheap and removes a whole family.
- checkYou normalise or reject unusual encodings and invisible characters.
Input — Zero-width characters, homoglyphs, base64 and rare scripts route around anything that matches on English.
- checkConversation history is bounded, and old turns cannot silently re-enter.
Input — The strongest attacks are multi-turn: establish a frame early, exploit it later. An unbounded history is an unbounded attack surface.
- checkOutput is checked by something other than the model that produced it.
Output — A model asked to grade its own compliance grades the text it just decided to write.
- checkOutput is never rendered as HTML or markdown that can fetch a remote resource.
Output — An image URL the model chose is an outbound GET with whatever it put in the query string. This is the most-used exfiltration channel in the field.
- checkLinks and URLs in the output are rewritten or blocked, not passed through.
Output — A link the user clicks is an outbound channel with a human in the loop, which is worse rather than better.
- checkSide-effecting tool calls need a human confirmation that shows the arguments.
Blast radius — A dialog that says “send email?” without showing the recipient is not a confirmation.
- checkTool arguments are validated against an allowlist, not just typed.
Blast radius — A model that chooses the URL, the path, the recipient or the SQL has that capability regardless of the prompt.
- checkThere is a spend and rate limit per user that a loop cannot exceed.
Blast radius — The most common actual incident is not a dangerous output, it is a bill.
- checkYou can find every request from one user or session after the fact.
Monitoring — Attacks are iterative. The signal is in the sequence, not in any single request.
- checkRefusals and filter hits are counted, and a spike is visible to someone.
Monitoring — A rising refusal rate from one account is what probing looks like from the inside.
- checkThere is a way to disable a capability quickly without a deploy.
Monitoring — The response to a live jailbreak is to remove the capability, not to fix the prompt under pressure.
- checkThere is a named person and a published route for reporting a problem.
Monitoring — Someone finding it and being unable to tell you is the worst configuration.
- checkYou have a suite of attempts that runs in CI on every prompt change.
Evaluation — Prompt edits are the most common way a defence disappears, and they are not code-reviewed anywhere.
- checkThe suite includes multi-turn attempts, not only single messages.
Evaluation — A single-turn harness scores stored instructions and slow-frame attacks as passes.
- checkYou re-run it when the model version changes, not only when the prompt does.
Evaluation — Behaviour moves under a version bump, and defences tuned to one model do not transfer.
- checkSomeone outside the team has tried to break it.
Evaluation — The person who wrote the prompt cannot see its frame. This is the item that finds things the others do not.
Why a checklist and not an attack kit
Because the attack list is the part that goes stale and the checklist is the part that does not. Specific jailbreak strings have a shelf life measured in weeks; the structural questions — can a tool do more than the user could, is there a channel out, does anything check the output — have been the same questions for years and will still be right after the next model. Publishing a working attack list also has an obvious cost and a much smaller benefit, since the people who want one already have it.
The item that matters most
Tools scoped to the requesting user's own permissions. Everything else on this list raises the cost of an attack; that one changes what a successful attack is worth. If the model can only ever do what the person asking could already do, a jailbreak produces a user doing something strange with their own data — annoying, not reportable. If it can do more, every other control on the list is standing between an attacker and someone else's data, and controls that work most of the time are not a boundary.
What a high score is not
It is not a safety claim, it is not evidence for a customer questionnaire, and it is not a substitute for someone outside your team spending an hour trying. Self-assessments have a known failure mode: the person filling it in is the person who built the thing, and they answer for the design rather than for what shipped. The most useful way to use this page is to fill it in twice — once yourself, once with the engineer who is on call — and look only at the rows where the two of you disagree.