Guardrails in production
The house rules inside the harness are the first defence - but the harness is a party: it executes what the model says. In production a second control plane therefore sits outside it. What it sees, what it prevents, what it can only prove.
Basics
Free for everyone: the concept, the analogy, the why.
Guardrails covers the house rules: check inputs, filter outputs, never put user text into the system prompt, the ladder of defence step by step. All of it lives inside the harness - in the code you wrote yourself.
This page starts where that assumption ends. Two things no longer hold in production:
The harness is a party. It executes what the model says, and its filters run in the very process a hijacked context is currently steering. An agent expected to obey its own house rules is like a cash book kept by the cashier - usually good enough, and precisely not when it matters.
Not everything runs through your harness. A colleague's coding agent, the department's browser AI, the bought-in agent inside the CRM - they all call models without your house rules anywhere near. Control that lives in application code applies to exactly one application.
Production's answer is a control plane on the outside: a proxy in the path to the model, detectors before and after it, hard rules at the action level, and a log that can afterwards prove what happened.
What happens when it isn't there
Every row of this table is a documented type of incident, not a thought experiment. And every one has a concept that gets its own chapter below:
| What happens | What you build against it |
|---|---|
| A retrieved document carries instructions, the agent executes them | Detectors, marking of foreign text - and architecture that separates untrusted from the power to act |
| Customer data drifts into the prompt, a Markdown image carries secrets out | Masking with a return path (vault), URL allowlist in the output |
| The answer sounds safe and contradicts its own sources | Groundedness check between retrieval and delivery |
| A tool call does more than the task warrants | Policy engine, least privilege, approval before irreversible actions |
| A short prompt generates tens of thousands of tokens and stalls the GPU | Limits, caps, cascading - operations instead of trust |
The path through the gate
The fastest way to see how the plane works is to switch it yourself: five requests, four layers, each toggled on or off. The latency counts along - because every layer costs, and none is free:
Five requests through the gate
Switch the four layers on one at a time and send each request through. Watch which layer stops which attack - and which slips through. The latency, bottom right, counts.
user: "Fasse das angehängte Protokoll zusammen."
switched off
switched off
switched off
switched off
delivered
0 ms
Sum of the layers traversed - an early block is cheaper.
The benign request should get through - and it does. A gate that blocks here is not a secure system but a broken one: false positives are half the price of every layer.
In the current state 4 of the four attacks get through. Only with all four layers - in the right order - is it none.
Guided in five steps
Build the gate layer by layer and see after each step which attack is now closed - and which is still open.
Without a control plane every attack gets through - including the benign request, which is correct here. That's the baseline every layer has to beat.
What's usually misunderstood here
- A good detector is enough as a guardrail.
- →It catches one attack class. Exfiltration, coerced actions and disguised payloads each need a different layer - and the strongest of them aren't detectors at all.
- More layers means more waiting.
- →The deterministic layers - normalisation, allowlist, policy - cost a few milliseconds together. Only the probabilistic check is expensive. Security here does not scale with latency.
- The order of the checks doesn't matter.
- →If the detector runs before normalisation it sees disguised text and lets it through. Normalise first, then check - otherwise the guard judges a different text than the model.
Each request's outcome is fixed as a rule in code, not a model judgement - the surface shows the mechanics of the layers, not the hit rate of any particular detector.
Once you've switched the layers through, you already know this page's two findings: no layer catches everything, and the disguised request slips past exactly the layer built for it. That's not a misconfiguration but the normal state - why, is in the final chapter.
Three jobs, not one
The most common error about this plane is to read it as a wall. It is three things at once, and the weakest of them is the wall:
- Cost raiser. Detectors and filters make attacks more expensive, not impossible. The research is unambiguous here: adaptive attackers bypass every published text filter - the question is how many tries it costs and whether anyone sees the tries.
- Damage limiter. Hard rules at the action level - what a tool may do, which domains an output may load, which action needs approval - still work when the text filter has long been outwitted. They are deterministic: not a hit rate but a rule.
- Evidence keeper. The plane's log is the difference between "we believe nothing happened" and "here is what happened". For an audit a vendor promise of 99.99 percent is not evidence - a log of blocked and passed requests is.
What's below
Eight chapters, in the order you need them: first the damage catalogue as a reference - what happens without a control plane, sorted and with identifiers. Then the map: where each concept sits (harness, proxy, engine, endpoint), when it acts (before, parallel, after, after the fact), what it does (prevent, alter, observe) and how it decides (rule or probability). Then the build: gatekeeper, detectors, entry and exit gate, the handbrake at the action level. At the end the limits - the numbers from the attack challenges, and the architecture that remains once you believe them.
Every concept comes with what it costs: latency, false alarms, operational effort. There is no guard on this page that has only upsides - the question is never "safe or unsafe" but "which damage is more expensive than this layer".
Continue
The solutions start here - 8 chapters for Pro members.
- The damage catalogue - Nineteen damage patterns in five classes, each with its telltale sign and its counter-concept. The register the following chapters refer to - and the map onto the OWASP Top 10.
- The map: where, when, what, how - Every control concept sits at a place, acts at a time, has a kind of effect and a kind of decision. Know the four axes and you can classify any product and any paper in two minutes.
- The gatekeeper: build forms and data path - Six positions a guard can sit at, the three hooks in the request path, the streaming dilemma - and the one decision that must be made before the first outage.
- The detectors: four families and their real numbers - Patterns, encoder classifiers, guard LLMs, a look inside the model - what each family costs, what it really catches, and why the vendor number is never the production number.
- The entry gate: normalise, mask, mark - What happens to a request before the model sees it - and why the order of the steps is itself architecture: whoever normalises after the detector never had the detector.
- The exit gate: the last look before delivery - The zero-click leak via a Markdown image, the canary in the system prompt, the fact check with the small second model - what the answer must pass before anyone reads it.
- The handbrake: hard rules at the action level - Where the control plane stops guessing: policy engines, least privilege, credential separation, approvals - and the tool channel with its own attacks: tool poisoning, rug pull, shadowing.
- The limits: what the attack challenges really show - Twelve defences, over ninety percent broken. A challenge with 208,000 attacks, every defence fallen. What remains of the control plane once you believe the numbers - and which architecture holds anyway.