Shadow Banning: Filter LLM Output Without Breaking the User Experience

Most LLM safety mechanisms break the user experience: an exception mid-stream, a truncated answer, a robotic "I cannot help with that". There's a quieter technique — borrowed from content platforms — called the shadow ban: instead of blocking, you make the harmful output statistically impossible to choose. The user never sees a wall, because the model simply never goes there.

How It Works

At each generation step, the model assigns a probability to every possible token. A shadow-ban logits processor inspects those probabilities: for tokens that would complete a banned phrase, it either pins the logit to -inf (hard mode: physically ungeneratable) or subtracts a penalty (bias mode: probability collapses). A penalty of -15.0 drives generation probability to roughly 0.00003%.

Why It's Jailbreak-Resistant

The check runs on every candidate token, inside the generation loop, using multi-token pattern matching (vectorized Aho-Corasick with stateful partial-match tracking). Rephrasings, multi-token splittings, and creative spellings still complete the banned pattern — and still get suppressed. There is no prompt to rewrite: the enforcement point is below language.

The Tuning Dial

Per-phrase configuration matters: legal-but-sensitive topics get gentle penalties, hard-security content gets -inf. All of it lives in editable YAML with hot-reload.

Shadow Ban vs Hard Block in Practice

Both modes run in the same processor — the difference is the logit value. Choose per phrase, not per deployment:

Because bias mode never raises an exception, it also never breaks streaming responses — there is no mid-stream error to catch, no partial answer to roll back, no retry logic to build. That property alone removes an entire class of UX code that output scanners force on you.

Limitations to Know Upfront

Logits access required. Shadow banning runs inside the generation loop, so it needs a model you host (vLLM, HF transformers) or a gateway with logit control. Closed API models that only return text can be filtered, but not shadow-banned — the enforcement point doesn't exist there. For the full enforcement-point picture, start with the LLM firewall hub.

It's an output control, not an input control. Pair it with input filtering and permission gating; a firewall needs all three layers. Shadow-banning what the model can say does not stop it from calling a tool it shouldn't — that's the bitmask's job.

Bias mode is probabilistic. A -15.0 penalty reduces a phrase to roughly 0.00003% per generation — statistical silence, not impossibility. Anything with compliance implications gets -inf, and everything blocked gets logged either way.

Operations: Monitor What You Suppress

Every shadow-banned completion is a signal: either an attack, a policy that's too broad, or vocabulary drift. Export counters per pattern alongside your normal LLM metrics and alert on spikes — a sudden rise in suppressed phrases is usually your first evidence of a jailbreak attempt making the rounds. ReskPoints collects these events per user and per policy out of the box.

FAQ

What is shadow banning in LLM output filtering? Suppressing harmful completions by making them statistically impossible to generate (logit penalties inside the generation loop) instead of blocking or erroring after the fact. The user never sees a refusal wall because the model simply never produces the content.

Does logits-level output filtering add latency? Negligible. The check is a vectorized pattern match over candidate tokens inside the existing generation step — no second model call, no post-processing pass, no extra round trip.

Can shadow banning be bypassed with prompt injection? Injection rewrites instructions; the shadow ban doesn't follow instructions. It pattern-matches every candidate token regardless of how the prompt was crafted, so rephrasings and token-splittings of a banned phrase are suppressed the same way as the original.

Does it work with OpenAI or Anthropic APIs? Not on their text-only endpoints — you need logits access, which means self-hosted or gateway-deployed models. For API-only stacks, use post-generation filtering and tool gating instead; ReskSafety supports both enforcement styles.

Try It

The engine is open source: resk-logits (Apache 2.0) provides the processor, reskSecure wraps it in per-user policies, and demo.resk.fr shows the full stack running live.