How Output Guardrails Actually Work
A system prompt asks the model to behave. A guardrail decides what actually leaves the wire. The simulation below walks through the second thing — it's built to explain the mechanism, not to demo a live system.
⚡ Audit Log Output
EVIDENCE FOR SOC 2 / GDPRIllustrative simulation using synthetic data. No real customer records are used on this page, and the timings shown are placeholders that illustrate the sequence — they are not measurements of any system.
What Happens Between Token And Screen
Intercept
Tokens are captured as the provider streams them, before your application layer hands the chunk to a user.
Classify
A rolling buffer is matched against active policy modules — regex, entity classifiers and structural rules in parallel.
Enforce
On match, the span is masked, substituted or blocked according to the policy's configured action.
Record
The event is signed and appended to the ledger: rule, action, model version, timestamp, requester.
Release
The sanitised chunk continues downstream. Streaming order and structure are preserved.
Fast Enough To Leave On
A guardrail that costs 200ms gets switched off before the quarter ends. This matters more than the feature list, and it's the number most vendors are vaguest about.
So we're not going to quote you numbers we haven't measured on your stack. What we'll tell you instead is what actually drives the cost — and then benchmark it properly during the assessment.
What makes it cheap
Pattern-based detection — SSNs, card numbers, key formats — is close to free. It's a regex pass over a buffer, and it runs in the gap between provider tokens where you have latency to spare anyway.
What makes it expensive
Classifier-based scanning — named entity recognition, toxicity, bias detection — means running another model. That cost is real, it scales with output length, and whether it's acceptable depends on your UI.
What we do about it
Benchmark your traffic before enabling anything, put the cheap scanners in the streaming path and the expensive ones out of band where the use case allows. You get the measurement, and it's yours to keep.
What Happens When Something Breaks
Any vendor sitting in your critical path owes you a straight answer to this. Here's ours.
If the scanning layer fails
You choose per policy, and we configure it. Fail-open forwards traffic unenforced and raises a high-severity alert — availability wins. Fail-closed rejects the request — safety wins. Our recommendation is fail-closed on health data and credentials, fail-open elsewhere.
If a policy produces a false positive
This is why we run every new policy in monitor-only against your real traffic first. You learn your actual false-positive rate before anything is blocked from a user, and tuning happens against data rather than guesswork.
If a policy misses something
No output filter catches everything — anyone claiming otherwise is selling you something. This is a control layer, not a guarantee, and you should not represent it to a customer as one. It belongs alongside data minimisation at the source, scoped retrieval, and human review for consequential decisions.
What we store — nothing
The tooling runs in your infrastructure and the logs are yours. We don't sit in your request path and we don't hold your data. During an engagement we work from architecture and synthetic examples — we don't ask for production credentials or live personal data, and we'd decline them if offered.
Run this against your traffic
Fifteen minutes, one endpoint, and you'll see your own interception log instead of ours.