Five Stages of LLM Guardrails: What Each One Checks
An AI workflow can receive a question, retrieve a document, call a tool and return an answer. Each step exposes different information. Reviewing five guardrail stages—input, output, MCP, RAG and action—helps a team decide where a check belongs. The stages are a map of possible inspection points, not a promise that every request automatically passes through all five.
Figure: A continuous content pipeline shows inspection at user input, retrieved context, tool arguments, tool results and final output. Action permission and consumption of sanitized content are separate checks.
Map the content each stage receives
Input checks inspect supported request content, and output checks inspect supported model responses. MCP-stage evaluation can examine supplied tool arguments and results on supported paths. RAG evaluation works with submitted retrieved chunks and source context. Action-stage content checks use fields such as the tool name, arguments, action class and domains.
Consider an assistant preparing a customer email. Its original question, retrieved policy passage, lookup result and proposed email each deserve an appropriate handling decision. The application must route those objects into the intended checks. Passing model traffic through a gateway does not by itself prove that every locally executed function has been evaluated.
Separate content decisions from permission to act
Explicit guardrail helpers can inspect a proposed tool invocation, while identity-aware Agentic governance handles registration, relationships, durable approvals and supported automatic execution boundaries. These interfaces serve related purposes, but they are not interchangeable.
On the current canonical MCP path with Agentic authorization enabled, only an exact Allow runs the tool. Content redaction does not supply missing access or clear a pending approval. Keep the content decision and the authorization decision distinct in the application and in the evidence shown to an operator.
Make the timing match the policy
A blocking check must finish before the protected content or action is released. Background evaluation can provide useful observations after a response, but it cannot recall text already delivered. For streaming, choose whether the application must buffer output until its required checks complete or can accept the documented asynchronous behavior.
Also handle explicit redaction correctly. In SDK 3.0.0, allow_with_redaction is nonblocking, alongside the other documented allowed content decisions. Explicit evaluation does not rewrite a local variable; the application must consume the sanitized result before forwarding the content. Check the returned decision itself rather than assuming that a reported shadow mode changes its meaning.
Visual guide: Five Stages of LLM Guardrails: What Each One Checks
Figure: Five guardrail surfaces surround a model runtime: input, retrieval, MCP tools, external actions and output, with a shared policy band below.
Publish a policy the team can explain
Current policy cards separate Settings from Patterns / JSON. A card override replaces its generated detectors and lists, while Settings retain the action, severity and enabled state. Review the effective configuration and supported scopes, then publish the policy and verify the intended Virtual Key binding for live inference.
Test matching, ordinary and boundary examples at each relevant stage. Include the media types the application accepts: text extraction, image metadata and external file references have different inspection limits. The October 2026 policy-editor guidance requires a gateway deployment containing those changes; publishing documentation or upgrading the SDK alone does not deploy them.
Map a complete support workflow to the five stages
A customer asks a support assistant to update an address using information from an uploaded note. Input checks inspect the customer message; retrieval checks address extracted passages; an action or MCP check concerns the proposed tool request; output checks concern the answer shown to the customer. Draw which content each stage actually receives. A detector that sees the chat message may never see a later tool result unless that integration submits the result through the intended boundary.
Use separate synthetic markers in each stage so a test can identify where inspection occurred. Verify which marker generated a finding and whether the corresponding content was blocked, redacted or merely recorded. DeepintShield’s explicit SDK helpers return structured decisions, while transparent provider requests surface gateway outcomes through their own response handling. Follow the documented contract for the surface under test instead of assuming identical exceptions everywhere. SDK stage contract
Check redaction consumption rather than only the verdict
Send a synthetic sensitive value that the chosen policy is expected to redact. Inspect the exact content forwarded to the next model or tool, and confirm the original marker is absent there. An allowed redaction result is incomplete protection if the application then forwards its original local input. Keep a separate reference to the original only where authorized for diagnostics, and avoid putting the full sensitive value in a general-purpose test log or screenshot.
Repeat with a blocking result and a monitor-only policy to verify the application distinguishes them. Test an unsupported or malformed decision as an error case rather than converting it to ordinary success. For streamed output, observe what reaches the consumer before the final verdict. If the requirement is that no unchecked text is displayed, use an appropriate buffering boundary; a cleaned final response does not remove an earlier visible delta or repair a downstream action triggered by it.
Create a policy release checklist around behavior
Before publishing a policy change, prepare matching, nonmatching and ambiguous examples in the languages and formats the workflow uses. Review the effective card configuration, especially overrides that replace generated detectors. Confirm that publishing the policy, not merely saving a draft, activates the intended behavior in the target workspace. Keep the previous configuration and its test set so a rollback can be evaluated against known expectations rather than treated as an untested return to an older label.
After rollout, sample both false positives and missed detections. A sudden reduction in findings can mean improved inputs, but it can also indicate a changed scope or a disconnected detector. Correlate policy version and request stage with the result before drawing conclusions. Content checks should remain separate from permission to update the address: an ordinary-looking request still requires the correct actor, resource and authorization. No detector result alone establishes that the customer owns the account.
Keep a fixture for each place that customer address data enters the workflow, including the user message and a tool result. Verify the relevant transformation at the next consumer. A policy applied correctly to the initial prompt can still leave an independently assembled downstream action argument unchanged.
Frequently asked questions
Are five stages always five sequential checks?
No. They describe supported evaluation surfaces. The workflow, enabled policies and integration determine which checks run and when; document that coverage for the actual request path.
Why did an allowed redaction result still expose the original value?
A likely integration mistake is forwarding the original local content instead of the sanitized result. Trace the exact value across the evaluation and forwarding boundaries with synthetic data. Also confirm which stage and modality were inspected; a verdict on one representation does not necessarily cover another attachment or later tool response.
Documentation and further reading
October 2026 documentation updates
Related guide: Agentic AI Security: How PEP and PDP Protect Tool Calls
