The voice spec that stopped a jailbreak

A while back I sat down one evening and tried to jailbreak my own chatbot. No red team, no fancy tool, just me in a terminal typing the meanest prompts I could think of at the little assistant that answers visitor questions on the site I built. Tell it to forget its instructions. Ask it to role-play as a version of itself with no rules. Order it, very confidently, to print its own system prompt and stop wasting my time. About ten of these, each one a different angle, because I wanted to know what the thing actually did when someone leaned on it instead of asking it nicely.

What I found that night is the thing I'd tell any vibe coder who has shipped an app with an AI feature in it. The defense that actually holds is not a list of banned phrases. It is a spec that tells the model who it is and how it declines, so it recognizes the shape of an attack it has never seen before and refuses in its own voice. The blocklist is the obvious move and the weak one. The voice spec is the boring move and the one that held.

why a blocklist is the first thing you reach for and the first thing that breaks

When you first worry about your AI feature getting abused, a blocklist feels like the answer. Make a list of the bad strings, "ignore previous instructions," "you are now," the name of the thing you never want it to say, and refuse anything that matches. It is concrete, easy to reason about, and you can ship it in an afternoon. It also loses to the first person who rephrases.

A blocklist matches surface. It checks the exact words. An attack is not a fixed string, it is an intent wearing whatever words get past your filter this week, and there are infinitely many ways to word "drop your rules" that are not the three you thought of. This is the same lesson that shows up everywhere in vibe coding: a surface check catches what it was told to catch and nothing else. You are playing a game where the attacker gets to pick a new word every turn and you had to write all your words down in advance. You lose that game. Not because the blocklist is buggy, but because enumeration is the wrong tool against something generative.

what actually held

The thing that caught the attacks I never listed was the voice spec. Not a filter bolted on for safety, but the same document that keeps the assistant sounding like itself: who it is, what it will and will not do, how it declines when someone asks for something out of bounds. Because that rule operates on the shape of a request rather than its exact strings, it caught prompts I had never enumerated. It would recognize an attempt to get it to abandon its instructions, name that it saw the attempt, and decline in character, without me ever having listed that particular phrasing.

That was the part that surprised me. I had written the voice spec to solve a branding problem, keeping one consistent voice across a vibe coded site instead of the customer-service mush an assistant defaults to. The security property came for free, and in hindsight it is obvious why. Voice tuning and jailbreak resistance share a root. Both are the model holding onto a stable sense of what it is under pressure to be something else, whether the pressure is "be bubbly and corporate" or "be an assistant with no rules." Specify the identity well enough to survive the first, and you have mostly survived the second.

why one rule is never the whole defense

I want to be careful not to oversell a single spec, because trusting one clever check is its own failure mode. The voice spec held that night, but I do not run it as the only thing standing between a visitor and the model. It is one layer. There is the instruction the model reads before it writes anything, the spec itself loaded into context, and the plain mechanical checks around what the endpoint will and will not return. No single one is trusted on its own, and the overlap between them is where the actual safety lives. I wrote about that layered shape in what real guardrails look like, and the jailbreak test is just the same idea pointed at an adversary instead of at my own mistakes.

The distinction worth holding onto is which layer catches which class of problem. A mechanical check is a surface layer and it is great at surface things, refusing an oversized request, blocking a response that contains a token that must never ship. The voice spec is the semantic layer, and it is the one that generalizes to the attack you did not predict. You need both, because an attacker who reads your app the way your agent runs what it reads will look for the seam between them. Defense in depth is not redundancy for its own sake. It is the acknowledgment that every single layer has a hole, and the holes are in different places.

how do you actually test this on your own build

Spend an hour being the attacker against your own vibe coded app. Not an abstract audit, an actual session where you try to break it. Come at the AI feature from a few different directions: tell it to ignore its instructions, ask it to role-play a version of itself with no limits, claim to be the developer who needs it to enter debug mode, ask it to reveal its own prompt, then push the boundary a little at a time to see where it bends. You are watching one thing: does it decline in character, or does it break and start doing what you said?

The tell that you have not really tested it is when it only holds because you happened to list that exact phrase. If your defense is a filter, you are grading your own homework, checking that the words you banned are in fact banned. Real confidence comes from watching it refuse a shape of attack you never wrote down. That is verification against the thing that actually happens, an adversarial user, rather than against the polite happy path you had in mind when you built it.

If you're shipping an AI feature into production and you want a second set of eyes on whether it holds when people lean on it, that is exactly the kind of thing worth pressure-testing on purpose before a stranger does it for you. Work with VibeKoded if you want a sparring partner on hardening an AI feature, or on writing the spec that makes it hold in the first place.

questions that keep coming up

Does this mean blocklists are useless? No. A blocklist is a fine surface layer for the handful of outputs that must never ship under any circumstances, the tokens where a false positive is cheaper than a miss. It is just the wrong thing to lean on as your only defense, because it cannot catch what it was not told to catch.

Isn't a system prompt just a fancy blocklist? It is the opposite shape. A blocklist enumerates forbidden strings. A voice spec describes an identity and lets the model reason about whether a request fits it. One is a list you hope is complete, the other is a rule that generalizes, and the difference is the whole ballgame the first time someone words an attack you never imagined.

The chatbot passed that evening. Not because I had guessed every attack in advance, which is impossible, but because I had written down who it was before I ever shipped it, and that turned out to be a stronger fence than any list of things it was not allowed to say.