LLM Guard was archived on July 9, 2026. The Python package still installs, the MIT license still applies, and the repository is still downloaded roughly 174,000 times a month — but no one is merging security fixes. For teams that put it in the request path of a production LLM, that is the moment to decide: freeze the dependency, fork it, or migrate.
This guide covers what the archive actually changes, the migration options, and a compatibility path that keeps the familiar scan_prompt and scan_output contract without pretending that a scanner and a generation-time control are the same thing.
What "archived" means in practice
Archived is not deleted. Your build will keep working. What stops is the part that matters for a security dependency:
- No security patches. A CVE in a scanner dependency, a bypass in a regex, or a new prompt-injection technique stays unfixed.
- No compatibility updates. New
transformers,torchor Python releases can break the package with no upstream fix. - No triage. Issues and pull requests are no longer reviewed, so a bypass reported by a researcher has nowhere to land.
- A false sense of coverage. The scanners still return scores, which makes the pipeline look healthy while its detection logic ages.
The project was acquired with Protect AI by Palo Alto Networks in 2025 and folded into Prisma AIRS. That is a rational outcome for the vendor; it is a supply-chain problem for everyone who self-hosts the open-source library. The same consolidation hit Lakera (Check Point), Robust Intelligence (Cisco) and Portkey (Palo Alto).
The four realistic options
| Option | What you get | What you own |
|---|---|---|
| Freeze LLM Guard | Zero migration effort today. | All future CVEs, Python upgrades and bypasses. Acceptable only for a short-lived internal tool. |
| Fork it | Full control of the scanners. | A security product to maintain: dependencies, model weights, tests, releases. Usually underestimated. |
| Move to a platform | Managed detection, support, compliance. | Data leaving your perimeter, per-request pricing, and a roadmap you do not control. |
| Migrate to a maintained library | Patched dependencies and an active release cadence. | Re-validating detection quality on your own corpus. This is the real work, and it is unavoidable. |
There is no free option. The question is whether you pay in migration time now or incident time later.
Which maintained alternatives are worth a look
They do not solve the same problem, so evaluate them against your threat model rather than a feature count:
- NVIDIA NeMo Guardrails — programmable conversational rails, including tool-execution rails. The strongest fit if you need dialog control and already run NVIDIA infrastructure.
- Guardrails AI — a validator hub for structured outputs and schema checks. Good when the failure mode is malformed or policy-violating output, not adversarial input.
- Microsoft Presidio — still the reference for PII detection and anonymization. Pair it with an injection detector rather than using it alone.
- RESK-LLM — a maintained, dependency-light detector pipeline with an LLM Guard compatibility shim (below). The differentiator is generation-time enforcement through resk-logits, not another scanner list.
If your priority is a managed API, the platform options are mature. If your constraint is self-hosting, regulated data, or a European provider, the open-source shortlist is much shorter than it was in 2024.
Migrating the scanner API without rewriting the pipeline
A typical LLM Guard pipeline has two calls and a list of scanners:
from llm_guard.input_scanners import PromptInjection
from llm_guard.output_scanners import Sensitive
from llm_guard import scan_prompt, scan_output
scanners = [PromptInjection(), Sensitive()]
sanitized, valid, scores = scan_prompt(scanners, user_prompt)
clean, valid_out, scores_out = scan_output(scanners, user_prompt, model_output)RESK-LLM ships a compatibility module with the same three-tuple contract, so the call sites do not change:
from resk2.compat.llm_guard import (
PromptInjection, Sensitive, scan_prompt, scan_output,
)
scanners = [PromptInjection(), Sensitive()]
sanitized, valid, scores = scan_prompt(scanners, user_prompt)
clean, valid_out, scores_out = scan_output(scanners, user_prompt, model_output)The shim provides PromptInjection, Jailbreak, Sensitive (email, phone, card, IBAN, API key and JWT redaction), BanTopics and Toxicity. Unknown constructor arguments are accepted, which matters when your scanner configuration is spread across a dozen services.
Two caveats, stated plainly:
- The shim is API-compatible, not detection-identical. Re-run your red-team corpus and compare block rates and false positives. A migration that silently lowers recall is worse than no migration.
- A scanner still runs after generation. If your requirement is "the forbidden sentence must never be emitted", add a generation-time control. That is what logits-level filtering is for.
A minimal migration checklist
- Inventory the scanners you actually use. Most teams run three to five, not twenty.
- Freeze the corpus. Export the prompts and outputs that previously triggered each scanner; that is your regression set.
- Map each scanner to a maintained equivalent and record the ones with no equivalent. Those are your real gaps.
- Run both pipelines in shadow mode for a week and diff the verdicts. Investigate every disagreement, not just the aggregate rate.
- Pin versions and add a dependency audit to CI, so the next archive is a pipeline failure rather than a surprise.
- Keep the old package installed only as long as the shadow run needs it, then remove it from the image.
What to do this week
If LLM Guard is in production, the minimum viable response is not a rewrite. It is: pin the exact version, add a CI audit, and put a migration owner on the calendar. The longer an unmaintained security dependency stays in the request path, the more the eventual migration costs — and the more likely it becomes an incident rather than a project.
Try the compatibility layer
Keep your scanner calls, move to a maintained pipeline.
RESK-LLM Monitor the migration