Why LLM guardrails in air-gapped networks need a different plan
If your assistant must run on a network where hosted moderation and classifier APIs are unreachable, the guardrails themselves become an offline system you build, transfer and maintain. The detection models, validator packages, policy files and update path all have to cross the boundary by controlled transfer, and each item needs an owner, a verification step and a record of what was imported. Plan that transfer as carefully as the guardrail design, because a guard that cannot be updated or verified will drift out of date without anyone noticing.
Both leading open-source options run self-hosted, so the platform choice is about policy style and validator sourcing rather than whether the software can run offline. NeMo Guardrails (Apache-2.0) defines rails in its config.yml, Python actions and Colang files, which suits teams that want dialog control and input and output rails written as one policy set. Guardrails AI (Apache-2.0) builds guards from validators installed from Guardrails Hub, which suits teams that want discrete, chainable checks such as regex or toxicity validators and structured output. Confirm with each project how its models and validators are fetched when no internet access is available, since that determines what you must stage in advance.
Before you choose, inventory every model file, validator package and dependency the guard needs, then record which version each one is and how you will verify its integrity before import. Ask your implementation partner how they will stage packages in an internal repository, how they will test a new detection release in a separate enclave, and how policy changes are approved and rolled back. Those answers will shape the rest of the design more than the choice of library alone.
Which requirements shape guardrails in an isolated network
This table maps the regulatory and network constraints that most often shape guardrail design in an isolated network to the build decisions they force. Read each row as a question to confirm with your compliance lead: whether the requirement applies depends on your sector, system classification and jurisdiction. The main takeaway is that the guard stack must work fully offline and must leave a local, verifiable record of every decision.
| Requirement | Source and scope | What it means for the build |
|---|---|---|
| Automatic event logging for high-risk systems | EU AI Act Article 12(1) requires automatic recording of events over the system's lifetime. Applies only if the system is classed as high-risk under the Act. | Log every blocked, modified or flagged request and response locally, with rail name, policy version and timestamp. |
| Minimum log retention | EU AI Act Article 19(1) requires providers to keep logs for at least six months unless other law provides otherwise. Confirm whether your sector sets longer periods. | Store guard logs in the enclave's own storage with retention set by policy, and confirm that the log store is included in backups. |
| Software integrity and authenticity of imported packages | NERC CIP-013-2 supply chain procurement controls, relevant to energy sector entities in scope. Other sectors often apply equivalent vendor verification duties. | Verify checksums and signatures for every validator package, classifier model and configuration file before it crosses the gap, and record the verification result. |
| Controlled remote access paths | NERC CIP-005-7 requires Interactive Remote Access to pass through an Intermediate System with encryption and multi-factor authentication. Applies to in-scope BES Cyber Systems. | Keep maintenance access to guard servers and model registries behind the approved access path, with no direct vendor sessions into the enclave. |
| No runtime calls to external moderation services | Constraint of the network itself. Hosted moderation APIs are unreachable from the enclave. | Run every classifier, toxicity and injection model locally, and fail closed or fail to a defined safe state when a local model is unavailable. |
| Offline model and rule updates | Operational constraint. Detection quality decays as attack patterns change, and updates arrive only through controlled media or transfer. | Define a transfer workflow with versioned bundles, a staging environment for regression tests and a rollback path for each guard version. |
| Change control for policies | Expected by most assessors for AI controls that affect outputs. Confirm the exact evidence format with your auditor. | Version Colang or config files and validator settings in source control, and tie each production policy to a reviewed, signed release. |
| Evidence of guard effectiveness | Assessors commonly ask how controls are tested. Confirm acceptance criteria with your compliance and risk owners. | Keep an offline red-team test set that runs against each new guard bundle before promotion, and store the results with the release record. |
Which guardrail platforms fit an air-gapped build
Four platforms cover most air-gapped guardrail designs: a rail framework, a validator framework, a gateway that enforces guard calls, and an alternative gateway. Each one depends on packages, models or telemetry settings that must be staged or checked before the network is cut off, so the selection is as much about what each platform fetches at runtime as about what it can detect.
NeMo Guardrails as the rail framework
NeMo Guardrails is Apache-2.0 licensed and defines input, dialog, retrieval, execution and output rails in Colang, configured through a config.yml file and optional Python actions. It can run as a Python library or as a guardrails server that loads configurations from a folder and exposes an HTTP API, and NVIDIA also offers a Helm-deployed microservice on Kubernetes. Its self-check, jailbreak and content safety models must be staged locally, and you should confirm which of them download weights or call external services on first use. Pin the library release, since the v0.24.1 release is the reference point for this page.
Guardrails AI as the validator framework
Guardrails AI is Apache-2.0 licensed and builds guards from validators published on Guardrails Hub, which are installed separately after the core package. In an air-gapped build, each validator package and its model assets must be mirrored into an internal index and checked before import. Confirm whether a validator fetches models or resources at runtime, and run guardrails configure with anonymous metrics reporting turned off, because the setup step asks whether to enable it. The library also generates structured output matched to Pydantic models, which helps when downstream systems expect fixed fields.
LiteLLM as the enforcing gateway
LiteLLM sits between applications and model endpoints, routing requests in OpenAI format and recording logs, keys and budgets, so it is a practical place to require that every request passes a guard call. It is MIT licensed except for its enterprise directory, which you should review before relying on any enterprise feature. Confirm that guardrail callbacks reach your internal guard services without an outbound route, that logging stores blocked prompts in your own storage, and that no provider or telemetry endpoint is referenced in the configuration.
Apache APISIX or Kong as alternative gateway
Apache APISIX and Kong Gateway are both Apache-2.0 licensed API gateways that also serve as AI gateways, and either can enforce authentication, rate limits and guard calls at the network edge. Choose one when the organization already runs it for API management, so guard enforcement sits in the same change process as other traffic policy. Confirm which AI plugins are included in the open-source distribution, since plugin availability varies by product and edition, and test that a blocked request is logged with enough context to support review.
How detection stays current without online updates
Detection content in an air-gapped guardrail stack goes stale unless it moves through a repeatable cycle. New validator packages, classifier model files and rule sets are downloaded in a connected staging zone, scanned for malware and known vulnerabilities, checked against published hashes or signatures, and then carried across the boundary through the approved media or data diode process. Each artifact should be recorded in a manifest that lists its version, source, hash and the person who approved the transfer. Inside the enclave, the same bundle is promoted through a test environment that replays representative prompts and outputs before anything reaches production. The organization owns this sequence, and the staging zone, transfer method and approvers should be agreed in writing before the first cycle.
The supplied versions are NeMo Guardrails v0.24.1, released on 16 September 2026, and Guardrails AI v0.11.0, released on 14 August 2026. Treat both as the baseline to re-pin on every cycle, not as a rolling dependency. Confirm the exact Python version, package set and validator versions in a lock file, and rebuild any guardrails server image from that lock. A fixed release calendar is a decision for your change board, based on how fast your risk owners need new detection and how much retesting your assessors expect. Vendors do not set that cadence for you. Colang 1.0 is the default configuration language, so teams on Colang 1.0 should not assume a move to Colang 2.x is a drop-in step. NVIDIA's migration tooling converts configurations, but its guidance says converted output still needs manual review, and that review belongs in the test environment before promotion.
Before you commit to a model update path, ask the vendor or project several questions in writing. Confirm whether the classifier models used by self-check moderation, jailbreak detection, topic safety and content safety are shipped as downloadable files, which versions and licenses apply to each, and whether they can be pinned and verified by hash. Confirm how Guardrails Hub validators are packaged for offline installation, and whether anonymous metrics reporting, which the Guardrails AI quickstart says is asked during guardrails configure, can be disabled in a closed network. Also confirm whether any hosted service call is required at runtime, since a library that silently phones home will fail an air-gap review.
Choosing a deployment pattern for isolated environments
In a fully disconnected enclave, nothing is reachable from outside the boundary during normal operation. Every guard model, classifier weight, validator package and policy file must be built or downloaded elsewhere, verified, and then carried in on approved media. The guard runtime, whether NeMo Guardrails or Guardrails AI, runs inside the enclave next to the application and the gateway, and it calls only local model endpoints. Detection quality is fixed at the time of import until the next approved transfer.
- Guard models: Self-check, content safety and jailbreak classifiers are hosted on enclave servers or GPUs and called over an internal address only.
- Logs: Blocked requests and guard decisions are written to an enclave log store that is also the system of record for audit evidence.
- Package entry: A mirror of Python packages, container images and model files is assembled outside, scanned, hashed and imported as a single signed batch.
- Updates: Rule and model refreshes follow the same import path, so every change has a dated transfer record.
- Before go-live: Test that the runtime starts with no outbound route, that a blocked prompt produces a log entry, and that a model file missing from the import fails closed.
Confirm with your security team which media and review steps the enclave accepts, because these set how quickly detection can be refreshed.
A partially connected enclave keeps a controlled path to outside sources, usually through a one-way transfer gate that moves files in only after inspection. Guard models still run inside the boundary, so user prompts and responses never leave it, but the team can pull fresh packages and model files more often. The gate becomes the most important control in this pattern, because it decides what enters and under which review.
- Guard models: Classifiers run locally on enclave hardware, and the gate only delivers their files and version manifests.
- Logs: Decisions are stored inside the enclave, with optional export of summarized metrics through a one-way diode or a reviewed outbound path.
- Package entry: Packages pass through the gate, where malware scanning, software bill of materials review and integrity checks against published hashes are recorded before release. The control behind this is the software integrity and authenticity verification described in NERC CIP-013-2 for other regulated sectors.
- Updates: Validator and rail releases arrive on a defined cadence, so the team can compare versions before promotion.
- Before go-live: Test that the gate rejects an unsigned or altered package, that the enclave cannot initiate outbound connections, and that a staged update can be rolled back.
Confirm with the gate operator how long a file takes to clear inspection, since that time sets the practical refresh rate for detection.
Some organizations already run an air-gapped platform that serves open-weight models locally with vLLM or Ollama, with an OpenAI-compatible endpoint that applications call. In this pattern, guardrails are added beside that inference service rather than built into a new environment. The guard models can reuse the same GPU pool and the same model registry, but they must be isolated in their own service so that a guard outage does not silently disable the model, and the reverse is also true.
- Guard models: Classifier models are served from the same local infrastructure, ideally as separate deployments with their own resource limits.
- Logs: Guard events are written to the existing platform log store, and inference logs are kept alongside them so that a blocked request can be traced to a model call.
- Package entry: Validator packages and model weights enter through the platform's existing import process, which should already record checksums.
- Updates: Model and rule versions are pinned in the gateway configuration so each change is tied to a deployment record.
- Before go-live: Test the failure mode when the guard service is down, confirm that the gateway denies requests rather than passing them unchecked, and verify that inference logs and guard logs share a request identifier.
Confirm whether the existing platform supports separate service accounts for the guard runtime, because shared credentials make the audit trail harder to read.
Rolling out guardrails in an isolated network, phase by phase
The sequence turns a guardrail design into a self-hosted, verified and documented service that keeps working without internet access, with each phase producing an artifact the next phase depends on.
Inventory required guards and models
The security architect and the application owner list every input and output check the assistant needs, such as prompt injection detection, PII screening, topic limits and output moderation. For each check, the team records whether it runs as a rule, a validator package or a self-hosted classifier model, and which model files it depends on. The output is a guard register that maps each risk to a rail or validator, a model file and an owner. Done means every guard has a named mechanism and no check depends on a hosted moderation API.
Build the offline mirror and bill of materials
The platform team pulls the NeMo Guardrails or Guardrails AI packages, their Python dependencies, validator packages, container images and model files on a connected staging host, then transfers them through the approved media process. They produce a bill of materials listing each artifact with its name, version, license and source location, and store a private package index and image registry inside the enclave. The output is a mirror that installs the full stack with no outbound connection. Confirm the licenses of every validator package before import, since Guardrails Hub validators are installed separately from the core library.
Verify integrity and record the import
A second reviewer checks each artifact against the bill of materials, comparing published checksums or signatures where the publisher provides them, and scans packages and images with tooling approved for the enclave. Any artifact that fails verification is quarantined and replaced from the source. The output is a signed import record that shows what crossed the boundary, when, who approved it and what checks it passed. This record supports supply chain evidence for the isolated network, including the software integrity expectations in NERC CIP-013-2 where that standard applies.
Stage the installation with a private registry
The platform team installs the guardrail service in a staging copy of the enclave before production. Where the guardrails run on Kubernetes, the team lists the required control plane and workload images in advance, pushes them to a private registry and points the cluster installer at that registry, so nodes never pull from a public source. They then deploy the NeMo Guardrails server image or the Guardrails AI service behind the AI gateway. The output is a working staging environment with a documented install runbook and a list of every outbound connection the team checked and found absent.
Configure policies in config.yml and Colang
The guardrail engineers write the rail configuration in config.yml, add any Python actions, and define dialog flows and checks in Colang, choosing the Colang version the team has tested and recording it in the configuration. They keep policies in version control, with each change linked to an approval and a test run. Converted or migrated Colang files need manual review, so the team reviews each converted file before it is used. The output is a versioned policy set that loads from the offline mirror and blocks the cases defined in the guard register.
Red-team guard coverage
An independent testing team, which may be DeployOpen or an internal group separate from the builders, runs prompt injection, jailbreak, data extraction and unsafe output tests against the staged guardrails. They measure which attacks the guards block, which pass, and how often legitimate requests are wrongly blocked on the organization's own sample data. The output is a coverage report that lists each risk, the test cases, the results and the open gaps with owners. Fixes return to the policy phase and the tests run again until the gaps are accepted in writing.
Validate logged decisions
The team confirms that every block, allow and redaction decision is written to the log store inside the enclave with the rule or validator that fired, the policy version, a timestamp and a reference to the request, without storing unnecessary personal data. They test log retention and access and check that the records can be exported for review. For high-risk systems under the EU AI Act, Article 12 and Article 19 set expectations for automatic event logs and their retention, so the team confirms these logs meet those expectations with counsel. The output is a log validation record signed by the service owner.
Document and rehearse the update procedure
The team writes a procedure for bringing new validators, model files and policy changes into the enclave through the same mirror, verification and staging steps used at first install. The procedure states who approves each import, how the bill of materials is updated, how a rollback works, and how the red-team suite is rerun after any change to detection logic. The team rehearses one update in staging before the first production change. The output is an approved update runbook and a dated bill of materials that becomes the baseline for the next import.
Questions teams ask before running guardrails offline
What drives the cost of an isolated guardrails build?
The main cost drivers are the engineering time to package and verify everything that crosses the gap, the compute for self-hosted classifier models, and the ongoing effort to tune policies and test them. Cost components are mostly labor and infrastructure: staff or a partner to build the bundle process, GPU or CPU capacity to run detection models, and recurring red-team testing. One-time work includes standing up the internal package mirror, model registry and configuration repository. Recurring work includes each refresh cycle, policy changes and regression testing. Ask any quote to break out these components, state which model sizes and hardware it assumes, and name who maintains the transfer process after go-live. No fixed figure applies to every environment, so the written scope is the only reliable basis for a number.
Can our own team run guardrails in an air-gapped network without outside help?
Often yes, if the team already operates Kubernetes or container platforms and has Python and security engineering skills, but the work is broader than installing a library. Your team needs to own the import path for validator packages and model files, the review step that checks each artifact before it crosses the boundary, policy authoring in Colang or validator configuration, and testing that blocks and passes behave as intended. Kubernetes can be built without internet access by pre-pulling images and pointing installs at a private registry, which shows the kind of offline preparation involved. Confirm internally whether you have people for each of these roles, because the gaps usually appear at the first model refresh rather than at installation.
What does the work need from our own staff?
Plan for named owners in four areas: platform operations, security engineering, AI or application engineering, and compliance. Platform operations runs the private registry, the model store and the guardrail servers. Security engineering reviews every imported artifact and owns the detection tests. Application engineers integrate the guardrails with the AI gateway and the language model endpoint. Compliance owns the evidence trail for guard decisions and logs. Each role needs enough time to handle scheduled refreshes, not only the initial build. Ask any partner to name which of these roles they fill, which they expect your staff to fill, and what knowledge transfer is included in the written scope.
How do we keep detection current without online updates?
You keep detection current through a controlled import cycle, not by letting the system fetch updates. Each cycle collects new validator versions, classifier model files, and rule or policy changes from an outside staging environment, scans and verifies them, then moves them across the gap into an internal registry. NeMo Guardrails releases, such as v0.24.1 published on September 16, 2026, and Guardrails AI releases, such as v0.11.0 published on August 14, 2026, show how often upstream versions change, so define the cadence in advance. Test each new version against your own prompt and response set before promoting it. Keep the previous version available for rollback. Confirm with your vendor how they publish release notes and checksums.
Can a hosted moderation API replace self-hosted guardrails in an isolated network?
No, a hosted moderation API cannot run where it is unreachable, so it cannot serve as the control in an isolated network. Hosted services also send prompts and outputs outside your boundary, which may conflict with your data handling rules. The practical substitute is a self-hosted classifier or rule set, which the NeMo Guardrails library supports through self-check moderation, jailbreak and injection detection, and content safety and topic safety models. Some of these models may require license acceptance or a download step, so confirm the license and model terms before planning the import. Also confirm how the classifier performs on your own data, because a model trained elsewhere may not match your language or domain.
How do guard logs support EU AI Act record-keeping duties?
For high-risk AI systems, Article 12(1) requires the system to technically allow automatic recording of events over its lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law says otherwise. Guardrail decisions, such as which input was blocked, which rail triggered, and which policy version applied, can be recorded as part of that event log. Store these records inside your network with retention and access controls set to your legal review. Whether your system is high-risk and which retention period applies to you are legal determinations, so confirm them with counsel before you design the log schema.
How do we confirm a validator does not call out at runtime?
Test it under the same network conditions as production, then verify it through several independent checks. Run the guard in a network segment with no outbound route, and monitor denied connection attempts at the firewall and egress proxy. Review the package for telemetry or network calls, since Guardrails AI asks during guardrails configure whether to enable anonymous metrics reporting, and that setting should be off. Confirm that models load from local paths and that the library does not attempt downloads at startup. Record the results as part of your release evidence and repeat the test after every import cycle. A check passed once does not cover later versions.
Evidence an auditor will ask for and which component produces it
This table maps each piece of evidence an assessor is likely to request for air-gapped guardrails to the requirement behind it and the component that produces it. Read it as a checklist to agree with your assessor early, since the evidence must be generated continuously rather than assembled before an audit. DeployOpen prepares this evidence, but auditors and certification bodies are the ones who assess it.
| Evidence item | Source requirement | Producing component |
|---|---|---|
| Package and model bill of materials with hashes | Software integrity and authenticity of vendor software, as addressed by NERC CIP-013-2 where it applies | Import pipeline manifest listing each validator package, classifier model file and version, with SHA-256 digests recorded at the import step |
| Transfer records across the air gap | Chain of custody for software and model files moved across the isolated boundary | Signed transfer log from the media scanning station, naming the approver, media identifier, dates and the checksums verified on arrival |
| Guard configuration under version control | Documented policy configuration and change control for each rail | Git repository holding config.yml, Colang files, Python actions and Guardrails AI guard definitions, with tagged releases tied to deployments |
| Blocked-request logs retained for the required period | EU AI Act Article 19(1) requires at least six months of logs unless other law applies (confirm longer periods with your regulator) | Self-hosted log store fed by the guardrail server or AI gateway, recording rail triggered, policy version and decision, with retention set to the longest applicable period |
| Red-team test results against guard rules | Evidence that guards were tested for prompt injection and leakage, as expected by many assessors | Test harness run on the isolated network with recorded prompts, expected outcomes, pass and fail results, and the policy version tested |
| Detection model and validator update records | Change management for security tooling, since offline updates are the main source of drift | Update register listing each new model or rule set, the approving owner, the test run before promotion and the rollback point |
| Evidence of how the classifier was validated | Accuracy and robustness documentation expected for high-risk AI obligations (confirm applicability to your system) | Evaluation reports from the self-hosted observability stack, with false positive and false negative samples reviewed by the owning team |
Questions to ask an implementation partner for an air-gapped guardrail build
Start with how the partner moves software across the gap. Ask who builds the transfer bundle, how each validator package, model file and rule set is pinned to a version, and how the partner verifies integrity and authenticity before import. Ask what goes into the transfer manifest (file hashes, source, signer, date and the person who approved the import), and whether the same bundle can be rebuilt and checked from a clean environment. Guardrails AI validators come from Guardrails Hub and NeMo Guardrails models are pulled from upstream sources, so ask the partner to show, for each, where it was obtained, what it depends on and how transitive dependencies were captured. Confirm the Python versions the chosen library supports, since NeMo Guardrails documents Python 3.10 through 3.13, and ask how the partner tests the bundle on a machine with no route to the internet before it is accepted.
Next, ask what the guard does when it cannot run. A classifier model that fails to load, a validator that throws an exception or a timeout in the gateway path each need an explicit rule. Ask the partner to state, for each rail, whether the request fails closed (blocked) or open (allowed with a log entry), and who approves that choice for high-risk flows. Ask how blocked and bypassed requests are logged, and how the AI gateway behaves if the guard service is down. For CIP-013-style procurement evidence, ask how each transfer is documented and retained, including who signed off, what was rejected and why. The partner should also be able to show a record for each controlled update, not only the first install.
Finally, ask what the partner will not claim. Ask for the false positive and false negative results on your own sample of prompts and outputs, the test set used, and how it was labeled. Ask which detection categories were tested offline and which were not, and whether the partner will state the coverage gaps in writing. Treat these as red flags: any guard that calls an external moderation or classifier endpoint at runtime, any update path that assumes online access, detection claims with no test data from your environment, and a refusal to name the rails or validators in the bill of materials. Ask the partner to confirm in writing that it will not represent detection accuracy it has not measured, and that it will hand over every model, rule and test artifact so your own team can rerun the evaluation.
Integration points that must work without the internet
An air-gapped guardrail stack is only as offline as its weakest connection. The AI gateway, guard runtime, model server, log store, identity provider and import staging zone each reach for something outside the enclosure unless someone has removed that dependency. Check each one before the first production request.
AI gateway
The gateway is the enforcement point where every prompt and response passes through the guard checks, so it must start and route without calling external endpoints. Confirm that the gateway image, its plugin packages and its provider configuration resolve from the internal registry, and that no telemetry or license check phones home. Apache APISIX and Kong are both Apache-2.0 and LiteLLM is MIT except its enterprise directory, so confirm which directories and features your deployment uses. Test a request with the outbound route blocked to confirm the gateway fails closed instead of passing traffic unchecked.
Guard runtime
NeMo Guardrails or Guardrails AI runs the input and output checks, and both load models or validators that are normally fetched at runtime. Guardrails AI validators come from Guardrails Hub and must be installed separately, so package them in advance and pin them in an internal index. NeMo Guardrails configurations depend on Colang files and optional Python actions that must be copied in with the release. Confirm the Apache-2.0 license terms for each package you carry across the gap and record the exact versions.
Model server
Classifier and safety models used for self-check moderation, jailbreak detection and topic safety need weight files on local storage before the enclosure is sealed. Confirm the model license for each file, since the code license of the guard library does not cover the weights. Check whether the serving engine, such as vLLM or Ollama, reaches a model hub at startup and disable that behavior. vLLM documents an offline docs option for air-gapped environments, so confirm its behavior against your version. Keep a copy of each model checksum in the staging record.
Log store
Every blocked prompt, redaction and guard decision needs a durable record, and that store must accept writes with no external sink. Confirm that tracing or evaluation platforms such as Langfuse or Phoenix are configured with local storage and no hosted callback. Note that Langfuse is MIT except its ee directories, and Phoenix is under the Elastic License 2.0, which bars offering it to third parties as a managed service. For high-risk systems, Article 19(1) of the EU AI Act requires providers to keep logs for at least six months unless other law provides otherwise, so size retention accordingly.
Identity provider
Operators and reviewers who change policies or read blocked-request logs authenticate against an identity provider, and that provider must run inside the enclosure. Confirm that its metadata, signing keys and login flows do not depend on a public discovery endpoint or a hosted certificate service. Check that group claims map to policy-editing roles, since a guardrail policy change is a production change. Many identity products also offer air-gapped features under paid editions, so verify the edition and its license before you deploy.
Import staging zone
Validator packages, model files and container images enter the enclosure through a staging zone that has access to the public internet on one side and the isolated network on the other. Treat this zone as the control point for CIP-013-style integrity checks: verify checksums and signatures, record the source and license of each item, and scan it before release. Kubernetes clusters can be built offline by pulling control plane images in advance with kubeadm config images pull and pointing kubeadm init at a private registry through its image repository flag. Confirm the same pattern for every image in the guard stack.
How DeployOpen scopes and supports air-gapped guardrails
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and that includes air-gapped networks where the guardrail stack, its classifier models and its validator packages all have to run without an internet connection. Most engagements are fixed-scope, which means the scope, the deliverables and the timelines are agreed in writing before work starts. For an air-gapped guardrail project, that written scope should name the rails or validators in use, the models and packages to be carried across the boundary, the AI gateway that enforces the policies, the logging destination, and the transfer procedure that the client's security team has approved.
Testing is a separate deliverable from the build. DeployOpen runs security testing that includes AI systems and agents, so red-team exercises against the guards are available as part of the scope. Ask for test results that show which prompt injection, data leakage and unsafe output cases were attempted, which were blocked, and which passed through, along with a plan for rerunning the same cases after each policy or model change. Confirm with the partner whether testing runs inside the isolated network or against a copy, because that decides who can see the test prompts and where the results are stored.
Ongoing work after handover, such as applying transferred updates, tuning policies after new attack patterns appear, upgrading NeMo Guardrails or Guardrails AI, and keeping gateway and logging components current, is available as a retainer. Agree the response expectations and the update cadence in writing before go-live. DeployOpen prepares systems, controls and documentation for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so the evidence package should be built to what your assessor will ask for, and that conversation should happen early.
