How do you keep LLM Guard support running after the archive?
An LLM Guard deployment that is already in production can keep running for now if it is pinned and isolated, but no new rollouts are recommended and a replacement date should be set before anything else changes. The protectai/llm-guard repository was archived by its owner on 9 July 2026, and the project's README states that the project and its associated models on Hugging Face are no longer under active development or maintained. Support work after that date is therefore about holding the current state steady, documenting it, and buying time for a planned move to a maintained guardrail.
Support work usually starts when something outside the application forces a decision. Common triggers include an audit request that asks which components and model versions are in use, a Python upgrade on the host, a security finding raised by a scanner or penetration test, and a planned platform change such as a new cluster, a new cloud account or a move to a different identity setup. Each of these can break an unpinned install, and none of them will be fixed upstream. Teams should expect that any fix will be their own.
The first practical constraint is the Python version. 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. Confirm the Python interpreter on every host, container image and CI runner that installs or runs the package, and record it alongside the exact package version. A host upgrade to Python 3.13 or later will stop the package from installing on that interpreter, so that upgrade should be scheduled together with the replacement plan, not after it.
Pinning also needs to cover the models. The Hugging Face models that LLM Guard downloads are not maintained either, so an unpinned model reference can change or disappear without notice. Record the exact model identifiers and revisions your deployment loads, store copies of the model artifacts in your own controlled storage where your licence and data terms allow, and check that a cold start in a clean environment still works. Also confirm whether your deployment runs LLM Guard as a Python library installed with pip or as an API server, because the pinning and rebuild steps differ.
Whether this work is done in-house or with a partner depends mostly on how many people already know the deployment and how quickly audit or security requests arrive. Teams with a small, well-documented install often handle pinning and rebuilds themselves. Teams with several environments, undocumented model loads or a pending audit often ask a partner to inventory the deployment and set up the pinned build. Any quote should list the environments in scope, the components to be pinned, the evidence to be produced and who owns the replacement date.
What LLM Guard support work includes
LLM Guard was archived on 9 July 2026, so the work centers on holding the current deployment steady while a replacement is planned. Each card below is a distinct piece of that work, and each ends in a document or setting the client keeps.
Environment inventory and version pinning
We record every host, container, API server and library instance that runs LLM Guard, along with the exact package version in each. The deliverable is an inventory register and a pinned lock file for each environment, so that a rebuild reproduces what is running today. Check that no environment installs the latest package by default, because an unpinned rebuild can silently change scanner behavior.
Python runtime and dependency control
The last PyPI release, 0.3.16, requires Python 3.10 or newer but below 3.13, which sets a hard ceiling for the runtime. We confirm the interpreter in each environment, freeze transitive dependencies, and identify packages that will need security scanning on their own schedule. The deliverable is a runtime specification and a dependency manifest. Confirm that your operating system image still ships a supported interpreter in the required range.
Model artifact pinning and local mirroring
Several LLM Guard scanners download models from Hugging Face at runtime, and those models are no longer maintained either. We pin each model to a specific revision, download the artifacts, verify their checksums, and host them in a local mirror that your environments read from. The deliverable is a model bill of materials with revisions and hashes. Confirm that the mirror is access-controlled and that no environment reaches the public hub unless it is explicitly allowed.
Configuration and scanner usage review
We review how each application calls LLM Guard, including which of the 15 documented input scanners and 20 documented output scanners are enabled, their thresholds, and their fail-open or fail-closed behavior. The deliverable is a scanner usage map that lists each enabled scanner, its purpose and its configuration. Check whether any scanner is enabled without a clear owner or a documented reason, since those are the first candidates for removal during migration.
Monitoring and rollback procedures
We set up alerts for scanner errors, timeouts, latency spikes and unusual block rates, and we document how to return to the last known-good package and model revision. The deliverable is a monitoring specification and a tested rollback runbook. Verify that a rollback has been executed in a non-production environment, because an untested rollback path often fails at the moment it is needed.
Interim state documentation and replacement timeline
We write down the current state of the deployment, the known limitations of the archived code, and the compensating controls in place, then agree a written replacement timeline with named owners and review dates. The deliverables are an interim state document and a replacement timeline. Confirm that the timeline is owned by a client role and that any fix to archived code is a local change, tested and owned by the client or the partner under written scope.
Why pinning LLM Guard versions and models matters
For an archived library, pinning is the first control you need. Pin the LLM Guard package to an exact version, which for the last PyPI release is 0.3.16 (uploaded 19 May 2025). Pin its transitive dependencies too, because LLM Guard relies on other Python packages that can change independently of it. Also pin the Python interpreter, which must be 3.10 or newer and below 3.13, and record the specific model files that scanners download from Hugging Face. Treat that full set as one versioned unit, and write it down before anything else changes.
An unpinned install can change behavior without anyone touching the code. A loose version range can resolve to a different release during a rebuild, and an updated transitive dependency can change how text is tokenized, matched or scored. A scanner can then start flagging different inputs or let different outputs through, and nothing in the application logs will say why. A missing model artifact causes a different failure. Scanners fetch their models when they start, so if a Hugging Face repository is moved, changed or removed, the scanner can fail at startup. Because neither the project nor its models are maintained, no upstream fix should be expected.
A local copy of the model files and a lock file make rebuilds reproducible. Mirror the model files you use into your own artifact store, record their checksums, and build container images from the lock file so the dependency set does not drift between builds. Then confirm the pinned set still works with your own tests. The LLM Guard README states that the project and its Hugging Face models are no longer under active development, so no one else will check that they still load and scan correctly on your platform. Test each scanner your deployment uses, including startup with network access blocked, and keep the results as evidence for the next review.
A Python upgrade on the host can make the environment unsupported even when the code still runs. An interpreter at 3.13 or newer falls outside the range the package declares, so a rebuild on a newer base image or an operating system upgrade can leave you running an unsupported combination. Fix the interpreter version in the image definition, block host upgrades from changing it, and check the version at deploy time. Before you change any pinned element, confirm the compatibility with the package metadata on PyPI and in your own test results, and plan the change as a tested release rather than an automatic update.
What drives LLM Guard support cost and effort
This table lists the factors that change how much work it takes to keep an existing LLM Guard deployment running after the archive. Each row names a driver, explains why it changes the work, and gives the control the reader can apply to keep it down. Deployment count, scanner selection and the form of integration usually matter most, so review those before asking for a quote.
| Driver | Why it changes the work | How to keep it down |
|---|---|---|
| Number of deployments and environments | Each deployment and environment needs its own pinned version, model set, test run and patch decision, so work multiplies across development, staging and production. | Standardize on one pinned release and one model set across environments, and promote the same artifacts rather than rebuilding them in each. |
| Enabled input scanners (of 15 documented) | Every enabled input scanner carries its own model dependencies and behavior, so each one adds models to mirror and cases to test after a pin. | Enable only the scanners your policy requires and document why each one is on. |
| Enabled output scanners (of 20 documented) | Output scanners such as Factual Consistency and Sensitive depend on models and text handling that change how responses are checked, so each adds test and review effort. | Turn off output scanners that duplicate controls elsewhere in the pipeline, and record which ones are required for each use case. |
| Library in applications or API server | A Python library is embedded in each application and upgraded with it, while an API server is a single service with its own endpoint, scaling and logging to maintain. | Pick one integration pattern per estate. A single API server usually means one upgrade path to manage. |
| Size of the regression test suite | After any pin or dependency change, the team must prove scanner decisions still match the expected results. A small or missing suite forces manual checks each time. | Build a fixed set of prompt and response cases with expected verdicts before the first pin change, and run it in the pipeline. |
| Locally mirrored models | LLM Guard relies on models that are no longer maintained on Hugging Face, so each model used must be copied into your own storage, checksummed and kept available offline. | Mirror only the models your enabled scanners load, and record their versions and hashes in one manifest. |
| Python version on the host | The last PyPI release requires Python 3.10 or newer but below 3.13, so the host interpreter limits OS images, base containers and security patches you can use. | Freeze the interpreter version in your base image and check it against the supported range before any OS upgrade. |
| Compliance evidence required | Assessors will ask for version records, change approvals, test results and model provenance for an unmaintained component, and each framework adds its own requests. | Keep a single evidence folder with pin records, test outputs and approvals, and confirm the format with your assessor early. |
| Number of teams calling the service | Each calling team has its own request formats, timeouts, error handling and change schedule, so every shared change needs coordination across them. | Publish one versioned interface contract and a change notice process, and give each team a named owner for compatibility testing. |
How a support engagement runs, phase by phase
The engagement moves from knowing what is running to a pinned, tested and documented state, then to a handover and a dated review of the replacement. Each phase closes with an artifact the client keeps, so the deployment stays supportable while a migration is planned. Timing for each phase is set in the written scope.
Inventory existing LLM Guard deployments
DeployOpen and your platform team list every place LLM Guard runs, including library imports in application code, API server instances, container images, CI jobs and the environments they serve. For each one, record the installed version, the enabled input and output scanners, the Hugging Face model identifiers they load and the named owner. The step is done when your team confirms the inventory accounts for every deployment. Output: a deployment inventory with scanner configuration per instance.
Audit interpreter and dependency versions
Check the Python interpreter each deployment uses against the range the last PyPI release supports, which is Python 3.10 or newer but below 3.13. Trace transitive dependencies, native libraries and model loaders, and flag any package that has drifted from the version the application was tested against or will not install on a supported interpreter. Output: a dependency and interpreter report listing each gap, its risk and the proposed fix. Confirm with your platform team whether any environment already runs outside this range.
Pin versions and mirror artifacts
Lock the LLM Guard release, its dependencies and the Hugging Face models each enabled scanner downloads to exact versions. Mirror the packages and model files into a registry or artifact store your organization controls, so builds and restarts no longer depend on upstream availability or on a repository that no longer changes. Record checksums for each artifact. Output: lockfiles, a mirrored artifact inventory with checksums and build instructions that resolve only from the mirror. Confirm the mirror location and retention with your security team.
Run regression tests on enabled scanners
Replay recorded prompts and model outputs through every enabled input and output scanner on the pinned build. Compare each scanner's decision and score with a baseline taken from production traffic or agreed test sets, and investigate any change in blocking, redaction or threshold behavior. Output: a regression report per scanner showing matched, changed and unexplained results, with the version of the test corpus recorded. Confirm with your application owners which prompts and outputs are approved for use as test data.
Prepare runbooks and rollback procedures
Write operating runbooks for the pinned deployment covering how to start, scale, restart and reload models, how to recognize scanner failure, and what to do when a model artifact is missing or a dependency fails. Define rollback to the previous pinned build and its mirrored artifacts, then rehearse it in a non-production environment. Output: a runbook set and a rollback record with the steps, owners and the evidence from the rehearsal. Confirm who on your side approves a rollback during an incident.
Hand over to your operations team
Walk your operations and security staff through the inventory, pinned artifacts, regression results, runbooks and rollback procedure, and transfer access to the mirror and deployment configuration. Your operators run a supervised restart or rollback drill so ownership is clear before the engagement moves to its next phase. Output: a handover record signed by the named owners, with open issues logged. Confirm which support arrangement applies after handover in the written scope.
Agree the review point for replacement
Hold a review with your leadership and platform owners to decide when the LLM Guard deployment will be replaced. Use the open issues, the security exposure and the status of any migration to a maintained guardrail as inputs. Record the decision, the scanners still in use and the conditions that would trigger an earlier review. Output: a written review record with an agreed date for the replacement decision. The replacement itself is planned and delivered as a separate migration engagement.
What usually goes wrong when LLM Guard runs unmaintained
LLM Guard was archived on 9 July 2026, so nothing in it will be fixed upstream. The failures below tend to arrive quietly, through routine changes that nobody checks, and each one has a prevention step that can be set up before the next incident.
Unpinned upgrades change scanner results
If the deployment installs LLM Guard without an exact version and dependency lock, a rebuild can pull a different release and change how scanners score prompts and outputs. Because the project no longer receives fixes, a change in results may never be explained by a vendor advisory. Prevention: pin the exact LLM Guard version and all transitive dependencies in a lock file, and rebuild only through a reviewed change.
Host Python upgrade breaks the install
The last PyPI release, 0.3.16, requires Python 3.10 or newer but below 3.13. An operating system or base image update that moves the host to Python 3.13 or later can stop the install or fail at import time. Prevention: pin the Python interpreter version in the container or virtual environment and block base image updates that move it past the supported range.
Model files disappear or change upstream
Several scanners download model weights from Hugging Face at runtime or on first use, and the models are no longer maintained alongside the code. A model may be removed, moved or replaced under the same name, which changes behavior or breaks startup. Prevention: mirror every model your scanners load into internal storage, record its checksum, and load only from that mirror.
Scanners tested only in development
Scanners often run in production with a configuration that was never exercised outside a developer's laptop, such as different input lengths, languages or traffic volumes. Failures under real load or unusual content then surface first in production. Prevention: replay production-like traffic through the exact scanner set and thresholds before any change reaches production, and keep that test set under version control.
False positives and negatives found after an incident
Without regular review, teams learn that a scanner missed a prompt injection or blocked legitimate content only after a user complaint or security event. Scanner thresholds and enabled scanners drift from what the business expects. Prevention: keep a labeled set of benign and adversarial examples, review block and allow counts on a fixed schedule, and record each threshold change with its reason.
Replacement date drifts without an owner
Because the project is archived, the planned move to a maintained guardrail such as NeMo Guardrails has no external deadline. Without a named owner and a dated plan, the replacement slips while the archived deployment stays in service. Prevention: assign one accountable owner, set a replacement target date in the risk register, and review progress at each change board.
Planning a replacement date for LLM Guard support
A pinned LLM Guard deployment needs a replacement date before anyone starts designing the replacement. The protectai/llm-guard repository was archived by its owner on 9 July 2026, and the README states that the project and its Hugging Face models are no longer under active development or maintained. Without a dated plan, support work drifts into an open-ended stopgap, and the deployment outlives the organization's tolerance for unpatched code. Start by naming one accountable owner, usually the product owner of the application that calls the scanners, with a security engineering counterpart. That person signs the plan, holds the date and reports slippage to the risk owner.
Next, list the events that should set the deadline. Business events include contract renewals for the application, a planned change to the model provider or the user population, and any product launch that depends on the guardrail. Audit events include the next assessment window for each framework the application is in scope for, and any finding that already cites the guardrail as a control. Ask your assessor which evidence they expect to see for a third-party component that is no longer maintained, because the answer may move the date earlier. Record each event with its date and the owner who confirmed it, so the deadline can be defended later.
Then decide how long the pinned deployment may run after the archive. This is a risk decision, not a technical one. Consider the Python version ceiling: the last PyPI release, 0.3.16 uploaded on 19 May 2025, requires Python 3.10 or newer but below 3.13, so the interpreter, base image and operating system each have their own support dates that may end before the guardrail is replaced. Confirm those dates with the platform teams. Set the maximum runtime only after you know which of these components will still receive security updates, and write the maximum down as a number of months agreed by the risk owner, not as an assumption.
Link every pinned component to an end date in one table. Cover the library version, the Python interpreter, the container base image, each scanner model, and any API server wrapper. For each row, record the end-of-support or end-of-use date, the decision that governs it, and the trigger that forces an earlier review, such as a published vulnerability in a dependency. A support task that cannot be tied to a row in this table is not a stopgap, and a row without an end date is a gap that the risk register must show.
Record the decision in the risk register as a single accepted risk with the end date, the owner, the compensating controls and the review cadence. The sibling page on LLM Guard security risks after archival covers the interim controls and the evidence to show auditors, so reference those controls here rather than repeating them. Schedule the migration to a maintained guardrail such as NeMo Guardrails from this plan, using the replacement date as the fixed point and working backward. The sibling page on migrating LLM Guard to a maintained guardrail covers the scanner mapping, gap testing and cutover, so treat its work as a dated project under this plan.
Recurring costs of keeping LLM Guard running
This table compares who pays for each cost of keeping an archived LLM Guard deployment running, whether the cost is one-time or recurring, and what pushes it up. Use it to build a cost model before you choose between in-house upkeep, a support retainer, and a planned replacement. DeployOpen does not publish prices, and a quote follows from the written scope.
| Cost item | Who pays | One-time or recurring | What drives it |
|---|---|---|---|
| Hosting for the API server or application runtime | Client, through its own cloud account or data center | Recurring | Instance count, traffic volume, model memory footprint and whether scanners run on CPU or GPU |
| Internal engineering time for monitoring and dependency checks | Client platform or security team | Recurring | Number of pinned Python packages, count of unmaintained dependencies with new advisories, and alerting coverage |
| Periodic regression testing after environment changes | Client, or DeployOpen if scoped as a project | Recurring when repeated after each OS, Python or model change | Number of enabled input and output scanners, changes to the Python runtime, and how many integrations call the API |
| Evidence collection for assessments | Client compliance and engineering staff | Recurring at each assessment cycle | Number of controls mapped to LLM Guard, auditor document requests and how current configuration records are kept |
| Support retainer, if the client chooses one | Client, under a written agreement with DeployOpen | Recurring under the agreed term | Scope of monitoring, response expectations, upgrade or patch work included, and scanner count |
| Cost of a future replacement | Client, including any DeployOpen migration project | One-time, but often planned as a series of phases | Number of scanners to map to a maintained guardrail, custom rules, test coverage gaps and cutover risk |
What you need to provide before LLM Guard support starts
Support starts only when DeployOpen can see exactly what is running today. Give us read access to the repositories that build your LLM Guard service, the deployment manifests (for example, container or orchestration definitions), and the host images or base images those workloads run on. 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. We need the images to confirm which Python interpreter and package versions are actually in use. If these artifacts are missing, we cannot confirm the deployed version, and any drift between the repository and the running container goes unnoticed until something breaks.
Next, provide the list of enabled scanners and their configuration. LLM Guard documents 15 input scanners and 20 output scanners, and each enabled scanner usually carries settings such as thresholds, allowed or banned lists, and redaction behavior. Those settings define what your application blocks today. Alongside them, supply sample prompts and outputs that reflect production traffic, with any sensitive content removed under your data handling rules. Support work depends on replaying this traffic to confirm that a patch or configuration change does not alter scanner decisions. Without a representative sample, the only check available is that the service starts, which does not show that it still blocks or flags what it should.
Third, confirm where the Hugging Face models are cached and give us access to those environments. The LLM Guard project and its associated models on Hugging Face are no longer maintained, so the model files on your hosts are now a fixed artifact. Tell us which model files and revisions are cached, which hosts hold them, and whether those hosts can reach Hugging Face at all. If the cache is inaccessible, a rebuild may pull a different model revision from the one you validated, or it may fail outright in a network without outbound access. Either outcome changes the scanner behavior that the earlier traffic sample was meant to test.
Fourth, name one owner each for the application, security and compliance. The application owner decides which scanners matter for the product and accepts functional changes. The security owner approves changes to controls and reviews residual risk while the archived code is still in use. The compliance owner decides what evidence the assessment needs. Also document the change window rules: permitted maintenance times, freeze periods, and the emergency change process. Without named owners, approvals stall, and a patch can sit waiting for a person who was never assigned to decide.
Finally, decide who signs off the replacement date before work begins. Migration to a maintained guardrail and the interim controls both depend on that date, so one accountable approver should own it and record it in writing. Confirm with your own governance team whether that approver is the CISO, the CIO or a delegated owner, and agree how any slip will be escalated. Scope and timing for each phase are agreed in writing once these inputs are in hand, so an unresolved sign-off decision is the most common reason a planned start moves.
Questions teams ask about LLM Guard support
How much does LLM Guard support cost?
The cost depends on the written scope, and DeployOpen does not publish a price list. The main drivers are the number of deployments, how many input and output scanners and which Hugging Face models are in use, whether LLM Guard runs as a Python library or an API server, the environment (cloud, data center or air-gapped), and how much pinning, testing and documentation the team needs. Initial stabilization work is one-time. A retainer for ongoing monitoring, patching and upgrades recurs. When you request a quote, ask for line items split into one-time and recurring work, the assumptions behind each item, and what the client team is expected to provide.
How long does LLM Guard support work take?
Duration depends on the scope, so no fixed timeline applies to every deployment. Work that is limited to pinning versions, freezing model files and documenting the current setup is shorter than work that also covers testing scanner behavior, moving to a new Python version or building a patch process. The number of environments and the availability of the client's reviewers also affect the schedule. No timing facts are provided here, so ask for a timeline in the written scope, with milestones, dependencies on client staff and the points where the client must approve changes before work continues.
Can our own team support LLM Guard without a partner?
Yes, provided three things are in place: version and model pinning, a regression test suite for the scanners you rely on, and a named owner for the deployment. Your team needs skills in Python packaging and virtual environments, container or API server operations, handling model files and their checksums, writing tests that check scanner decisions on your own prompts and outputs, and reviewing security changes. Because the upstream project no longer receives fixes, the owner must also approve every local change and keep a record of it. If any of these pieces is missing, a partner can help set them up before handing the work back.
Does LLM Guard support include fixing vulnerabilities in the archived code?
No. The upstream repository was archived on 9 July 2026, and its maintainers are not publishing fixes. Support works on a local-change model instead. When a defect or vulnerability is found, the client decides whether to accept a change, DeployOpen writes and tests a patch in the client's own copy of the code, and the change is recorded with its test results and the reason for it. The patched copy then becomes the version you run and maintain. Whether a specific fix is included depends on the written scope, so name the known issues and the review process in the scope document.
Can LLM Guard run on Python 3.13?
Not with the last release. LLM Guard 0.3.16 was uploaded to PyPI on 19 May 2025, and it requires Python 3.10 or newer but below 3.13. A deployment on Python 3.13 would need local changes to dependencies and code, followed by full regression testing of every scanner in use. Those changes become part of your local-change record and your ownership burden. If your platform team is moving to Python 3.13, plan that move as a separate work item, or keep LLM Guard on a supported Python version while you plan its replacement. Confirm the dependency versions in your own environment before you commit to a date.
Can a partner keep an LLM Guard deployment running until a replacement is live?
A partner can scope work to keep the existing deployment operating while a replacement is planned and built. In practice this covers pinning the package and model revisions, mirroring model files inside your environment, monitoring the service, applying the local changes you approve and keeping backups of the working configuration. It does not remove the underlying risk that the project is archived. Any availability commitment must appear in the written scope, along with the response process and the client's responsibilities. Ask how cutover to a maintained guardrail is handled, because the migration work is typically scoped separately.
What should we pin in an existing LLM Guard deployment?
Pin everything that changes the scanner's behavior, not only the package version. Record the LLM Guard version (0.3.16 is the last release on PyPI), the Python interpreter version, the full dependency lockfile, the container base image and the exact Hugging Face model revisions used by each scanner. Store copies of those model files in an internal artifact store with checksums, so a deployment does not depend on the external hub at startup. Keep the scanner configuration under version control and test it against a fixed set of prompts and outputs. Each pinned item should have an owner and a documented reason to change it.
How DeployOpen works on this
DeployOpen approaches LLM Guard support as a fixed-scope piece of work inside your own infrastructure. We start by inventorying what is running, then pin and document the versions, models and scanner settings in use. The aim is a stable deployment with a written plan for moving to a maintained guardrail.
How we scope
- The written scope lists every scanner, API server and Python environment in the deployment.
- It records the pinned release, the Hugging Face models each scanner loads and the Python version ceiling.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
How we build
- Pin the LLM Guard release, dependencies and model revisions so the deployment rebuilds the same way each time.
- Lock the Python runtime to the range the final release supports, which is 3.10 or newer but below 3.13.
- Test scanner behavior against recorded traffic samples before and after each change, in your environment.
How we hand over
- Documentation covers the build, the pinned versions, configuration, and how to restore from backup.
- A dated replacement plan names the scanners to map to a maintained guardrail such as NeMo Guardrails.
- Your team receives the runbooks and access needed to operate the deployment without us.
How we support
- Ongoing support is available as a retainer, scoped in writing like the original engagement.
- Retainers can cover upgrades, backups and testing of the replacement guardrail once it is in place.
- Ask in the quote which parts of the deployment sit outside the retainer.
