NeMo Guardrails security hardening guide

Why NeMo Guardrails security hardening is harder than enabling the rails

Hardening a NeMo Guardrails deployment covers four things: the server endpoint, the model credentials it uses, adversarial testing of the rails, and logging of blocked requests for review. A team with NeMo Guardrails in front of an LLM has to show that all four hold up, and enabling rails addresses only part of that work. The library includes jailbreak and injection detection, but turning a detector on does not show that it blocks the attacks your organization cares about. Those attacks depend on your application, your users and the data behind it, so test cases should come from your own threat model and run against your own configuration.

The guardrails server is a network service, and it needs the same access controls as any other internal API. When NeMo Guardrails runs as an HTTP server that loads configurations from a folder, any client that can reach it can send prompts through your rails. Decide which services may call it, how those callers authenticate, which network paths can reach it, and who may change the configurations it loads. Confirm in the exact release you run whether the server includes built-in authentication, which options it supports and what they require. Do not assume a control exists simply because the server mode exists.

The rails sit on top of other calls, so a weakness in one place exposes others. Each request can reach the LLM provider, and depending on your configuration it may also call self-check moderation, fact-checking, or NVIDIA content safety and topic safety models. A leaked or over-permissioned credential therefore exposes the LLM account and every safety-model account the configuration uses, not only the guardrails. Inventory each outbound credential, where it is stored, who can read it, how it rotates and whether it appears in server logs or traces. Confirm with the release documentation how the server reads these values.

Hardening is also not a one-time task. Colang 1.0 is the default configuration language, and configuration changes between 0.x releases can alter how rails behave. In an illustrative case, a rail that blocked a test prompt before an upgrade may pass it afterward. Rerun the adversarial test set and the endpoint checks after every library upgrade, configuration edit or change to a safety model. Assign an owner for that retest and make it a gate in your change process before go-live. Finally, confirm what the release logs for blocked requests, which fields it records, and whether those logs contain user prompts that need the same protection as the endpoint.

Which parts of the stack need hardening

A NeMo Guardrails deployment is more than one library call. The server endpoint, configuration files, custom code, model credentials and container image each create a place where access can be abused or a rail can be bypassed. Review each component below against who can reach it, what it can call and what it stores before you test the rails themselves.

Guardrails server and Python API entry point

The guardrails server exposes an HTTP API that loads configurations from a folder, and the Python API can be called directly from application code. Ask who can reach the endpoint, whether it sits behind authentication and network controls, and whether any caller can choose which configuration is loaded. Confirm that the entry point is reachable only from the services that should call it.

The config.yml file

config.yml defines which models are called, which rails are active and which safety services are used. Ask who can edit it, how changes are reviewed and whether it can point to endpoints an attacker could redirect. Confirm that it is version controlled, that production copies match reviewed versions and that no secrets are embedded in it.

Colang files and their rail logic

Colang files define dialog flows and rail behavior, so a flawed flow can let a request skip the intended check. Ask which team writes and approves them and whether each of the five rail types (input, dialog, retrieval, execution and output) is tested for bypass paths. Confirm that Colang 1.0 or 2.x files have been reviewed after any conversion.

Optional Python actions

Python actions run custom code inside the guardrails process, and execution rails call them to reach tools and external systems. Ask what each action can read, write and call, and whether its inputs are validated before use. Confirm that actions run with least-privilege credentials and that their outputs are checked before reaching output rails.

LLM and safety-model credentials

The LLM provider keys and the credentials for self-check, content safety, topic safety and jailbreak detection models are used on every request. Ask where they are stored, which identity they belong to and how quickly they can be rotated. Confirm that they are injected at runtime from a secrets store, scoped to the models needed and absent from logs and images.

Optional LangChain integration

LangChain integration is opt-in and enabled with the NEMOGUARDRAILS_LLM_FRAMEWORK=langchain environment variable. Enabling it adds a framework whose dependencies and chains become part of your trust boundary. Confirm whether the setting is intended in each environment, that the dependency set is pinned and that the variable cannot be changed by a caller.

Docker image built from the Dockerfile

The Dockerfile provided with NeMo Guardrails builds a server image that bundles the library, configurations and dependencies. Ask which base image and Python version are used (the library supports Python 3.10 to 3.13), whether the container runs as a non-root user and whether the image is scanned before release. Confirm that configurations are mounted or baked in deliberately and that the image is rebuilt on each library update.

Which hardening choices fit your deployment

This table compares the main hardening decisions for a NeMo Guardrails deployment, with the situations where each option fits and the operational cost it carries. Read each row as a choice you make once and then maintain, and look for the failure mode that would matter most in your environment before choosing.

Decision	Option	When it fits	Operational cost and failure modes
Process placement	Library inside the existing application process	A single application team owns the LLM feature and wants rails to ship with its release cycle.	Rail upgrades and config changes require redeploying the application. A rail fault or memory spike can affect the host application.
Process placement	Separate guardrails server	Several applications share one set of rails, or a security team must change rails without touching application code.	One more service to run, monitor and scale. Every request gains a network hop, and an unavailable server must be handled explicitly (fail open or fail closed).
HTTP exposure	API reachable only on an internal network	The callers are internal services in the same network segment or cluster.	Relies on network policy and service identity being kept correct over time. Misconfigured routing can expose the endpoint more widely than intended.
HTTP exposure	API behind an API gateway	External or cross-team callers need authentication, rate limits and central logging.	Gateway policies, certificates and auth configuration need ongoing review. Gateway outages or timeouts block guarded traffic, so the gateway and rails need a shared timeout budget.
Provider key storage	Keys in a secrets manager	Keys must be rotated, scoped and audited, or the platform already runs a central secrets service.	Adds a retrieval dependency at startup and on rotation. Teams must confirm the server reads keys at runtime or restarts cleanly after rotation.
Provider key storage	Keys in environment variables	A small, short-lived or non-production deployment where the host is tightly controlled.	Keys appear in process listings, container specs and deployment logs if handled carelessly. Rotation usually means a redeploy, and key sprawl grows with each environment.
Packaging	Microservice container on Kubernetes with Helm	The team already operates Kubernetes and wants a vendor-maintained container image and chart to start from.	Chart values, image versions and cluster policies become part of the review scope. Confirm current image, chart and license terms with NVIDIA before adoption.
Packaging	Self-built container from the open-source library	The organization needs full control over base images, dependency pinning and build provenance.	Your team owns Dockerfile maintenance, dependency scanning and rebuilds after each Python or library update. Pin the NeMo Guardrails version and retest on every bump.
Framework integration	LangChain integration enabled	Your application chain already uses LangChain and the integration is required for the rails to work as designed.	Enabled through the NEMOGUARDRAILS_LLM_FRAMEWORK=langchain environment variable. Adds a dependency surface, so LangChain versions must be pinned and tested together.
Framework integration	LangChain integration left disabled	The application calls the library or server directly and does not need LangChain components.	Smaller dependency footprint and fewer version interactions. Confirm that no configuration silently depends on LangChain behavior before disabling it.
Detection approach	Built-in jailbreak and injection detection	You want a maintained starting point and can accept vendor-defined detection behavior.	Detection quality must be measured against your own prompts. Confirm model or service dependencies, added latency and cost with the current documentation.
Detection approach	Custom Python actions or third-party checks	Your threat model includes domain-specific abuse that generic detectors miss, or policy requires a specific external check.	Your team owns the code, its tests and its updates. Third-party checks add data-sharing and availability review. Failure handling in custom actions must be designed, not left to defaults.

How to harden a NeMo Guardrails deployment step by step

Hardening a NeMo Guardrails deployment is a fixed sequence in which each step narrows exposure or proves a control works before the next one starts. The steps cover inventory, version pinning, configuration control, endpoint access, credential handling, integration scope, rail testing and logging, and end with a recorded baseline that future upgrades can be compared against.

Inventory entry points and credentials
Platform and security leads list every way a request can reach the guardrails server, including HTTP routes, Python API callers and any framework adapters in use. They also list each credential the configuration uses, such as LLM provider keys and safety-model keys, and record where each one is stored today. This step is done when every entry point has a named owner and every config file that references a key is known. Check: a search of the configuration folder finds no key values that are missing from the inventory.
Pin Python and the release under review
Engineering pins the Python interpreter to one of the supported versions: 3.10, 3.11, 3.12 or 3.13. It also pins the nemoguardrails package to v0.24.1, the release this page covers, in a lock file or container base image so builds are reproducible. Behavior can change between 0.x releases, so the team should record the exact versions that passed testing. Check: a clean environment built from the lock file reports the pinned Python and package versions and installs without resolving newer packages.
Lock the configuration folder in version control
Engineering places the configuration folder, including config.yml, Colang files and any Python actions, under version control with review required for every change. Changes to rail behavior then appear as reviewed diffs instead of silent edits on the server. The team should confirm its own branch protection and signing requirements. Check: a test change to a Colang flow shows up in the diff, cannot reach the running server without a reviewed merge, and the server loads the folder from a commit the team can name.
Restrict who can reach the server endpoint
Network and platform engineers limit which networks, service accounts and gateways can reach the guardrails server port. They place the server behind an internal API gateway or private load balancer, disable any debug or administrative routes that production does not need, and confirm with the vendor or their own documentation which authentication options the server build supports. Check: a connection attempt from a host outside the approved list fails at the network layer, and an authenticated request from an approved client succeeds.
Move keys to a secrets store and rotate
Security and platform engineers move LLM provider keys and safety-model credentials out of configuration and environment files and into the organization's secrets store. The server then reads them at startup through the secrets mechanism the team confirms for its runtime. Engineers rotate one key in a non-production environment first to prove the procedure works before rotating production keys on a schedule. Check: a secret scan of the configuration folder and the container image finds no key values, and a rotated key works after a restart without any configuration edit.
Disable unused integrations and actions
Engineering reviews the configuration and disables any integration, custom action or model that no approved rail uses. Opt-in features such as the LangChain integration, which is enabled through the NEMOGUARDRAILS_LLM_FRAMEWORK=langchain environment variable, stay off unless a reviewed use case needs them. Each removal is recorded in the change log so the reason can be audited later. Check: the loaded configuration lists only approved integrations, and a test request that calls a removed action fails as expected.
Add and tune jailbreak and injection rails
Application security engineers add input and output rails for jailbreak and injection detection, along with any dialog or execution rails the use case requires. They run the regression suite of known attack prompts and benign prompts, then tune rail settings and order until attacks are blocked and legitimate requests still pass. Test results are stored with the commit that produced them. Check: the suite meets the pass criteria the team agreed in advance for blocked attack prompts and for benign prompts, and each tuning change appears as a reviewed commit.
Log blocks, scan the image, record baseline
Operations and security engineers configure request and block logging so each blocked prompt produces an entry with a timestamp and request identifier, handling prompt content according to the organization's data policy. They confirm what the server logs by default and add anything missing. Engineers then scan the container image and configuration folder with the team's scanners and record the configuration baseline: commit hash, image digest, Python and package versions, enabled rails and integrations. Check: a blocked test prompt produces a log entry that a reviewer can find by request identifier, the scan has no unaccepted high-severity findings, and the baseline matches the deployed image.

Access control, secrets and logging controls to put in place

A NeMo Guardrails server sits between your users and your LLM, so it holds provider credentials, sees user prompts and can run custom code. The cards below cover the controls that protect the HTTP endpoint, the model credentials, the configuration files, the outbound network path and the logs. Confirm each item against the release you run before you rely on it.

Restrict network access to the HTTP API

Limit which networks and hosts can reach the guardrails server port, using the firewall, security groups, Kubernetes network policies or load balancer rules your platform provides. Only the application tier that calls the guardrails should reach it, and administrative or debug access should stay off the public path. Check the exposed port and any bind address in your container or service definition.

Authenticate callers at the gateway

Place an API gateway or reverse proxy in front of the server and enforce caller authentication there, with your existing identity method and per-client credentials. Before relying on any built-in server-side authentication, confirm with the NeMo Guardrails documentation and the release you run whether it exists and how it is configured. Test that unauthenticated and expired-credential requests are rejected.

Separate provider credentials by environment

Give development, test and production their own LLM and safety-model API keys, and inject them at runtime from your secrets manager rather than baking them into images. Scope each key to the minimum models and spending limits its environment needs, so a leaked development key cannot reach production traffic. Document who can rotate each key and how a rotation reaches running servers.

Keep secrets out of configuration and Colang files

Keep config.yml and Colang files free of API keys, tokens and connection strings, and reference secrets through environment variables or your secrets store. Review these files in version control with a secret-scanning step, since rail definitions are often copied between projects. Treat any value that appears in a configuration folder as exposed to everyone who can read that folder.

Limit outbound egress to model endpoints

Allow the server to reach only the LLM, safety-model and fact-checking endpoints it actually uses, and block other outbound connections at the network layer. Egress rules narrow what a compromised server or malicious custom action can contact. Confirm the full list of endpoints each configured rail calls, including any third-party integrations, before writing the allow list.

Review custom Python actions as privileged code

Custom actions run as Python inside the server process with its network, file and credential access, so treat them like application code with server privileges. Require code review, pin dependencies, and remove any action that reads environment secrets or writes to disk without a clear need. Confirm which actions the configuration loads so that no unreviewed file is picked up from the configuration folder.

Log blocked requests for review

Record each blocked request with a timestamp, the rail that fired, the policy or reason code, a caller identifier and a request reference, so reviewers can reconstruct the decision. Store user text only where review requires it, mask or truncate personal data, and set a retention period that matches your privacy policy. Confirm what the release logs by default before adding any logging layer.

How to test that rails block jailbreaks and injection and fail safely

Testing a NeMo Guardrails deployment should answer one question before go-live: do the configured rails stop hostile input, and does the system fail closed when something it depends on breaks? A three-part test plan answers it. The first part is a regression suite of known jailbreak and prompt injection cases, mapped to each rail type your configuration uses. Map cases to input rails, dialog rails, retrieval rails for RAG chunks, execution rails for custom actions and tools, and output rails separately, so a failure points to a specific control in config.yml, its Colang files or its Python actions rather than to the application as a whole.

The second part is adversarial testing against the deployed endpoint, not only the Python API used in development. Test the HTTP interface your application actually calls, since that is where authentication, request limits and the configuration selected for each request take effect. Include indirect injection: instructions planted in documents returned by retrieval, and in text returned by tools or custom actions. These are the paths an attacker who cannot type into the chat box can still reach, so they need their own cases and their own expected outcomes. Use injected content that you write and own, and label the cases in your report as your own test material.

The third part covers failure behavior. Stop or misroute the safety-model service that backs any self-check or content safety rail, then confirm the request is refused or answered with the configured refusal rather than passed through unchecked. Send an invalid provider credential and confirm the error is handled without exposing details. Send malformed requests, oversized payloads and requests that name a configuration that does not exist. For each case, record the observed behavior and compare it to the intended fail-closed behavior in your design, which your team should write down before testing.

Define a pass in writing. A case passes when the request is blocked or answered with the configured refusal, the block is written to your log with enough context to review it, and no provider key appears in any response, log line or error message. Check logs and responses directly with a search for the key value and its prefix, because a key leaked into a stack trace is easy to miss. Jailbreak and injection detection in the library should be measured on your own prompts and data, with recorded false positive and false negative counts, rather than assumed from the library's documentation or from another team's results. Confirm with NVIDIA's documentation and release notes which detection models and versions your configuration depends on, since detection behavior can change between releases.

Rerun the full suite after every configuration change, every change to Colang or Python actions, every change to the safety-model or provider settings, and every library release, including the upgrade you made to the latest 0.x version. Treat the suite as a release gate, not a one-time report. If your team lacks capacity to build the adversarial corpus, run the failure tests, or review detection results with independent eyes, DeployOpen runs security testing of applications, APIs and AI systems as a separate engagement, and that work can cover this test plan. Scope, deliverables and timelines would be agreed in writing before testing starts.

How hardening changes by deployment model

A single-node deployment runs the guardrails server as one process on one host, usually behind a reverse proxy inside your network. Hardening is mostly host hardening plus careful handling of the configuration folder, because the rails, action files and model settings all live there.

Endpoint: Bind the HTTP server to a private interface and publish it only through a reverse proxy that terminates TLS and enforces authentication. Keep the server port closed to user networks.
Secrets: Load model and safety-model credentials from environment variables set by the service manager or from a host secret store. Keep keys out of config.yml and out of source control, and limit read access to the service account.
Egress: Allow outbound connections only to the model and safety-model endpoints listed in your configuration, enforced with host firewall rules or a forward proxy.
Logs: Write server and blocked-request logs to files, ship them to a central store with a log agent, and set retention in that store to the period your policy requires.
Image and patching: No container image is involved unless you choose to run one. Patch the operating system and the Python environment on a fixed schedule, and rebuild the virtual environment after each library upgrade.

Check that the service account cannot write to the production configuration folder and that the firewall rules match the endpoints named in your configuration.

What drives hardening effort and how to keep it down

This table lists the factors that change how much work a NeMo Guardrails security hardening engagement takes, why each one matters, and one practical way to reduce it. Read each row as a question to ask in a scope discussion, then check the quote against the drivers that apply to your deployment.

Driver	Why it raises effort	How to keep it down
Number of rails and custom actions	Each enabled input, dialog, retrieval, execution or output rail adds configuration to review, Python actions to threat model and test cases to write. Custom actions that call internal systems need their own access checks.	Enable a narrow set of rails that map to documented risks, and keep custom actions small and single-purpose so each one can be reviewed and tested separately.
LLM and safety-model providers and credentials	Every provider, including self-check moderation and content or topic safety models, needs a credential, a secret store path, rotation and a network path. Each one also widens the set of endpoints that must be tested for leakage and misuse.	Use one shared secrets pattern for all providers, with short-lived or scoped credentials, and limit each provider to the rails that actually call it.
Number of environments	Development, test, staging and production each need their own configuration, credentials, logging targets and test runs. Drift between them is a common source of rework during assessment.	Keep one versioned configuration set with environment-specific values injected at deploy time, and run the same regression suite in every environment.
Retrieval rails touching sensitive documents	When retrieval rails pass document chunks through the guardrail, access controls, data minimization and logging of retrieved content must be designed and tested. Chunk-level leakage and injection through documents add test scenarios.	Restrict the retrieval corpus to documents the calling user may already see, filter by metadata before retrieval, and avoid logging full chunk text by default.
Integration surface: LangChain, identity provider, log platform and SIEM	LangChain integration is opt-in and changes the runtime framework. Identity provider integration affects who can call the server and change configurations. Log and SIEM connections need schema decisions, delivery checks and access controls. Each integration adds a trust boundary.	Document each integration as a separate interface with its owner, data flows and failure behavior, and enable only the integrations the deployment needs.
Size of the adversarial test suite	Jailbreak and injection testing scales with the number of rails and languages in scope. Without a shared baseline, each rail or upgrade requires new test authoring and manual review of results.	Build a reusable test catalog grouped by rail and attack class, store it in version control, and run it automatically before each configuration change or upgrade.
Compliance evidence requirements	Assessors may ask for configuration history, test results, change approvals, blocked-request logs and proof of access control. Producing this evidence after the fact takes more effort than collecting it during the build.	Agree the evidence list before work starts, generate test reports and configuration diffs automatically, and map each control to a named artifact. Confirm the requirements with your assessor, since DeployOpen prepares evidence but does not issue audit reports or certifications.

What to monitor, back up and document after hardening

The ongoing work starts with four signals. Track blocked and allowed request rates per configuration, error rates from calls to safety models (self-check input and output moderation, jailbreak and injection detection, and any content safety models you enable), credential usage and rotation dates for the model provider keys the server holds, and outbound connections from the guardrails server. A sudden rise in blocks can indicate an attack or a rail that is too strict, while a rise in safety-model errors means you need to confirm whether your configuration fails open or fails closed. Unexpected egress deserves its own alert, because custom actions can call external services. Confirm with your platform team which metrics the server exposes in your deployment and which ones need a log pipeline or sidecar.

Back up everything that defines behavior in version control. That means the configuration folder with config.yml, every Colang file, the custom Python actions, prompt and model settings, and the Dockerfile or deployment manifests used to build the server. Route every change through a pull request that a second person reviews, and deploy only from the reviewed main branch. Keep secrets out of the repository. Store them in your secrets manager and record only their names, owners and locations. A repository alone does not describe the running system, so also record the image tag and the library version in use. Test the backup by rebuilding the server from the repository in a clean environment and running your test suite against it.

Re-run the adversarial suite before every upgrade. NeMo Guardrails releases in the 0.x series can change behavior, so treat a version bump as a change to the guardrails themselves, not only to the software beneath them. Run the jailbreak and injection cases, the dialog flows, and the retrieval and execution rail cases against the candidate version, then compare each blocked or allowed outcome with the baseline from the current version. Store results per version. Any changed outcome needs a written explanation that a reviewer accepts before rollout. Agree in advance who signs off, and which kinds of change stop a release. Version the test suite itself, so that a result can be reproduced later.

Logs of blocked requests need controls of their own. These logs often contain user prompts, which can include personal or confidential data, so restrict read access by role, name a review owner who triages entries and is accountable for follow-up, set retention in line with your data policy, and log who accessed the records. Keep a current set of documents alongside the system: the threat model, a rail inventory listing each rail, its type, the model or action it calls and its owner, the location of every secret, the log retention settings, and the test evidence for each version. Internal and external assessors will ask to see these documents first. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports or certifications, which independent auditors and certification bodies provide.

Questions teams ask before hardening NeMo Guardrails

How much effort does hardening a NeMo Guardrails deployment take?

Effort depends mostly on how many rails are in use, how many configurations the deployment serves, and how much of the protection relies on model calls rather than deterministic rules. A single input-rail configuration behind one endpoint is a much smaller job than a multi-tenant server with input, dialog, retrieval, execution and output rails. The main drivers are the attack surface of the endpoint, the number of custom actions that touch tools or data, the size of the jailbreak and injection test suite, and how many environments must be covered. No duration or fee is stated here. Ask any provider for a written scope that lists the rails, endpoints, actions and environments in play, the test categories planned, and the evidence each deliverable will produce.

Can an internal team harden NeMo Guardrails without a partner?

Yes, an internal team can do this if it has engineers who know the Python API or server, Colang, and the application's threat model, plus someone who can write adversarial tests and read logs. The work is not unusual for a platform team, but it is easy to underestimate in three places: securing the server and model credentials, building a jailbreak and injection test suite that is rerun on every change, and setting up review of blocked requests. Many teams find that the testing and logging parts compete with feature work. A useful self-check is whether someone can name the test cases that would fail if a rail were removed. If not, the team has a gap to close, whether internally or with a partner.

What does the work need from our team before it starts?

Plan on providing access and named people before any testing begins. The usual list includes read access to the guardrails configuration repository (config.yml, Colang files and Python actions), a non-production environment that matches the production server or container setup, and credentials for the LLM and any self-check, content safety or topic safety models the rails call. The team also needs a log platform where blocked and flagged requests can be inspected, and named owners for security decisions, application behavior and on-call response. Confirm in the quote who holds each credential, how test credentials are scoped and rotated, and whether production traffic may be used for replay or whether synthetic data is required.

Does using the library or the microservice change the hardening work?

Yes. The open-source library runs inside your application process or your own server, so hardening covers your code, your hosting, your secrets handling and your network path. NVIDIA also offers a NeMo Guardrails microservice, a production container image built on the same configuration model and deployed on Kubernetes with Helm. Its deployment hardening, such as cluster configuration, network policy, image provenance and secret injection, adds scope, while the rails logic and tests remain largely the same. Each rail that calls a model adds latency and cost per request, which affects test duration and load testing. Confirm which deployment model you run before requesting a quote, because the scope differs.

How often should we retest the rails?

Retest whenever something that affects rail behavior changes, and on a regular schedule even when nothing does. Triggers include changes to config.yml or Colang files, new or modified custom actions, a change to the underlying LLM or safety model, a new NeMo Guardrails release, a change to the Python version or container base image, and any new tool or data source connected to the application. NeMo Guardrails releases can change behavior between 0.x versions, so pin versions and rerun the regression suite before upgrading. Ask a provider whether retesting is included in the fixed-scope engagement or offered as an ongoing retainer, and what the retest scope covers in each case.

Once hardened, will the rails block every jailbreak?

No engagement can promise that. Rails reduce risk by filtering known patterns, applying deterministic rules and checking inputs and outputs with models, but jailbreak and prompt injection techniques keep changing, and model-based checks can miss or over-block requests. Hardening establishes a tested baseline: documented threat scenarios, a test suite covering input, dialog, retrieval, execution and output paths, measured results, and a process for logging and reviewing blocked requests. The honest deliverable is evidence of what was tested, what passed, what failed, and what remains open. Ask any provider to state the test categories and known limitations in writing, and to explain how residual risk will be tracked after go-live.

What should we ask for in a written quote?

Ask for the scope in terms your team can check: the deployment model (library or microservice), the list of rails and custom actions in scope, the endpoints and environments, and the threat scenarios to be tested. Request the deliverables by name, such as the hardened configuration, the regression test suite, the logging and review design, and the handover documentation. Confirm which inputs you must supply and by when, who pays for LLM and safety-model calls during testing, and what happens if scope changes. Ask whether ongoing retesting or upgrade support is priced separately, and whether any part of the work depends on a certification body or external auditor, which a provider cannot issue.

How DeployOpen scopes, hardens and hands over NeMo Guardrails security work

DeployOpen approaches NeMo Guardrails security hardening as a fixed-scope engagement, with the scope, deliverables and timelines agreed in writing before work starts. The work runs inside your own infrastructure, covering the server endpoint, model credentials, rail testing and blocked-request logging, and ends with documented handover to your team.

How we scope

Confirm whether you run the open-source library, the guardrails server or the NeMo Guardrails microservice, since each changes the attack surface.
Inventory which of the five rail types are active and which configuration files, Python actions and Colang versions your deployment uses.
Record the written scope, deliverables and timeline agreed before work starts, including which LLM and safety-model endpoints are in bounds.

How we build

Restrict access to the guardrails HTTP endpoint and place it behind your existing authentication and network controls.
Move model provider and safety-model credentials out of configuration files into your secrets management, and limit their scope.
Run jailbreak and injection test sets against input, dialog and output rails, then record which attacks pass through and fix the rails.

How we hand over

Deliver the hardened configuration, deployment settings and test suite so your engineers can rerun the rail tests themselves.
Document how blocked requests are logged, where the logs are stored, who reviews them and how sensitive content is handled in logs.
Walk your team through known residual risks, the rails that depend on third-party models, and the checks to repeat after changes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, which covers rail regression testing after NeMo Guardrails version changes.
Confirm with your team which release you are pinned to, since NVIDIA may change behavior between 0.x releases and you should review release notes before upgrading.
Agree in the written scope who owns rail updates, log review and re-testing after new attack patterns are published.