Review Blocked Requests
When a guardrail acts on a request, the caller sees a blocked message and Agentic Data Plane records the action on the request’s trace. Agentic Data Plane does not include a dedicated violations dashboard. You review blocked requests through transcripts and, for guardrails the AI Gateway evaluates itself, through the audit log.
After reading this page, you will be able to:
-
Review what a caller sees when a guardrail blocks a request
-
Find guardrail activity in a request’s transcript or in the audit log
-
Diagnose a guardrail that blocks too much or doesn’t fire
What the caller sees
-
Blocked input: Agentic Data Plane stops the request before it reaches the model and returns your configured blocked input message.
-
Blocked output: Agentic Data Plane returns your configured blocked output message instead of the model’s response.
-
Anonymized PII: When the sensitive-information policy anonymizes a match on output, Agentic Data Plane delivers the response with each match replaced in place by its entity type, such as
{EMAIL}. On input, this release does not forward the redacted prompt to the model: Agentic Data Plane short-circuits the request like a block and returns your configured blocked input message, not the redacted prompt.
The blocked message arrives in the shape the caller’s client expects. When a caller without an agent identity has its input blocked on a streaming request, Agentic Data Plane sends the blocked message as the stream’s own events and closes the stream normally, so an SDK reads it as the model’s reply instead of reporting a transport error.
A call an agent makes is refused rather than answered, whether the guardrail blocked it or only anonymized the output. A blocked input, a withheld output, and an output the guardrail anonymized instead of withholding all come back to the agent as an HTTP 403 error with the error code guardrail_intervened, in a single error envelope that OpenAI- and Anthropic-format SDKs both parse. For an anonymized output, the message the agent receives is the anonymized text itself, so an agent never gets it as the ordinary reply the bullet above describes. The agent’s runtime records the turn as failed, so the reason reaches the turn’s transcript instead of reading as an ordinary reply. One case stays a reply: a guardrail that intervenes partway through a streaming response, by blocking or anonymizing, cannot be turned into an error because the response has already started, so the agent receives that message in the stream like any other caller. A call that carries no agent identity, such as a person in a chat client or your own application code, always receives the blocked or anonymized message as the model’s reply.
Automated reasoning never blocks. It records findings on the trace for your application to act on.
Where guardrail activity is recorded
Agentic Data Plane records guardrail activity as attributes on the request’s OpenTelemetry trace, which you read in the request’s transcript alongside the LLM call, tool calls, and cost data. See what your agent did.
When the AI Gateway evaluates the guardrail itself, which is how a guardrail runs on a non-Bedrock provider, the audit log also records the result on the call’s event. The call’s outcome reads Denied when the guardrail blocked it and Masked when the guardrail anonymized the response, and the event’s Policies section names the guardrail with a Blocked or Masked result and links to it. On a Bedrock provider, Bedrock enforces the guardrail as part of the model call, and the audit log does not attribute the block to the guardrail. Use the transcript for those requests.
For streaming responses, Agentic Data Plane evaluates output in batches as the stream arrives and records the outcome on the trace. Input evaluation runs before the stream starts.
Troubleshoot guardrail behavior
When a guardrail blocks legitimate traffic or fails to act when you expect it to, work through the checks in this section to find the cause.
A guardrail blocks too much
If a guardrail blocks legitimate traffic:
-
Content filters: Lower the strength for the affected category, or set its action to detect while you tune.
-
Sensitive information: Narrow the entity types or regex patterns to the data you actually care about. Structured payloads such as code or JSON can contain strings that resemble PII.
-
Denied topics: Tighten each topic’s definition and examples so the semantic match is more specific.
-
Contextual grounding: Lower the threshold so only clearly ungrounded or irrelevant responses are caught.
To stage a change without enforcing it, set the policy’s action to detect and review the results on the trace before you block. For contextual grounding, you can also turn off a filter’s Evaluate this check switch to skip evaluating it entirely.
A guardrail doesn’t fire
If you expect a guardrail to act and it doesn’t:
-
Confirm the guardrail is enabled. A disabled guardrail keeps its configuration but skips evaluation.
-
Confirm the specific policy is enabled. The guardrail’s detail page shows each policy’s Enabled or Disabled status; a disabled policy takes no action. For contextual grounding, also confirm the filter’s Evaluate this check switch is on.
-
Confirm the provider the request used references this guardrail. A guardrail acts only on providers that reference it.
-
Confirm the direction. An output-only policy such as contextual grounding never acts on input, and an input-only policy never acts on output.
-
Confirm the request actually went through the provider. Direct-to-provider requests that bypass Agentic Data Plane are not evaluated.
