Open Guardrails, Verifiable Authority: How EVE Extends NeMo Guardrails 0.24

On the NeMo Guardrails 0.24.0 release, NVIDIA gave rails an engine-neutral verdict type. A rail no longer just raises or returns a loosely-shaped result — it returns a RailOutcome carrying one of three mutually exclusive decisions: ALLOW, BLOCK, or TRANSFORM. The type carries the decision and neutral evidence, and deliberately leaves rendering — which exception, which refusal message, which language — to the engine consuming it.

That is a good piece of API design, and it is more consequential than it first appears. An explicit, engine-neutral outcome is exactly what an external system needs in order to consume a guardrail verdict as data rather than as a side effect. It makes open guardrails composable.

So we composed with it. This post describes what EVE now implements against the real NeMo Guardrails 0.24.0 runtime, what it deliberately refuses to do, and what was actually executed to prove it.

What changed in NeMo Guardrails 0.24

The relevant addition is nemoguardrails.actions.rail_outcome.RailOutcome. Three things about it matter for interoperability:

• The decision is explicit and closed. ALLOW, BLOCK, TRANSFORM — and the type enforces that a transform payload is present if and only if the decision is TRANSFORM.
• Transforms name their target. A rewrite declares which conversation variable it rewrites: the user message, the bot message, or the retrieved chunks.
• Failure is distinguishable from refusal. A failed flag marks a BLOCK that the engine synthesized because a rail raised rather than decided.

That third property is the one most integrations get wrong, and it is the one we built around most carefully.

An external ALLOW is a signal, not authority

Here is the distinction that governs the entire integration.

When a guardrail returns ALLOW, it is reporting that its detectors found nothing. That is genuinely useful information. It is not a statement that a $50,000 wire transfer is permitted for this tenant under this policy version by this role. Those are different questions, and conflating them is how a content filter quietly becomes an authorization system that nobody designed, reviewed, or can audit.

So EVE's precedence rules are deliberately asymmetric. A rail is trusted to add restriction and never to remove it:

1. A CoreGuard BLOCK is final. No external outcome can lift it. This is evaluated before the mode check, so no configuration — not even switching rails off — routes around it.
2. An external BLOCK can force a block.
3. An external TRANSFORM rewrites content, and only content.
4. An external ALLOW is inert. It leaves the CoreGuard verdict exactly as it was.
5. Anything else — timeout, malformed result, unsupported version, changed configuration — fails closed.

The property that ties these together is that combining a CoreGuard verdict with a rail outcome must never reduce restriction. That is not left as a design intention; it is asserted directly and swept across the full matrix of enforcement mode, rail decision, failure mode and CoreGuard verdict in the test suite.

Why a timeout must never become an ALLOW

NeMo's failed flag maps onto a distinction EVE treats as load-bearing: did the rail decide, or did the rail break?

EVE classifies eight failure modes — the rail raised, timeout, backend unavailable, malformed result, unknown outcome, unsupported engine version, configuration changed after load, and not configured — as integration failures rather than policy decisions. In enforce mode all of them block. In shadow mode none of them do.

The reason to keep them separate rather than simply blocking is attribution. A blocked request that reads “the policy refused this” when the truth is “the guardrail backend was unreachable” sends an operator to the wrong place, and pollutes the record an auditor will later read. The signed evidence records which of the two it was.

It also closes a specific failure pattern: an integration that returns a permissive default when its backend is degraded. In EVE, a retryable infrastructure failure never becomes an executable ALLOW.

Transform: binding what was sent, not what was asked

TRANSFORM is where evidence gets interesting, because after a rewrite the content the model received is no longer the content that was submitted. An evidence record that binds only one of them proves very little.

EVE binds both. The signed payload carries the digest of the original content and the digest of the transformed content, together with the engine name, its exact resolved version, and a digest of the rail configuration that produced the rewrite. Alter either digest and the content hash no longer matches, so offline verification fails.

Several rules fall out of taking that binding seriously:

• An empty or whitespace-only transformation fails closed rather than silently passing the original through.
• A transform that carries no rewrite for the leg being governed fails closed — a bot-message rewrite cannot quietly rewrite the request.
• A transform rewrites content only. Tenant, provider, model, operation, policy and endpoint are supplied by the caller and are never read from a rail result.
• A transform whose two digests are identical is rejected as inconsistent, because it would demonstrate nothing.

Tool-call guardrails are not tool-execution authorization

NeMo 0.24 ships tool-call and tool-result rails. They can inspect a tool call against a declared toolset and block it. They cannot authorize it, and EVE does not pretend otherwise.

EVE claims execution authority only when it receives the complete structured action and runs its existing chain: signed decision certificate, execution token, durable single-use redemption, provider recheck. Where the transport carries only message text — a chat completion, for instance — the honest status is NOT_APPLICABLE_TO_THIS_TRANSPORT, and that is what EVE reports.

Where a complete structured action is present, EVE binds a digest of it and routes it to that chain. A rail may block along the way. It never authorizes, on any transport, for any action shape.

What was actually executed

Everything above was run against the real nemoguardrails==0.24.0 package — not a mock, not a fixture, not a vendored copy. The rail configuration used in the integration tests is model-free, so the engine runs deterministically with zero model calls.

• 29 integration tests against the real 0.24.0 runtime, covering genuine ALLOW and BLOCK decisions through LLMRails.check, and genuine RailOutcome objects for allow, block, transform and failure.
• 297 precedence and evidence tests, including a full sweep asserting that combining never relaxes restriction.
• 16 pipeline tests proving the feature is inert when disabled.
• 24 capability-manifest tests that refuse over-claims.
• 104 pre-existing model-routing tests, still passing.

A runnable demonstration exercises the whole loop with a provider that counts its own invocations, so “the provider was never called” is a measured fact rather than an assertion. All 41 of its checks pass: a NeMo BLOCK records zero provider calls; an external ALLOW against a CoreGuard BLOCK records zero provider calls; a TRANSFORM records exactly one call carrying only the redacted text; a simulated backend outage records zero. The resulting certificate is signed by the same EVE signer that signs every other decision, verifies offline against its published public key, and is rejected when any bound field — including the rail digests — is tampered with. No governed plaintext appears anywhere in it.

Claims we are not making

A post about verifiable evidence should be precise about its own status.

• This integration is implemented and tested, and it is not deployed. It ships behind a feature flag that is off by default. Enabling the flag alone cannot block traffic: the mode defaults to shadow, and enforcement requires a second explicit interlock. No production canary has been run.
• EVE is not FISMA-certified, holds no FedRAMP authorization, and holds no Authority to Operate. We publish an engineering mapping to NIST SP 800-53 Rev 5 as an input to a customer's evidence package. An ATO is granted to a system by an Authorizing Official, never to a component by its vendor.
• There is no Cisco AI Defense integration. We looked for a stable, documented, testable public API and did not find one we could build against and verify without a commercial tenant. Reverse-engineering a private API was out of scope, and shipping an untested integration would have been an over-claim.
• There is no official Arthur integration. EVE exports rail decisions as privacy-safe governance events over its generic OpenTelemetry surface — decision id, hashed tenant, policy, outcome, reason code and digests, never governed content. That exporter is tested, but it has never been run against Arthur’s ingest or any other vendor’s. Generic OTEL compatibility is not vendor-tested interoperability, and we label it as generic.
• A customer-controlled deployment profile is documented, not shipped. The published gap assessment names the largest gap plainly: there is no egress-control mechanism yet. It also records something we think buyers should hear more often — a remote guardrail backend is fundamentally incompatible with a strict data-boundary claim, because the content leaves the boundary to be inspected. In a sovereign topology, rails must run in-process.
• One behaviour we verified rather than assumed: with a colang v1 flow, LLMRails.check evaluates the block condition only and does not apply TRANSFORM rewrites — rewrite application is an IORails concern. EVE therefore binds the transform contract at the outcome level, and says so.

Making claims refutable

Alongside the integration we added a machine-readable capability manifest. Each capability declares its transport, coverage, outcomes, failure mode, evidence format, signing algorithm, offline verifiability, feature flags, deployment status, limitations, and whether it can carry execution authority.

The manifest is only worth something because a validator mechanically refuses over-claims: execution authority on a text-only transport, a fail-closed claim with no proof reference, offline verifiability without a verifier, “durable” asserted over a development file store, tenant isolation without a tenant-scoped store, or a documentation-only capability claiming deployment.

It caught an inconsistency in our own first draft. That is the point of building it.

Open guardrails and verifiable authority are complementary

None of this is an argument against open-source guardrails. NeMo Guardrails is a capable, well-engineered project, and 0.24's explicit outcome contract is precisely what made this integration clean to build. Teams should use good detection.

The argument is narrower: detection and authorization are different layers, and evidence belongs to the second one. Knowing that a detector passed is not the same as being able to demonstrate, months later and outside the vendor's console, that a specific action was permitted under a specific policy version for a specific tenant — and that the content the model actually received is the content the record says it received.

Open guardrails make the first layer good. Signed, offline-verifiable decisions make the second layer provable. Running both is the sensible architecture.

Frequently asked questions

Does EVE replace NeMo Guardrails?

No. They do different jobs and are designed to run together. NeMo Guardrails decides whether content looks safe and can allow, block or rewrite it. EVE decides whether the governed action is authorized under a named policy version for a specific tenant, and emits signed evidence of that decision. In EVE's integration a NeMo verdict is an input to the decision, not the decision.

Why can't an external ALLOW authorize execution?

Because an ALLOW means a detector found nothing, which is not the same as a policy permitting an action. In EVE's precedence rules an external ALLOW is inert: it leaves the CoreGuard verdict exactly as it was. An external BLOCK can add restriction, and a TRANSFORM can rewrite content, but no external result can lift a CoreGuard block. That rule is checked before the mode check, so no configuration can route around it.

What happens if the guardrail backend times out?

It fails closed. EVE classifies a timeout, an unreachable backend, a malformed result, an unsupported engine version and a configuration change after load as integration failures rather than policy decisions. In enforce mode every one of them blocks. This distinction matters because a retryable infrastructure failure must never be laundered into an executable ALLOW.

How is a transformed prompt proven to be what the model actually received?

The signed decision payload binds both the digest of the original content and the digest of the transformed content, along with the engine name, its exact version and a digest of the rail configuration that produced the rewrite. If either digest is altered, the content hash no longer matches and offline verification fails. A transform whose two digests are identical is rejected as inconsistent, because it would prove nothing.

Can a NeMo tool-call rail authorize a tool execution?

No. A tool rail can block a call and can contribute risk evidence, but it never carries execution authority. When the transport exposes only message text, EVE reports the status NOT_APPLICABLE_TO_THIS_TRANSPORT. When a complete structured action is available, EVE routes it to its existing certificate, token, single-use redemption and provider-recheck chain. Content filtering is not action authorization.