Stop uncertain actions and escalate by risk

Learning objective

Define fail-closed defaults and risk-based escalation to human reviewers.

Core idea

Fail closed means withholding the protected action or content when the required control cannot establish permission to proceed. A timeout, missing verdict, invalid detector response, or unavailable reviewer must not become an implicit approval. It does not require shutting down every unrelated function in the application.

Write a safety-outcome policy that distinguishes a policy violation from an unavailable decision and from an authorized request that still requires review. That distinction determines whether you refuse, defer, or escalate. NVIDIA’s runtime security FAQ explicitly states that NeMo Guardrails has no library-wide failure policy applying to every rail and integration; the selected engine, flow, action, and provider determine behavior. Check each rail’s Guardrail Catalog entry for its documented failure behavior. For example, with the default parser, self_check_input and self_check_output treat empty model output as unsafe and block, and self_check_facts explicitly fails closed with a score of 0.0; each task logs a warning when the model hits max_tokens before producing visible output.

See 10.4.1–10.4.3 for approval design, interrupts, and accountable oversight. This lesson decides what happens while a required safety decision is missing and how review demand stays within a usable operating model.

How it works

Define terminal outcomes before choosing detectors

Use a policy table that names each protected operation, its required checks, the authority allowed to resolve uncertainty, and its safe terminal outcome. OWASP’s Excessive Agency guidance calls for independent verification of high-impact actions and human approval where appropriate. An agent’s self-assessment cannot supply the missing authorization.

Distinguish four application outcomes. Allow means all required conditions passed. Deny means policy prohibits the request. Review means policy permits a qualified reviewer to decide an unresolved case. Unavailable means a required control could not complete. These are application policy categories, not NeMo return-value enums.

A clearly prohibited disclosure should be denied, rather than placed in a queue where an operator might casually approve it. A permitted but unusually consequential operation can be held for review. An unavailable detector requires the application to withhold the protected result, return a safe status, and decide whether approved manual review can replace that particular check. Do not make every outage a human-review request by default.

Configure the actual failure mechanism

NeMo Agent Toolkit’s v1.9.0 retail safety example documents _type: output_verifier middleware. Its built-in defense middleware uses the defense extra (nvidia-nat[defense]). Set fail_closed: true when content must not pass through after a verifier-model outage or an invalid response, including a missing decision field. The middleware treats that condition as a threat and applies its configured action.

Choose the action deliberately. action: refusal blocks the output. action: redirection replaces it with the middleware’s fallback response. action: partial_compliance logs the problem and allows the original output, so it is a monitoring choice rather than a protective choice for this requirement. A fail-closed flag combined with a pass-through action does not achieve the intended release policy.

Placement matters as much as the flag. An output verifier after a tool cannot prevent a side effect that tool already performed. Attach the required decision before the protected consequence, and reserve post-execution verification for content that has not yet been released. Test that a refusal message is handled as a stopped operation rather than parsed as an ordinary successful tool result.

Prevent configuration fallback from removing protection

The experimental IORails tool rails described in 9.4.1 fail closed on malformed tool payloads. However, the application must actually select that engine, either by constructing the Guardrails facade or by setting NEMO_GUARDRAILS_IORAILS_ENGINE=1 so the top-level LLMRails import resolves to the IORails-backed engine. The Guardrails facade can silently fall back to LLMRails for an incompatible configuration, leaving the IORails tool rails inactive.

NVIDIA documents that rails.tool_output accepts tool call validation, while rails.tool_input accepts tool result validation. A misdirected, unknown, or duplicated flow name makes the configuration ineligible for IORails. Construct the facade with require_iorails=True when those rails are required so an incompatible configuration raises instead of downgrading silently. Test an intentionally misspelled flow during deployment verification.

These tool rails require a Colang 1.0 configuration and support the openai and nim engines using the OpenAI Chat Completions wire format. Their experimental status and compatibility limits belong in your deployment decision. Neither the fail-closed validation behavior nor the constructor option establishes a universal failure policy for unrelated rails.

Route uncertainty without treating silence as consent

NeMo Agent Toolkit provides the interaction mechanism through Context.get().user_interaction_manager and its prompt_user_input method. A HumanPromptText request pauses the workflow until input returns. That exchange supplies human input; the application still has to authenticate the reviewer, validate the decision, and decide whether the proposed operation remains authorized.

Keep the escalation policy separate from the interaction transport. In the documented interactive-workflow path, nat serve supports the interaction data models, while nat run supports only HumanPromptText; the front-end instructions enable WebSocket mode. Select a supported path before depending on a review prompt in an otherwise unattended process.

Your safety-outcome policy must also define a review deadline and an expiry outcome. The Toolkit’s prompt models carry an optional timeout field (HumanPromptBase.timeout, default None) where the deadline is set. Over HTTP interactive execution, an interaction_required response returns the prompt with its timeout and an error field, which is populated only when the prompt times out or becomes unavailable; that is the signal the application observes. If the reviewer disconnects or the deadline expires, leave the operation unexecuted and return a deferred or refused result. A later response needs validation against the still-pending request; it must not resurrect a request that already expired. The detailed approval lifecycle belongs to 10.4.1–10.4.2.

Key distinctions and trade-offs

Use the missing or adverse condition to choose the response:

Fail closed trades availability for an explicit safety requirement. Control the scope of that trade: a payment decision can stop while independently checked, read-only itinerary retrieval continues. Do not route the payment to an unchecked model or tool to make the failure disappear.

Architecture / decision scenario

An employee travel assistant prepares reimbursements. The finance owner permits routine claims below $200 after automated checks, requires a reviewer for claims above $2,000 or changed bank details, and prohibits payments to an unauthorized recipient. Claims from $200 to $2,000 pass the same automated checks and go to a reviewer only when another risk signal fires, such as a duplicate receipt or a merchant outside the trip’s location; a 1% random sample of them also goes to audit review. These are hypothetical organization rules, not NVIDIA limits.

The workload is 1,200 requests per hour. Normal review demand is 2%, or 24 requests per hour, while the team can resolve 40 per hour. During a detector outage, a proposed fallback sends 10% of requests to review: 120 per hour. That adds 80 unresolved requests each hour. The tempting alternative is to auto-approve after a ten-minute wait, but that turns reviewer scarcity into permission to transfer money.

The finance owner rejects automatic approval. The application stops protected payment actions when the required detector cannot decide. It admits only the review cases the approved manual process can resolve, returns a deferred status for excess work, and keeps independently authorized itinerary reads available. The ten-minute deadline ends in deferral, never execution. The platform owner restores detector service; finance owns the manual substitute and queue priorities.

Verification covers an unavailable verifier, a missing decision field, an incompatible IORails configuration, a reviewer disconnect, and expiry followed by a late reply. Each test checks that no payment occurred. The team also checks that valid low-risk work completes when its required controls are healthy; fail-closed behavior should match the protected consequence rather than conceal a system-wide outage.

Common exam traps

• Treating a detector error as a safe classification.
• Assuming every NeMo Guardrails integration shares one failure default.
• Combining fail_closed: true with partial_compliance and expecting blocking.
• Assuming an output refusal can prevent an already completed tool side effect.
• Letting the facade downgrade while required IORails protections disappear.
• Treating a human prompt, reviewer silence, or queue expiry as authorization.

What to remember

Specify the safe outcome for every missing decision. Configure the engine and action that enforce it, then inject failures to prove the protected consequence stays blocked. Escalate only cases a permitted reviewer can resolve, and keep queue pressure or expired requests from becoming implicit approvals.

Knowledge check

References

• NVIDIA, AI Runtime Security FAQ
• NVIDIA, NeMo Agent Toolkit Safety and Security, v1.9.0
• NVIDIA, Tool Calling
• NVIDIA, LLM Self-Check
• NVIDIA, Interactive Workflows Guide
• NVIDIA, HTTP Interactive Execution
• NVIDIA, nat.data_models.interactive
• OWASP, LLM06 Excessive Agency