Where a guardrail attaches
Lesson 3 of 5 in AWS Agents in Practice: Deploy, Authorize, Guard, Observe, Pay.
Guardrails are the most misunderstood control in agent deployments, and the misunderstanding is always the same: teams ask what does it filter when the question that decides whether it works is where does it run.
A check that runs inside your agent’s code is a check the model can be talked around, because the model produced the arguments that reach it. A check that runs on the platform edge is one it cannot: the tool call leaves the model, hits enforcement, and either passes or does not. Same filter, two completely different security properties.
On AWS there are three places a check can live, and they catch different failures.
The first attach point is the model invocation. Guardrails configured on a Bedrock model still apply when that model is invoked through AgentCore — that continuity is stated in the Agents Classic maintenance-mode FAQ, along with the reassurance that Bedrock itself, Knowledge Bases and Guardrails are unaffected by Classic going into maintenance mode. It is the cheapest thing to turn on and it covers the model’s own inputs and outputs.
It also has an obvious gap once you internalise that AgentCore is model-agnostic. If the agent is reasoning with a model that is not invoked through Bedrock, there is no Bedrock model call for a guardrail to attach to. Model-level filtering is a property of the invocation path, not of the agent.
The second attach point is the one that matters for tools, and it sits where every MCP tool call already passes. Since July 2026, AgentCore Policy supports Bedrock Guardrails: guardrail checks for prompt injection, harmful content and sensitive data exposure are evaluated at the AgentCore Gateway layer — on inputs to gateway targets and on outputs of authorized agent actions — outside the agent’s code, where the agent cannot reason around them. Because every tool and context source routes through the gateway, new agent capabilities inherit the same enforcement automatically, which is the property that makes this scale past the first ten tools.
One tool call, three enforcement points
- Model reasons over context
If the model is invoked through Bedrock, model-level guardrails see this input and the resulting output. Content-shaped checks only.
- Model emits a tool call with arguments
Still just text. Nothing has happened yet — this is the moment where enforcement is both possible and cheap.
- Check inside your agent code?
Useful for business logic you own, but it lives on the same side of the boundary as the reasoning that produced the arguments. Necessary, never sufficient.
- Gateway: Cedar policy + guardrail checks
Deterministic authorization on principal/action/resource plus conditions on input attributes, and guardrail checks for injection, harmful content and sensitive data — on the way in and on the way out.
- Target executes (Lambda, API, MCP server)
Egress credentials are attached here by the Gateway, not carried by the model.
- Output re-checked, then returned to the model
Outputs of authorized actions are also evaluated — this is the leg that catches sensitive data on the way back and tool-output poisoning attempts.
- Denied — logged, agent told no
A deny is a fact, not a suggestion. The agent may retry differently; it cannot retry its way past the policy.
| Failure you are worried about | Model-level Bedrock Guardrails | Gateway: Cedar policy | Gateway: guardrail checks via Policy |
|---|---|---|---|
User asks the agent for hate speech or a jailbreak | Yes — content filters cover hate, insults, sexual, violence, misconduct, and prompt injections/jailbreaks, for text and images. | No — Cedar authorizes actions, it does not read intent. | Partly — only if the text reaches a gateway target. These checks run on inputs to gateway targets and outputs of authorized actions, not on the model’s conversation with the user. For the chat channel itself, model-level Guardrails are the attach point. |
A web page the agent read contains instructions telling it to exfiltrate data | Partly — the injection filter may catch the text if it passes through a guarded model invocation. | Yes, structurally — the exfiltration attempt has to become a tool call, and that call faces a deterministic permit/forbid. | Yes — injection checks run on inputs to gateway targets, and every context source routes through the gateway. |
The agent tries to issue a refund of $40,000 | No. Nothing in the six safeguard types knows your refund limit. | Yes — this is exactly the | No — guardrails are content-shaped, not amount-shaped. |
A tool response returns a customer’s national ID and it heads back into context | Partly — sensitive-information filters can block or mask PII on a guarded model invocation. | No — authorization already said yes to the call. | Yes — sensitive-data checks are evaluated on outputs of authorized actions. |
A newly added tool ships without anyone reviewing its safety | No — model-level config knows nothing about your tool inventory. | Depends on your policies — default-deny policy sets fail closed; permissive ones do not. | Yes, by inheritance — because tools route through the gateway, new capabilities inherit the same enforcement automatically. |
Key terms: guardrails, prompt injection, tool-output poisoning, approval gate, least privilege
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.