Scan model output too, not just user input. The threat model changed the day agents started executing tool output. Untrusted text does not only come from users anymore:

Compose your own policy with per-scanner thresholds:

Every scanner returns findings with the scanner name, a score, and the matched spans, so you can log exactly what fired and why. No black boxes.

## What is in v1

Ten scanners, all deterministic:

| Scanner | What it catches |
|---|---|
| `prompt_injection` | Instruction overrides, delimiter smuggling (`<<SYS>>`, `[INST]`), jailbreak markers, role-play switches, system-prompt extraction |
| `secrets` | AWS, GitHub, Slack, Stripe, OpenAI, Anthropic, Google keys; generic `key = value` assignments; unlabelled high-entropy tokens |
| `pii` | Emails, phone numbers, US SSNs, credit card numbers (Luhn-validated) |
| `toxicity` | Profanity wordlist, scored by density |
| `gibberish` | Keyboard-mash and degenerated-model noise via consonant-ratio and entropy signals |
| `ban_topics` | Configurable banned-topic keywords (weapons, self-harm, illicit behavior by default) |
| `code_execution` | `os.system`, `subprocess`, `eval`/`exec`, `pickle.loads`, aimed at untrusted tool output |
| `url_allowlist` | URLs pointing outside your configured domain allowlist |
| `token_limit` | Text over your token budget (chars/4 heuristic) |
| `regex` | Your own required/forbidden patterns |

Two thin adapters, both optional:

## The benchmarks, and what they do not prove

Each scanner ships with a labeled corpus under `benchmarks/`: true positives and true negatives, including adversarial and near-miss cases. Run them yourself:

On the bundled corpora, 133 cases across all ten scanners, every scanner lands at 1.00 precision and 1.00 recall.

Now the honest part. These corpora are small and hand-written. A 1.00 on 133 cases is a smoke test proving the patterns fire on the obvious cases. It is not a safety certification. Real attacks are more creative than any corpus I can write alone, which is why larger community-sourced corpora are on the roadmap. If you evaluate against your own data, please contribute the cases back.

## Read the limitations before you trust it

Every scanner documents its limitations in its docstring, and I would rather you read them than my marketing. The short version:

- Pattern matching is not understanding. Novel phrasings, non-English attacks, and heavy obfuscation (zero-width characters, homoglyphs) will get through the prompt-injection scanner. A unicode normalization pass is on the roadmap precisely because of this.
- The secrets entropy heuristic misses short secrets and flags some non-secrets. In-house key formats need your own patterns.
- PII coverage is narrow by design: email, phone, SSN, card. Names, addresses, and non-US identifiers are not covered.
- Toxicity and ban-topics are wordlists with no sense of context. They will flag legitimate discussion of the thing they police.
- Redaction removes matched characters, not meaning. Do not rely on it alone for data you cannot afford to leak. Pair it with blocking.

A guardrail library that will not tell you where it is blind is selling you something. This one tells you.

## A worked example: guarding tool output

The input scanners get all the attention, but the scanner I reach for most is `code_execution`, because the threat model flipped when agents started running tools. The dangerous text is not the user's prompt anymore. It is the tool output your agent is about to act on.

Picture it: your agent fetches a URL, or reads a file, or gets a function result back from some third-party API. That text goes straight into the model's context, and the model treats it as instructions unless something intervenes. A poisoned README or a compromised API response can carry this:

Your model reads that as helpful documentation. The `code_execution` scanner reads it as `os.system` plus a shell pipe and blocks the text before it ever reaches the model:

This is the scanning direction most tutorials skip, and it is the one that matters most once you give a model hands. Scan what goes in, scan what comes out, and scan what comes back from the tools in between.

## If you are migrating off llm-guard

Three things I would do first:

1. Start with the scanners that have no judgment calls: `secrets`, `pii`, `prompt_injection`, `code_execution`. These are the highest signal, lowest false-positive set.
2. Run in collect-all mode for a week before you block anything. Log the findings, read them, tune your thresholds against your actual traffic. A guardrail you deploy in block mode on day one will block your own legitimate traffic by day two. I have the scars.
3. Treat the benchmark as a starting point, not a verdict. Run `python -m llm_sentinel.benchmark`, then add your own cases from production. The corpus format is plain JSON, one file per scanner, and contributions back are the fastest way to make the library smarter for everyone.

## Roadmap

- Unicode normalization pass (zero-width chars, homoglyphs) before scanning
- Pluggable LLM-as-judge scanner interface (opt-in, never the default)
- Anonymize transform for PII (typed placeholders, reversible with a local key)
- More adapters (Django middleware, crewAI callbacks)
- Larger, community-sourced benchmark corpora

If you are migrating off llm-guard, the core contract is the same shape: scan text in, get findings out. The difference is the strictness: nothing here needs a GPU, an API key, or a second opinion from another model.

Contributions are welcome, especially adversarial test cases. The repo is at https://github.com/anushamukka9/llm-sentinel.

One question for the comments: what is the nastiest prompt-injection phrasing you have seen in the wild that a pattern matcher would miss? I will add the good ones to the corpus.