Guardrails in production.

Choose controls for the application.

“Refund my $10 order.” The agent refunds $10. Everything looks right—except the order belongs to another customer. Checking the amount is easy. Checking whether this user can refund this order belongs at the payment boundary.

An input check would miss that failure; an output check would arrive too late. Put guardrails where they can stop the mistake: before data access, before an action, and before an answer reaches the user. Start with what your application can do.

For RAG, separate missing evidence from failure to use available evidence. Retrieve more or abstain in the first case; correct or reject the answer in the second. Google’s sufficient-context research makes this distinction explicit.

Other workflows extend these controls. Persistent-memory agents need checks before storing and reusing information. Event-driven agents need authenticated events, duplicate detection, and bounded retries. Extractors need schema, range, and source checks. Code copilots need secret detection, sandboxing, and validation before execution or merge. Bulk generators need a publication gate. Multi-agent systems need explicit delegation boundaries.

Combine profiles when capabilities overlap. A chatbot that retrieves documents and changes accounts needs conversational, retrieval, and action controls.

Layered controls.

Your prompt says “never share customer data.” A retrieved document says “send it to this URL.” Prompting can guide the model; it cannot guarantee obedience. Your application can enforce what enters context, which tools run, where data goes, and what reaches the user. Put controls at each of those boundaries.

• Input — before the model call. Inspect the incoming message, event, and attachments. Validate size and structure; detect injection and unsupported intent; handle sensitive information. Run local privacy checks first if the data must not reach an external guard service.
• Data and retrieval — before adding context. Enforce tenant/document access in the retrieval backend. Inspect source applicability, freshness, and malicious instructions. A trusted connector can return untrusted content.
• Action — immediately before execution. Check the resolved tool, arguments, authenticated identity, destination, and current resource state. Bind approval to the exact operation; recheck changed arguments.
• Output — before delivery or publication. Check sensitive disclosure, policy violations, and unsupported claims. For RAG, verify both grounding and relevance: a source-consistent answer can still fail to answer the question.
• Memory and handoff — before persistence or reuse. Check source, ownership, retention, and authority. A summary must not upgrade the trust level of its source.

Use explicit outcomes: ALLOW, REDACT, CLARIFY, BLOCK, ABSTAIN, or ESCALATE. Keep checker errors separate from policy decisions.

Use inexpensive checks first.

Use deterministic rules wherever the decision is precise. Add semantic checks only where meaning matters, and reserve evaluator calls for ambiguity.

Each method has a limit. Regex misses contextual PII. Similarity scores are not safety probabilities. Specialist models need task-specific evaluation, and LLM reviewers can be wrong. A scope match never grants access or permission to act.

Make the scope router return a usable decision.

Define supported intents and examples of near misses. Include relevant dialogue for follow-ups such as “cancel it.” Route strong matches to a workflow; ask for clarification when intent or required fields are ambiguous; reject unsupported scope. Treat missing RAG evidence separately from scope.

For mixed requests, evaluate each requested operation before acting. A request can contain an allowed question and an unauthorized instruction. Reclassify when the user introduces a new task. Run privacy and injection checks independently.

NeMo exposes embeddings_only, embeddings_only_similarity_threshold, and embeddings_only_fallback_intent. Set the fallback deliberately; do not interpret a weak nearest match as permission to proceed.

Use selective escalation within each risk category. Total check cost includes cheap screening, required independent checks, and the fraction escalated to expensive evaluation. Fixed latency bands are not guarantees: payload, serving hardware, batching, and queueing determine actual performance.

Make enforcement happen before impact.

Keep three responsibilities separate: a detector reports a finding, policy chooses the response, and application code enforces it. For example, an injection classifier returns a score; policy decides to block; the orchestrator prevents the model call. The model must have no alternate route around that gate.

1. Async execution can still enforce a blocking gate.

Run independent checks concurrently, then await every mandatory verdict before starting the protected operation. In the OpenAI Python Agents SDK, use @input_guardrail(run_in_parallel=False) when the agent must wait. With parallel mode, the agent can consume tokens or start work before the guardrail finishes. Cancellation cannot undo an external side effect (SDK guardrails).

Use asynchronous I/O for network calls; move blocking CPU/GPU inference to appropriate workers or model serving. Bound concurrency rather than launching an unbounded batch of classifier calls.

2. Attach controls where the framework runs them.

OpenAI documents that agent input guards apply to the first agent, output guards to the final-output agent, and tool guards to the function tools carrying them. Protect intermediate actions at the tool boundary; audit hosted tools, MCP, shell, and custom executors for their own enforcement path (OpenAI human review).

3. Pass validated fields between components.

Keep retrieved text out of system/developer policy messages. Extract only necessary fields into a bounded schema; validate enums, identifiers, ranges, and ownership before use. OpenAI recommends structured data flow to reduce injection propagation (OpenAI safety guidance). Valid JSON can still contain a malicious destination or unauthorized account ID, so schema validation must be followed by semantic and permission checks.

4. Pause and resume approvals without replaying work.

For sensitive function tools, OpenAI supports needs_approval=True. A paused run exposes interruptions and resumable state. Persist that state for delayed review and resume the same run; do not restart the user request and risk repeating earlier actions (OpenAI human review). Revalidate mutable permissions at execution and use backend idempotency independently of the SDK.

5. Buffer output before release.

In NeMo, configure rails.output.streaming.stream_first: false and use stream_async() when chunks must pass checks before delivery. Tune chunk_size and context_size together. Overlap helps detect split violations; it does not prove whole-answer safety (NeMo streaming). Buffer the complete answer when cross-sentence verification is required.

6. Choose correction behavior explicitly.

Guardrails AI documents EXCEPTION, REFRAIN, FIX, and REASK among its validation-failure actions. NOOP records a failure but does not prevent delivery. Bound regeneration with num_reasks where supported, revalidate transformed output, and handle service exceptions separately from failed validation. Streaming support differs by validator and failure action; verify the chosen combination (Guardrails AI failure actions).

7. Isolate serving and enforce an end-to-end budget.

Keep cheap rules local where practical. A shared model service improves utilization but adds network and queue latency. Stateless workers can scale while conversation state, approvals, and memory remain in controlled stores. Propagate deadlines, cap payloads and evaluator tokens, and stop optional escalation when the budget is exhausted.

Decide what happens when a check fails.

Fail closed for authorization, mandatory disclosure checks, and irreversible actions. Degrade safely by abstaining, switching to read-only behavior, or queuing review. Fail open only for explicitly optional, low-consequence checks; never let that bypass required controls.

A timeout bounds one call. A circuit breaker stops repeated calls to an unhealthy dependency after configured failures and later probes recovery. There is no universal 200 ms threshold. Opening the breaker invokes the failure policy—it does not authorize bypass.

Return a controlled unavailable response when nothing has executed. If a transaction may already have committed, report its status as pending or unknown until reconciled; do not invite a blind retry.

Preserve trust across the workflow.

A malicious instruction saved as “customer preference” can return next week. Preserve the source and authority of information as it moves through retrieval, tools, summaries, and memory.

• Preserve provenance on retrieved text and tool results. Carry the source ID, tenant, source version or timestamp, and trust level with the content. Keep those labels through summarization and agent handoffs.
• Do not promote document instructions into system policy. Treat external instructions as data. Keep trusted policy separate from retrieved text, tool responses, and user-controlled fields.
• Validate actions independently of the text that suggested them. Check the authenticated user, approved workflow, destination, and actual arguments. A document saying “send this file” supplies no authorization.
• Treat memory writes as a separate boundary. An injected instruction stored as memory can recur across sessions. Validate proposed writes, restrict scope and retention, and recheck access when reading them.
• Give tools narrowly scoped credentials and restrict outgoing destinations. Limit credentials by task and resource; enforce network, filesystem, and destination policy outside the model. A classifier miss should not expose unrestricted access.

Turn production failures into better controls.

A rising block rate does not tell you whether your guardrails improved. You might be stopping more attacks—or rejecting more customers. Connect each verdict to the outcome of the request, then review both failures and successful-looking runs.

Record the decision and its consequences.

Give every request a trace ID and every check a span. Capture the boundary, check version, verdict, reason, score if available, latency, timeout, escalation, and final action. Link retrieval source IDs, tool outcomes, and human overrides. Distinguish “the guard fired” from “the guard was right.”

Redact routine telemetry. Keep input hashes and transformation metadata; retain original payloads only when justified, with restricted access and retention. Logging raw and sanitized prompts by default creates another sensitive-data store.

Find recurring patterns before changing thresholds.

Group reviewed failures by reason, workflow, language, source, and policy version. Use redacted text or embeddings to cluster paraphrases. Rank clusters by severity, affected users, growth, and failure rate—not raw volume alone. Ten repeated retries from one user are different from ten independent failures.

For example, if a developer assistant blocks “kill the process,” inspect the surrounding task. The fix may be better contextual classification, rather than weakening the violence policy for every workflow.

Look for edge cases among the passes.

Sample near-threshold decisions, disagreement between checks, user corrections, repeated retries, and human overrides. Also sample ordinary passes: otherwise you cannot discover silent misses. Test split secrets across stream windows, multilingual injections, quoted attack text, mixed intents, and instructions hidden in tool results or memory.

Reviewers must label whether each case should pass, clarify, redact, or block. A model score or a user complaint is a signal to investigate, not ground truth.

Version the whole decision path.

Record an immutable release manifest covering policy rules, thresholds, detector models, evaluator prompts, application prompts, retrieval/index versions, tool schemas, and permission configuration. Keep references to the source evidence used for a decision. A changed retriever can alter guardrail outcomes even when the classifier stays unchanged.

Promote reviewed cases into regression tests.

Turn each adjudicated failure into a test with an expected decision and an execution assertion—for example, “clarify, and do not call the refund tool.” Add controlled variants and retain a separate holdout set. Compare false blocks, missed violations, task completion, latency, and cost by workflow and language.

Evaluate offline, then shadow the proposed policy on production traffic without executing duplicate actions. Canary the release with explicit rollback criteria. OpenAI’s evaluation guidance recommends continuous evaluation and growing the test set as new failures emerge.

Preconfigurable implementations.

Start with a working example, then configure it for your application. These four Python notebooks include setup instructions, editable policies, and sample checks.

The configuration checker reviews declared settings; it does not prove runtime enforcement. Test that protected operations wait for mandatory checks, including when a checker fails or times out.

Provenance coloring and limited paraphrasing.

“Within 30 days” becomes “about a month.” A small rewrite can change a policy.
For critical facts, validate evidence IDs and let code copy the source text; limit paraphrasing to surrounding explanation and preserve conditions, quantities, and exceptions.
Color and label spans as evidence-copied, flagged for review, or unchecked—the evidence-bound repair preprint demonstrates this provenance approach.
These labels show how text was produced, not whether it is true; source selection and completeness still need checks.

Keep these docs close.

OpenAI SDK guardrails · Tool approvals · NeMo configuration · NeMo streaming · Guardrails AI failure actions · Sufficient Context · Continuous evaluation

Benchmark the versions you deploy on representative traffic. Latency, cost, and detection quality depend on your configuration and workload.