Which to choose when LLM Guard is already in production
If LLM Guard is already running in production, the first decision is not which tool to adopt but how soon to stop depending on it. LLM Guard's repository was archived on July 9, 2026, its README states the project and its Hugging Face models are no longer maintained, and so it receives no security fixes. LlamaFirewall is a reasonable replacement path for teams that want a Meta-maintained, MIT-licensed framework covering prompt injection and generated code, so plan migrations toward it or another maintained option rather than new LLM Guard rollouts. Confirm the license of any model you pull in separately, because LlamaFirewall's components are not all under the same terms.
Three drivers should settle the choice. First, identify the application type. LlamaFirewall's PromptGuard 2 targets direct prompt injection in chat models, its AlignmentCheck scanner audits the reasoning of agents, and CodeShield analyzes LLM-generated code. If your LLM Guard use is mostly input scanning on a chat front end, the mapping is direct. If you run tool-calling agents or code generators, you will need the agent and code layers and should test them against your own traffic. Second, list the non-LLM output scanners you depend on today, such as those for malicious URLs, sensitive data or JSON validity. LlamaFirewall's regex and custom scanners can cover some of these, but you must write and test them yourselves. Third, check whether a dependency on a Together API key for AlignmentCheck is acceptable under your data handling and vendor rules, since that scanner requires it.
Which scenario favors LlamaFirewall or another path
This table maps common LLM application scenarios to the better fit among LlamaFirewall, Guardrails AI, NeMo Guardrails and a replacement for LLM Guard's archived scanners. Read each row for the condition that decides the choice, and treat any gap as something to confirm in your own tests. The main takeaway is that LlamaFirewall covers prompt injection, agent reasoning and generated code, while PII, secrets and several output checks need a plan beyond it.
| Scenario | Better fit | Deciding condition |
|---|---|---|
| Chat assistant with direct prompt injection risk | LlamaFirewall with PromptGuard 2 | Confirm the Llama 4 Community License terms that cover PromptGuard 2 model weights fit your use. |
| Agent that calls tools | LlamaFirewall with AlignmentCheck | AlignmentCheck needs a Together API key, so confirm the data sent to it is acceptable for your environment. |
| Code-generation feature | LlamaFirewall with CodeShield | CodeShield covers 8 languages through Semgrep and regex rules. Confirm your languages are included. |
| PII anonymization or secrets detection | Confirm a maintained replacement for Anonymize and Secrets | No direct LlamaFirewall equivalent is documented. Custom regex scanners may cover known token formats, but test detection before relying on them. |
| Dialog or topic rails | NeMo Guardrails | Colang defines dialog rails. Confirm the topic control you need, since LlamaFirewall's documented scanners do not describe dialog rails. |
| Output format, toxicity or malicious URL checks | Guardrails AI validators | Validators come from Guardrails Hub and structured output uses Pydantic models. Confirm each validator you need exists before committing. |
| Platform on Python 3.13 or later | LlamaFirewall | LLM Guard's last PyPI release excludes Python 3.13 and above. LlamaFirewall requires Python 3.10 or later. |
How LLM Guard and LlamaFirewall are built and deployed
LLM Guard and LlamaFirewall solve overlapping problems but ship in very different shapes. One is an archived scanner library with a deployable API server, the other is a maintained framework that sits across chat models and agents. The cards below cover the packaging, runtime and operating questions that decide how each one would fit into an existing LLM stack.
LLM Guard as a library or API server
LLM Guard can be installed with pip and called directly from Python, or deployed as an API server that other services reach over HTTP. That choice decides where scanning runs, who owns the process and how it scales. It also matters for an archived project: the last release on PyPI is 0.3.16, uploaded on 19 May 2025, so any server you run today is frozen at that code. Confirm that your internal images and dependency pins can be rebuilt without upstream fixes.
LLM Guard scanner catalog
The documented scanner set covers 15 input scanners and 20 output scanners, including Prompt Injection, Secrets, Anonymize and Malicious URLs on the output side. Each scanner is a separate component you enable, tune and test. Map each one to a risk in your own threat model, then confirm that the model it depends on still runs in your environment, since the project's Hugging Face models are no longer maintained either.
LLM Guard Python version ceiling
LLM Guard 0.3.16 requires Python 3.10 or newer but below 3.13. That upper bound is an operational constraint: a platform team that standardizes on Python 3.13 or later cannot install the release as published. Check the interpreter version in your base images early, because a forced downgrade or a fork is a cost you carry for as long as you keep the scanner.
LlamaFirewall as a layered framework
LlamaFirewall is a framework that layers several scanners across chat models and agents rather than a single scanner set. It combines PromptGuard 2 for direct prompt injection, AlignmentCheck for auditing agent reasoning, CodeShield for insecure generated code, and regex or custom scanners. The practical question is which layers your application needs. A chat-only assistant may not need AlignmentCheck, while an agent that writes and runs code likely needs CodeShield.
LlamaFirewall install and Python floor
LlamaFirewall installs with pip install llamafirewall and needs Python 3.10 or later, with no upper bound stated in its README. Its demos cover OpenAI Agents and LangChain, which makes it a closer fit to agent frameworks than to a generic API gateway. Plan the integration as code inside your application process, and test the scanner calls in the same CI pipeline that ships the agent.
AlignmentCheck and its external key
AlignmentCheck audits agent reasoning, which LLM Guard has no direct equivalent for. Its scanner requires a Together API key, so calls leave your environment unless you have confirmed otherwise with the maintainers. Treat that dependency as a data flow decision for your security and privacy review, and confirm whether an alternative path exists for air-gapped or restricted deployments before you rely on it.
Capability comparison: prompt, response and code scanning
This table compares the two toolkits row by row on the scanning jobs that matter during a replacement, plus license, maintainer status and release history. Read the rows marked as items to confirm as gaps you must test yourself before cutover, since no direct equivalent is documented in the sources we reviewed.
| Capability | LLM Guard | LlamaFirewall |
|---|---|---|
| Prompt injection detection | Prompt Injection input scanner, one of 15 documented input scanners | PromptGuard 2 classifier for direct prompt injection, available as 86M and 22M variants with a 512-token window |
| Output scanning | 20 documented output scanners, including Factual Consistency, JSON, Malicious URLs, No Refusal, Sensitive and Toxicity | No general output scanner documented in the sources reviewed; regex or custom scanners may cover some checks, so confirm coverage |
| Code safety | No dedicated generated-code scanner documented in the sources reviewed | CodeShield statically analyzes LLM-generated code in 8 languages using Semgrep and regex rules |
| Agent reasoning audit | Not documented as a feature; confirm before assuming coverage | AlignmentCheck audits agent reasoning, but it requires a Together API key |
| PII and secrets handling | Anonymize, Deanonymize and Secrets scanners documented; confirm behavior against your data types | No direct PII or secrets scanner documented in the sources reviewed; confirm with the maintainers or build a custom scanner |
| License | MIT | MIT for the framework; the PromptGuard 2 model weights ship under the Llama 4 Community License Agreement |
| Maintainer status | Archived on GitHub on July 9, 2026; no longer maintained and receives no security fixes | Maintained under Meta's Purple Llama repository |
| Latest release | Last PyPI release is 0.3.16, uploaded May 19, 2025 | Version 1.0.3 is the latest on PyPI |
| Python requirement | Python 3.10 or newer but below 3.13 | Python 3.10 or later |
Licenses and what each component carries
LLM Guard is Protect AI's MIT-licensed toolkit of input and output scanners. The repository was archived on July 9, 2026, and its README states that the project and its associated models on Hugging Face are no longer under active development or maintained. The MIT license lets you keep using the code you already have, but it does not give you security fixes. Your existing deployment keeps the license it shipped with, and the archive changes the support position rather than the permission to use the code.
- License: MIT, as stated in the project README.
- Last release: The last PyPI release is 0.3.16, uploaded on May 19, 2025, requiring Python 3.10 or newer but below 3.13.
- Maintenance: No security fixes will arrive, so any vulnerability in a scanner or in its Hugging Face models stays open unless your team patches it.
- Dependencies: Review the models your installed scanners download from Hugging Face, since their terms are separate from the library's MIT license.
Confirm with your legal team which third-party models your current LLM Guard configuration loads, and record their licenses alongside the code license before planning the move to a maintained component.
LlamaFirewall is an MIT-licensed framework from Meta's Purple Llama repository. It layers scanners for chat models and agents, including PromptGuard 2 for direct prompt injection, AlignmentCheck for auditing agent reasoning, CodeShield for insecure generated code, and regex or custom scanners. The Purple Llama license table places CodeShield under MIT, so the scanner code you would run for generated code carries the same permissive terms as the framework.
- Framework license: MIT for LlamaFirewall, per its README and LICENSE file.
- CodeShield license: MIT, per the Purple Llama license table, which also covers the evals and benchmarks.
- Regex and custom scanners: Your own rules and scanners are governed by your own licensing decisions.
- AlignmentCheck: It requires a Together API key, so it introduces a third-party service dependency that the MIT license does not cover.
- Version: The latest PyPI release is 1.0.3 at the time of research.
Check the LlamaFirewall LICENSE file against the version you pin, and confirm whether AlignmentCheck is in scope for your deployment before you approve it.
The code license does not transfer to the models. PromptGuard 2 and Llama Guard 4 are model weights distributed under the Llama 4 Community License Agreement, according to the LICENSE files in the Purple Llama repository. The Purple Llama README also notes that some earlier models, such as Llama Guard 3 and Prompt Guard, use the Llama 3.2 Community License. Each model you deploy therefore brings its own acceptable use policy, attribution and redistribution conditions, and those conditions can differ by model generation.
- PromptGuard 2: Ships under the Llama 4 Community License Agreement, in 86M and 22M parameter versions.
- Llama Guard 4: Ships under the Llama 4 Community License Agreement, as a 12-billion-parameter multimodal classifier.
- Earlier models: Llama Guard 3 and Prompt Guard use the Llama 3.2 Community License, so mixed versions mean mixed terms.
- Acceptable use: Confirm whether your intended use, region or user base triggers any restriction in the agreement.
- Redistribution: Check whether your packaging, image builds or internal distribution count as redistribution.
Have legal review confirm the Llama terms for your use, for each model version you plan to run, before any production rollout.
The supplied facts do not list any paid edition, enterprise license or commercial support tier for LLM Guard, LlamaFirewall or CodeShield. Their open licenses permit commercial use under their stated terms, but that does not mean a vendor offers contracted support, indemnity or service levels. Any commercial support you need would come from a third party, and its terms would be separate from the software licenses described on the other tabs.
- Editions: No paid edition appears in the supplied facts for any of the three components.
- Support: No vendor support contract is documented for the archived LLM Guard, and none is described for LlamaFirewall in the sources reviewed.
- Indemnity: Open licenses typically disclaim warranties, so ask who accepts responsibility for defects.
- Hosted services: AlignmentCheck depends on a Together API key, which is a separate commercial relationship.
Confirm with each vendor, in writing, whether any paid edition, support plan or hosted service exists, and record the answer in your procurement file.
What has no direct equivalent in LlamaFirewall
LlamaFirewall covers prompt injection, agent reasoning, generated code and custom regex rules. Several LLM Guard scanners sit outside that set, so the team that moves off LLM Guard must decide whether to rebuild each capability, source it from another tool, or accept the gap. The supplied facts do not confirm a LlamaFirewall equivalent for any card below, so check each one against the current LlamaFirewall documentation before you plan the switch.
Factual consistency checking
LLM Guard documents a factual consistency output scanner that compares a response against supplied context. LlamaFirewall's described scanners focus on prompt injection, agent alignment, insecure code and regex rules, and the supplied facts do not confirm a factual consistency check. If your application answers from documents, you need a grounding check somewhere in the response path. Confirm with the LlamaFirewall maintainers whether any scanner or custom scanner pattern covers this, and test it against your own answers before you rely on it.
Malicious URL detection
LLM Guard's Malicious URLs output scanner checks links in model responses before users click them. LlamaFirewall's documented scanners do not include a URL reputation check in the supplied facts. Teams that let models produce links in customer or employee channels need a replacement, such as a URL reputation service or allow-listing of domains, plus a decision on who maintains its threat data. Confirm the current LlamaFirewall scanner list before assuming a gap or a fit.
JSON and structure validation
The JSON output scanner in LLM Guard checks that responses are well-formed before a downstream system parses them. LlamaFirewall's CodeShield addresses generated code, not arbitrary structured output, so schema validation of model responses is not covered by the supplied facts. If your integrations expect JSON from an LLM, plan a schema validator in your application or in a validation library, and test malformed responses explicitly.
No-refusal detection
The No Refusal output scanner flags responses where the model declined a request, which matters for monitoring over-blocking and for spotting models that have been steered away from their policy. LlamaFirewall's described scope does not include a refusal classifier. Decide whether you need refusal rates as a signal, then build the classifier or log the signal in your own pipeline and confirm with LlamaFirewall whether it offers anything comparable.
Anonymize and deanonymize
LLM Guard's Anonymize input scanner and Deanonymize output scanner replace personal data before a prompt reaches the model and restore it in the response. This is a stateful pair that needs a mapping store that is protected like personal data. LlamaFirewall's documented components do not include this pair in the supplied facts. For regulated workloads, confirm the data flow, retention of the mapping table and how the restore step behaves on errors before you select a replacement.
Ban topics and token limits
LLM Guard's Ban Topics input scanner and Token Limit input scanner enforce business rules such as blocked subjects and maximum input size. LlamaFirewall's regex and custom scanners could approximate some keyword rules, but the supplied facts do not confirm topic classification or token budgets. Write these rules as explicit policy in your gateway or application, and test them against real traffic samples you control.
What drives the running cost of each path
PromptGuard 2 runs as a classifier inside your own infrastructure, so its running cost is compute you already pay for or will provision. The model card for Llama Prompt Guard 2 says the 22M version, based on DeBERTa-xsmall, cuts latency and compute costs by 75% with minimal performance trade-offs, and the 86M version is multilingual. The choice between the two sizes is therefore the largest lever on inference cost, and it recurs with every request your application sends through the scanner.
- Model size: The 22M variant is the cost-sensitive option cited in the model card; the 86M variant is the choice when multilingual coverage matters more than throughput.
- Request volume: Compute scales with the number of prompts scanned, including retries and agent loops that send more prompts per user action.
- Context length: The model has a 512-token context window, so long inputs need chunking, which multiplies the number of classifier calls.
- Hardware: Whether scanning runs on CPU or GPU, and whether it shares nodes with inference, changes the monthly bill more than the model choice alone.
Ask the vendor or your platform team to benchmark both sizes on a sample of your own traffic before you size the nodes, since the 75% figure comes from the model card, not your workload.
AlignmentCheck is the LlamaFirewall scanner that audits agent reasoning, and it requires a Together API key. That makes it a recurring, usage-based cost paid to a third party, separate from the infrastructure you run yourself. Unlike PromptGuard 2, you do not control its unit cost, so the cost model belongs in the procurement file as an external dependency rather than as a compute line.
- Usage-based billing: Confirm with the provider how calls are metered and priced for the model you select; DeployOpen does not set or estimate these rates.
- Call frequency: AlignmentCheck is most relevant to agents, so cost tracks agent steps and tool calls, not end-user messages.
- Key management: The key must be stored, rotated and scoped like any production secret, which adds a small recurring operational task.
- Data path: Calls leave your environment for the provider, which can affect data handling reviews and may need its own approval.
Ask for the provider's current pricing terms in writing, a per-workflow estimate built from your agent traces, and whether a self-hosted alternative to this scanner is supported in your version.
The largest one-time cost is usually the engineering work to rebuild scanners that LLM Guard provided and LlamaFirewall does not supply directly. LLM Guard documents 15 input scanners and 20 output scanners, and some of them, such as Anonymize, Secrets and Sensitive, have no one-to-one counterpart in LlamaFirewall's set of PromptGuard 2, CodeShield and regex or custom scanners. Each gap becomes a design, build and test task that your team or an implementation partner must scope.
- Inventory: List every LLM Guard scanner your application enables, then mark each as covered, partly covered or unmatched.
- Custom regex work: Regex or custom scanners are a supported extension point, but patterns for PII, secrets and business rules must be written, tuned and maintained by someone.
- Output behavior: Output scanners that check refusals, JSON structure or factual consistency need new logic or a different tool, which affects the response path.
- Testing: Rebuilt scanners need regression cases, so the test set is part of the build cost, not an afterthought.
Ask for the rebuild as a scoped work package with named deliverables, so that each unmatched scanner has an agreed acceptance test before work begins.
Switching scanners changes what the application blocks, so evaluation is a required cost that is easy to underestimate. Before cutover, you need a baseline of how the existing LLM Guard configuration behaves on representative prompts and responses, then a comparison against the new stack. This is one-time for the migration, but it recurs whenever you change a model, a threshold or a scanner set, so the test harness should outlive the project.
- Baseline capture: Record current block and allow decisions on a labeled sample of real traffic, handled under your data policies.
- False positives and negatives: Measure both, because a stricter scanner can break legitimate workflows while a looser one lets attacks through.
- Threshold tuning: Each scanner has settings that trade precision against recall, and tuning consumes engineer and reviewer time.
- Adversarial testing: Red team tools such as garak or promptfoo can generate attack sets, which adds tooling and analyst time.
Ask for the evaluation plan in the quote, including the sample size, who labels the data and which metrics define acceptance.
Upgrade effort is the recurring cost that the migration decision most directly changes. LLM Guard is archived and receives no security fixes, so keeping it in production shifts all future patching and model maintenance onto your team. LlamaFirewall is maintained, but its releases, model versions and license terms still need review. The Prompt Guard 2 model ships under the Llama 4 Community License Agreement, and LlamaFirewall itself is MIT licensed, so each upgrade includes a license check as well as a regression run.
- Archived versus maintained: The last LLM Guard release on PyPI is 0.3.16, uploaded on 19 May 2025, and it requires Python 3.10 or newer but below 3.13, which constrains your runtime upgrades.
- Model updates: Classifier and model changes require re-running the evaluation set, not just a package bump.
- Dependency pinning: Pin Python and package versions, and track the supported Python range for each component.
- Ownership: Decide who receives security advisories and who approves each upgrade.
Ask the provider or partner for its upgrade cadence, what a retainer covers, and how regression testing is run after each change.
How to plan the switch from LLM Guard to LlamaFirewall
This sequence moves LLM Guard's prompt and response scanning to LlamaFirewall without an unmonitored gap in protection. It ends with a scanner-by-scanner mapping, measured detection results from shadow traffic, and a retired LLM Guard deployment with a filed decision record.
Inventory every LLM Guard scanner in use
Platform and security engineers list each input and output scanner that runs in production, along with its settings, the application and request path it guards, and the team that owns its alerts. Count only what is configured and enforced, since LLM Guard documents a much larger scanner set than most deployments use. Export the configuration from the API server or Python code and check it against the running services, not the repository alone. The step is done when the inventory has one row per scanner per application and every row names an owner.
Map each scanner to a replacement or rebuild item
The security lead assigns each row one outcome. Prompt injection scanning maps to PromptGuard 2, which targets direct prompt injection and jailbreak attempts, so indirect injection through documents or tools needs its own test cases. Regex and custom checks carry over through LlamaFirewall's regex and custom scanner support, making them the main transfer path. Code-generation checks map to CodeShield, which covers 8 languages. Scanners such as Anonymize, Secrets, Ban Topics and Token Limit have no equivalent that we can confirm in the LlamaFirewall documentation, so each goes on a rebuild or keep-elsewhere list with an owner. The step is done when every row has exactly one outcome.
Install LlamaFirewall in a test environment
A platform engineer installs LlamaFirewall outside production with
pip install llamafirewallon Python 3.10 or later, and checks the installed version against 1.0.3, the latest release on PyPI. The team reviews the LlamaFirewall README and the demo for its agent framework, then decides whether to enable AlignmentCheck. That scanner requires a Together API key, so the team must confirm what data it sends and route the key through the same review as any other third-party processor. The step is done when a test prompt passes through PromptGuard 2, a regex scanner and a custom scanner and each returns the expected verdict in the logs.Run both stacks in shadow mode
Engineers replay recorded production traffic through LLM Guard and LlamaFirewall in parallel. LLM Guard keeps enforcing, while LlamaFirewall only logs its verdicts. Before recording, the team removes or masks personal data and secrets from stored prompts and responses, and confirms the retention period with the data owner. Each request should produce one paired record holding both verdicts, the scanner name and an input hash. The step is done when the paired log covers every scanner in the mapped inventory, including low-volume routes, so no path is missing from the comparison.
Compare detections and tune thresholds
Security engineers and application owners review every disagreement between the two stacks and label a sample from each side as a true or false detection. They adjust LlamaFirewall thresholds and regex or custom rules against that labeled set, then replay the traffic again to confirm the change does not reopen a gap. Results go into a table with false positives and missed detections for each scanner, and the owner signs off on the scanners that stay. The step is done when every mapped scanner has a documented result and every rebuild item has a test case that fails before the fix and passes after it.
Cut over enforcement in stages
The platform team moves blocking enforcement to LlamaFirewall one application or scanner group at a time, starting with routes that carry the lowest business impact and have the clearest test coverage. The LLM Guard configuration stays deployable during each stage so the team can roll back a single route without a full redeploy. Monitoring compares block rates and user-facing errors against the baseline recorded in shadow mode. The step is done when every route enforces through LlamaFirewall, a rollback has been rehearsed on at least one route, and the change log names the owner of each decision.
Retire LLM Guard and file the record
The platform team removes the LLM Guard packages, the API server deployment and its configuration from pipelines, and keeps the archived configs and paired shadow logs under the retention rules agreed in the shadow step. LLM Guard was archived and receives no security fixes, so the rollback window should close once enforcement is stable. The security lead files a short decision record covering the mapping, rebuild items, test results and open risks. The step is done when no request path imports LLM Guard, the deployment is removed from the inventory, and the record names every scanner that was dropped and why.
Questions buyers ask before switching LLM Guard scanners
Does LLM Guard still work after the archive, and what do security fixes mean now?
LLM Guard still runs in an existing deployment, but the project is no longer maintained, so it receives no security fixes. The repository was archived on 9 July 2026, and its README states that the project and its Hugging Face models are no longer under active development. The last PyPI release is 0.3.16, uploaded on 19 May 2025. That means any vulnerability found in its scanners or dependencies after the archive will not be patched upstream. Your team would need to absorb that risk, isolate the service, or plan a move. For new work, do not start a fresh LLM Guard rollout. Confirm with your security team how your current deployment is exposed and what compensating controls apply while you migrate.
How long does a guardrail scanner switch take, and what drives the timeline?
No duration is fixed by the sources for this migration, so the timeline depends on your own environment. The main drivers are the number of LLM Guard input and output scanners in use, how many applications call them, whether scanner results feed other logic such as redaction or logging, and how much of your test suite already covers prompt injection and output handling. Teams with one application and a few scanners usually face a smaller job than teams with several agents and custom scanner configurations. Ask any implementation partner for a written scope that lists each scanner, its replacement, the test cases and the rollout steps before agreeing a date.
Can our team replace LLM Guard scanners without outside help?
Yes, if your engineers can read the existing scanner configuration, rebuild the calls against the replacement libraries, and test the results. LlamaFirewall installs with pip install llamafirewall, needs Python 3.10 or later, and ships demos for OpenAI Agents and LangChain. The harder work is behavioral: deciding how each replacement scanner's verdict maps to your block, redact or allow decisions, and proving that you have not lost coverage. Teams without a red team or evaluation practice often benefit from outside help on that validation step. Consider whether your staff have the time to run that work alongside production duties.
What skills and staff time does the switch need from engineers and security teams?
Engineers need working knowledge of Python, of the LLM request path in your applications, and of how your current scanner calls are wired in. Security staff need to define the policy: which prompts and responses must be blocked, which must be redacted, and which must be logged. Both groups need to agree on test cases. Expect engineering time for code changes and integration tests, and security time for policy decisions and review of results. The exact effort depends on your scanner count and application count, so ask your team to inventory both before estimating hours.
Does AlignmentCheck in LlamaFirewall require a Together API key?
Yes. According to the LlamaFirewall README, the AlignmentCheck scanner requires a Together API key. AlignmentCheck audits agent reasoning, which LLM Guard does not offer as a direct equivalent. If you do not plan to use it, you can build a LlamaFirewall configuration without it, but confirm that choice against your agent threat model. If you do use it, add the key to your secrets management process, review where data is sent when the scanner runs, and check the terms that apply to that key with the provider and your legal team before sending production traffic.
Does PromptGuard 2 cover the same ground as LLM Guard's prompt injection scanner?
PromptGuard 2 covers a similar purpose, detecting direct prompt injection and jailbreak attempts, but it is not a drop-in replacement. Its model card describes two versions, 86M and 22M parameters, that label prompts as benign or malicious, with a 512-token context window. The 86M version is multilingual, and the 22M version is built on DeBERTa-xsmall and is described as cutting latency and compute by 75% with minimal performance trade-offs. LLM Guard's Prompt Injection scanner has its own thresholds and output format, so you must test both on your own prompts. Check the token limit against your longest inputs, and confirm the detection results on a sample of real traffic before you switch.
What does a fixed-scope DeployOpen engagement for this switch include?
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work starts. For a scanner switch, a written scope would normally list the scanners being replaced, the replacement components, integration into your applications, test coverage, documentation and handover. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so request a quote based on your written scope and ask what is one-time and what recurs.
Where LLM Guard to LlamaFirewall projects usually run long
The delays in an LLM Guard to LlamaFirewall move usually come from what the old deployment does without anyone having written it down. Undocumented scanner configurations are the most common source: thresholds, enabled input and output scanners, and the order they run in are often set in application code or an API server config that nobody has reviewed since the original rollout. Before any code changes, list every scanner in use, its settings, and the request path it sits on. Confirm with the team that owns each application whether a scanner was ever tuned for a specific false-positive problem, because that tuning will not carry over automatically.
Custom LLM Guard scanners are the second driver. LLM Guard's documented scanners do not map one to one onto LlamaFirewall, which centers on PromptGuard 2 for direct prompt injection, CodeShield for generated code and regex or custom scanners for pattern checks. Any in-house scanner class needs to be rewritten against LlamaFirewall's scanner interface, and its behavior needs to be retested. Regression testing of detection thresholds is the step most often underestimated. A prompt classifier with a different model and different scoring will flag a different set of inputs, so a written test set of known benign and known malicious prompts, drawn from your own traffic, should define acceptable results before cutover. If your agents call tools, the team also needs to decide whether AlignmentCheck is in scope, since it requires a Together API key and that dependency has its own approval and data-handling review.
Python version alignment closes the list. LlamaFirewall needs Python 3.10 or later, while the last LLM Guard release on PyPI, 0.3.16, requires Python 3.10 or newer but below 3.13. Teams pinned to an older interpreter or to a container image built around LLM Guard's dependencies may need to upgrade the runtime before the new scanners install cleanly. A DeployOpen scope for this work would typically cover an inventory of scanners and configurations, a rewrite plan for custom scanners, a threshold regression suite, a decision record for AlignmentCheck, and the runtime and dependency changes. The scope and deliverables are agreed in writing before work starts, and the timeline depends on that inventory, so ask for it to be completed first.
How DeployOpen helps plan and run the switch
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so the LLM Guard replacement runs where your applications already do. We scope the move from archived scanners to LlamaFirewall in writing first, then build, test, document and support it. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.
How we scope
- We inventory which LLM Guard input and output scanners your applications call today and map each to its LlamaFirewall or regex equivalent.
- The written scope names which scanners need a replacement, which need custom rules, and which will be retired with no direct equivalent.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any migration work starts, and a quote follows from that scope.
How we build
- We deploy LlamaFirewall in your environment and confirm the Python version and dependency set match your runtime before wiring it into request paths.
- We check whether AlignmentCheck is in scope, since it requires a Together API key and that dependency needs approval under your data handling rules.
- We test blocked and allowed prompt samples on both stacks side by side, so you can see where detection behavior changes before cutover.
How we hand over
- Handover includes configuration, scanner mappings and a record of every gap left open, so your team knows what the switch did not cover.
- We document how each guardrail is invoked, how results are logged, and which pipeline steps need updating when a scanner changes.
- Your team receives run procedures for rolling back to the previous scanner set if a new control misbehaves in production.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, which can cover tracking new LlamaFirewall releases on PyPI.
- A retainer can include periodic re-testing of prompt injection detection as your applications and models change over time.
- Ask any provider to confirm how LlamaFirewall updates will be tested in your environment before they reach production applications.
