The Short Answer
ibl.ai deploys NemoClaw-sandboxed agents with NVIDIA NeMo Guardrails as two separate layers inside your perimeter: OpenShell limits what an agent can reach, and the rails check model traffic. The Agentic OS governs who reaches which agent, the stack is model-agnostic, and you own all the code and the data.
The two names suggest one product, and they are not one. NemoClaw is NVIDIA's open-source reference stack for running agents in OpenShell sandboxes. NeMo Guardrails is a separate Python library, with its own release line, at version 0.24.1 as of this writing.
Neither NVIDIA's March 2026 NemoClaw announcement, its documentation overview, nor its repository README mentions NeMo Guardrails.
Combining them is a deployment decision, and it is what ibl.ai's NemoClaw service scopes. This post extends our earlier look at why organizations need to own the sandbox.
What does NemoClaw's sandbox protect, and what does it leave out?
NemoClaw's sandbox protects the infrastructure layer: where an agent can go, and what it can touch. NVIDIA's security documentation lists sandbox isolation, network policy, filesystem restrictions, SSRF validation and credential handling on its side of the line.
Underneath, OpenShell uses Landlock to confine filesystem access and seccomp to restrict process behaviour. Network policy can be reloaded while the agent runs. The filesystem and process layers are locked when the sandbox is created.
NVIDIA's September 2026 Open Agent Safety Platform says enterprises "need an enforceable boundary outside of the model and agent harness," and that OpenShell "provides a secure runtime boundary." That is the sandbox's job: governing behaviour from outside the agent.
The NemoClaw overview adds two properties worth keeping. Requests to unapproved destinations are blocked and surfaced for operator review, and provider credentials stay outside the sandbox.
The same security documentation is just as clear about the other side.
For OpenClaw, nine categories sit at the application layer, where NemoClaw adds no protection of its own, including prompt injection defenses, tool access control and messaging access policy.
OpenClaw's own controls in that layer include more than 50 automated configuration and posture checks through openclaw security audit.
What do NVIDIA NeMo Guardrails add to a sandboxed agent?
NeMo Guardrails adds checks on content in model traffic. A network policy decides where an agent may connect, not what it says, so a permitted model call can still carry a jailbreak in or a Social Security number out.
The library defines five rail types, each running at a different point in an LLM interaction.
| Rail | Where it runs | Typical use in a deployment |
|---|---|---|
| Input | Before the model sees user input | Jailbreak detection, PII masking, rejecting a request |
| Dialog | While the conversation is steered | Required confirmations, scripted flows |
| Retrieval | On chunks retrieved for RAG | Dropping or altering a chunk before it enters the prompt |
| Execution | On inputs and outputs of custom actions | Actions run by the Guardrails runtime. Tools run by the agent harness need tool-call and tool-result rails instead |
| Output | Before a response reaches the user | Blocking or altering the response |
Rails are written in YAML and Colang, which means they can sit in version control and be reviewed like any other policy. The library is Apache 2.0 licensed, so nothing about the rails themselves depends on a vendor's hosted service.
How does jailbreak defense work with NeMo Guardrails?
Jailbreak defense with NeMo Guardrails is an input rail, and the documentation offers four routes: an LLM self-check, heuristic pattern matching, the NVIDIA NemoGuard Jailbreak Detection NIM, and third-party integrations such as Prompt Security and Pangea AI Guard.
Detection is probabilistic, so treat it as one layer and not as a guarantee. NVIDIA's own README says the built-in guardrails "may or may not be suitable for a given production use case." Each rail should be tested against your own traffic before it is relied on.
The sandbox is what limits the damage when a jailbreak gets through. A compromised agent that cannot reach an unapproved host, or read a file outside its declared paths, has much less to work with.
How does PII redaction work in a NemoClaw deployment?
PII redaction belongs in a content layer, because a network policy decides destinations and not what a message says. OpenShell can call supervisor middleware you supply to inspect traffic, but you still have to bring the detection.
NeMo Guardrails can block content containing PII or mask the entities before processing, through integrations such as NVIDIA GLiNER-PII and Microsoft Presidio.
For agents built on the Agentic OS, ibl.ai's platform also ships its own Privacy settings per agent: Redact, Mask or Block across entity types such as Person, Email, Phone and SSN, applied before the model sees the text, with an optional second pass on responses.
Two checks are worth making in any deployment. Pick the detection engine deliberately, because recall varies by entity type and language. And run it locally, so the check for sensitive data does not itself send that data to an outside endpoint.
Where do RBAC and audit logging live in this stack?
RBAC and organization-wide audit live above the sandbox, because NemoClaw is not built to carry them for an organization.
NVIDIA describes it as "an early-preview reference stack for a trusted operator on one host," and says it is not a multi-tenant enterprise control plane.
That is a fair scoping statement, and it marks where the deployment work sits.
In an ibl.ai deployment, the Agentic OS governs who can reach which agent through role-based access and records platform activity in audit logs. Sandbox-level events come from OpenShell's own logs.
Agentic OS workflows can add checks of their own. The workflow Guardrails node adds PII Detection, Moderation, Jailbreak Detection and a hallucination check at a specific point in a run, so different steps can carry different checks.
How should network isolation be configured for guardrailed agents?
Network isolation should be configured so the rails sit on the only path to the model. NemoClaw supports an Other OpenAI-compatible endpoint for inference, and the NeMo Guardrails server exposes a chat endpoint compatible with the OpenAI API.
Placed that way, the rails see model traffic while OpenShell policy can block direct routes around them.
The agent reaches a guardrails endpoint inside your network, and that endpoint reaches a model you chose. NVIDIA's provider guidance cautions that behavior on proxies and gateways may vary, so this route has to be validated in each deployment.
This design covers model traffic only. Tool execution and calls to allowed hosts are outside the rails, so those need tool-result rails, middleware or tighter egress.
The guardrails server also restricts tool-calling requests when dialog flows are configured, so which rails apply has to be scoped per deployment.
The same reasoning applies to the checks themselves. Self-check rails call an LLM, so point them at a model inside your boundary. NVIDIA's README also says its hosted Build endpoint "must not be used in production environments."
What do you own when ibl.ai deploys NemoClaw with NeMo Guardrails?
You own the policies and deployment code, and you run NemoClaw and NeMo Guardrails under their Apache 2.0 licenses. ibl.ai delivers the Colang rail definitions, agent configurations and infrastructure code into your repositories, as listed on the service page.
The ibl.ai platform arrives as full source code under a perpetual license. The platform already runs for 1.6M+ users across 400+ organizations, and Syracuse University runs ibl.ai on its own Google Cloud.
ibl.ai is family-owned and operated from New York, and our engineers work alongside your team through the deployment. If you are choosing between this model and a hosted assistant, NemoClaw vs. custom GPTs sets out the trade-offs.