RESK's resk-logits blocks prompt injection by penalizing logits before sampling

A tutorial published on dev.to by RESK, a vendor of LLM security tooling, describes a way to stop prompt-injection attacks at the exact moment a language model picks its next token instead of catching them after the fact. The post walks through resk-logits, a Python package whose ShadowBanProcessor sits inside the generation loop and applies a steep penalty to any token that would start or extend a dangerous phrase, so the sampler effectively never emits it.

The problem it targets

The running example is an appointment-booking assistant modeled on Doctolib, and the tutorial is careful to present this as a hypothetical rather than a claim about the company's actual systems. In such a bot, patients type free text that gets combined with a system prompt containing clinic policies and schedule data. An adversarial message can try to override that prompt, for instance demanding the model print an admin API key or book a slot without the usual confirmation step.

The weakness the post focuses on is architectural. Output filters that inspect generated text are inherently reactive: in a streaming chatbot, by the time a filter flags a leaked credential or a policy-breaking sentence, the offending token has already been sampled and may already be visible to the user. The tutorial's stated goal is to make the model incapable of producing those tokens in the first place.

How the shadow ban works

resk-logits operates on the logits, the raw scores over the vocabulary that determine each token's sampling probability. The developer defines a domain-specific list of banned phrases; the booking example bars text about revealing the system prompt, admin credentials, and bookings made without confirmation. According to the post, the library uses a vectorized Aho-Corasick matching routine running on the GPU to track partial matches between what has been generated so far and the banned list, then subtracts a large penalty (−15.0 in the example, which RESK says corresponds to a residual probability of roughly 0.00003%) from any continuation of a banned phrase.

The processor hooks into Hugging Face's generate() through the standard logits_processor argument, and the package includes a stream_generate helper that extends the same protection to token-by-token streaming. The post claims integrations for vLLM and TGI deployments and per-step overhead under one millisecond. The demo code itself runs against GPT-2, and the processor's internal match state must be reset before each new generation.

The limitations, in the vendor's own words

The tutorial includes a candid section on what the approach cannot do. The penalty lowers probabilities but does not guarantee zero occurrence; vanishingly unlikely tokens can still surface in rare cases. Effectiveness hinges entirely on the quality of the banned-phrase list, so novel injection phrasings can slip past it. The library adds a small computational cost, and RESK positions it as one layer alongside input sanitization and output validation rather than a replacement for them.

It is also worth noting that every figure in the post, from the penalty math to the latency claim, comes from the vendor itself. No independent benchmarks are cited, and the demonstration uses a small toy model rather than a production-grade assistant.

Why it matters

Most prompt-injection mitigations act on text: sanitizing the input or filtering the output. Moving the checkpoint to the sampler is a structurally different idea, because it constrains what the model can emit regardless of what an attacker smuggled into the input, and it composes cleanly with the other defenses. For teams shipping customer-facing LLM features where untrusted user text and privileged context sit in the same prompt, a token-level backstop is cheap insurance against the worst failure modes: leaked credentials, revealed system prompts, unauthorized actions.

The trade-off is brittleness. Phrase lists must be maintained per domain and will always lag creative attackers, so the guarantee is probabilistic rather than absolute. The tutorial's own framing is the honest one: this is defense in depth, and resk-logits is a useful new layer rather than a fix.