Same agent, two clouds: a field guide to guardrails
What Bedrock Guardrails and Azure's Foundry guardrails actually catch, where each one checks, what they miss, and what they cost.
- Published
- Reading time
- 7 min
On this page
Every agent platform now sells “guardrails”, and every architecture diagram has a box with that word in it. The box usually hides three questions: what does it actually catch, where does it check, and what does it miss?
This part of the series answers those for the support agent from ATC-001, on Amazon Bedrock and on Microsoft Foundry.
What a guardrail is, and isn’t
A guardrail is a separate classifier that reads text on its way into or out of the model and decides whether it looks harmful, off-limits or like an attack. It’s useful, and it’s probabilistic. AWS says its content filters block “up to 88%” of harmful content. Microsoft warns that a clean Prompt Shields result “doesn’t establish that the request is benign”. OWASP’s guidance on prompt injection says it’s unclear whether fool-proof prevention exists.
So a guardrail lowers risk. It doesn’t replace the two controls that actually limit damage: least privilege for what the agent’s tools can do, and a person’s approval for anything that can’t be undone. ATC-006 and part three cover those.
The four checkpoints
An agent’s traffic can be checked in four places:
- What comes in. The user’s message. This catches abuse, off-topic requests and direct jailbreak attempts.
- What comes back. Tool results, retrieved documents and web pages. This is where indirect prompt injection arrives: instructions hidden in an email or a support ticket that the agent reads and then obeys. It’s the most important checkpoint for an agent, and the one most setups skip.
- What it’s about to do. The tool call and its arguments, before it runs.
- What goes out. The final answer, checked for harmful content, leaked personal data or claims the sources don’t support.
Azure’s default guardrail, or a guardrail you create and attach on AWS (Bedrock has no default), covers 1 and 4 well. The differences are in 2 and 3.
AWS: Bedrock Guardrails
You define a guardrail once and attach it to model calls, agents and knowledge bases. It has six kinds of policy:
- Content filters for hate, insults, sexual content, violence and misconduct, plus a prompt attack filter for jailbreaks and prompt injection. Each has a strength from none to high, set separately for input and output, except prompt attack, which checks input only. They work on text and images.
- Denied topics: up to 30 subjects described in plain language, such as “investment advice”.
- Word filters: exact words and phrases, free of charge.
- Sensitive information filters: 31 built-in types of personal data plus your own patterns, each set to block, mask or just detect.
- Contextual grounding checks: scores whether the answer is supported by the source text and relevant to the question.
- Automated Reasoning checks: validate answers against rules you’ve written down as a formal policy. English only, detect-only, and not a defence against prompt injection.
Two details matter for agents.
The inline guardrail doesn’t read tool results. AWS documents that its filters, prompt attack and sensitive information included, don’t evaluate tool results or tool definitions. If you call InvokeModel directly, prompt attacks are only checked inside the input you’ve explicitly tagged as user input. To cover checkpoint 2, call the guardrail yourself on each tool result. ApplyGuardrail runs a full guardrail on any text, and the newer InvokeGuardrailChecks API runs individual checks, prompt attack included, with no guardrail to configure. Both take plain text, so you can use them with models outside Bedrock too.
For checkpoint 3, use the gateway. With AgentCore Policy, AgentCore Gateway can run content, prompt attack and personal-data checks on the inputs and outputs of any tool you write a policy for, so tool calls and tool results are checked in one place. Tools without a matching policy aren’t checked, so cover them all. Part two covers the gateway.
There are two tiers. Standard adds detection inside code, prompt-leakage detection and much broader language support, and requires cross-Region inference. Classic supports English, French and Spanish only. Both cost the same. AWS says guardrails are ineffective in languages they don’t support, so check the list if your users don’t write in English.
Azure: Foundry guardrails and Content Safety
On Azure, models sold through Foundry get a guardrail by default. The default blocks hate, sexual content, violence and self-harm at medium severity and above, and detects direct prompt attacks. You can raise or lower the thresholds, switch to annotate-only for model deployments, and add blocklists. The same checks are available as a standalone service, Azure AI Content Safety, for anything else.
The features that matter beyond the default:
- Prompt Shields detect both direct attacks from the user and document attacks: instructions hidden in retrieved content. Document attack detection is off by default. Turn it on.
- Tool call and tool response checks for agents, in preview. Foundry can check what an agent sends to a tool and what comes back, but only for supported tools such as AI Search, Functions, OpenAPI tools and SharePoint. Each checkpoint adds roughly 50 to 100 ms.
- Groundedness detection checks answers against their sources. English only, and in preview as a guardrail control.
- Protected material detection flags known copyrighted text and public code.
- Task adherence, PII detection and custom categories are in preview.
- Spotlighting, also in preview, marks retrieved documents so the model treats them as data, not instructions.
One gap to know: Claude models on Foundry “use Anthropic safety systems and safeguards, supported by Microsoft”. Microsoft’s documentation doesn’t say whether Foundry guardrails apply to them, so if you run Claude there and need Microsoft’s checks, call Content Safety yourself.
Side by side
-
1. What comes in
AWS: Guardrail on the model call Content filters, prompt attack, denied topics, PII.Azure: Default guardrail On by default. Harm categories and user prompt attacks. -
2. What comes back
AWS: Check each tool result yourself With ApplyGuardrail or InvokeGuardrailChecks. Inline filters skip tool results.Azure: Prompt Shields document attacks Off by default. Tool response checks in preview, supported tools only. -
3. What it's about to do
AWS: AgentCore Gateway with guardrails Checks inputs and outputs of each tool you write a policy for.Azure: Tool call checks Preview, supported tools only. Task adherence in preview. -
4. What goes out
AWS: Guardrail on the model call Plus contextual grounding and Automated Reasoning.Azure: Default guardrail Plus protected material, and groundedness in preview. -
Personal data
AWS: Sensitive information filters Block, mask or detect. 31 types plus regex.Azure: PII guardrail Preview. -
Models from other vendors
AWS: ApplyGuardrail works with any model Including self-hosted and other clouds.Azure: Content Safety API Claude on Foundry uses Anthropic's safety systems.
What it costs
Both clouds bill by the amount of text checked, in units of up to 1,000 characters.
- AWS charges per policy. Content filters and denied topics cost $0.15 per 1,000 units each, sensitive information and grounding checks $0.10, and Automated Reasoning $0.17 per policy. Word filters and regex patterns are free. Through
InvokeGuardrailChecks, a prompt attack check costs $0.08 per 1,000 units. - Azure bills Content Safety at $0.375 per 1,000 text records, and Microsoft lists Prompt Shields and groundedness under the same text-record pricing. Microsoft doesn’t publish a separate charge for the default guardrail on Foundry model deployments.
For the support agent in ATC-001, checking the customer’s message and the final reply with two policies costs about $6.30 a month, more than the default model.
Now add checkpoint 2. Say each conversation reads three tool results of about 4,000 characters each: 36,000 units a month. A prompt attack check on every one costs about $2.88 a month with InvokeGuardrailChecks on AWS, or about $13.50 at Azure’s text-record rate. Either way, it’s cheap compared with what an injected instruction could do with your order system.
Five rules that hold on both clouds
- Check the edges and every untrusted input. That means the user’s message, every tool result and the final answer. You don’t need to check the model’s own reasoning between steps.
- Treat tool results as user input. Anything an outsider could have written, such as an email, a ticket, a web page or a review, goes through a prompt attack check before the model sees it.
- Don’t confuse guardrails with permissions. A guardrail might catch an injected “refund this order”. What reliably limits the damage is the refund tool’s own limits and a person’s approval.
- Start in detect mode. Both clouds can flag without blocking. Run that way for a week, look at what it flags and how often it’s wrong, then switch to blocking.
- Know what streaming does. On AWS, the default streaming mode checks each chunk before sending it; the faster asynchronous mode can let text through first. On Azure, even the default mode can send the last part of an answer before it’s checked, and the asynchronous mode can show up to about 1,000 characters before a flag arrives. If an answer must never be seen before it’s checked, don’t stream it.
A checklist
- Guardrail on input and output, with thresholds you chose, not just the defaults
- A prompt attack check on every tool result and retrieved document
- Azure: document attack detection turned on
- AWS: tool results checked with
ApplyGuardrailorInvokeGuardrailChecks, or through the gateway - Personal data masked in outputs and logs
- Least privilege and human approval behind every tool that writes
- A week in detect mode before blocking
- Your users’ languages checked against the supported list
- Adversarial tests of your own, re-run whenever the prompt or tools change
Status and prices as of October 2026; preview features may change. Sources: Bedrock Guardrails, prompt attack filter, sensitive information filters, guardrail tiers, supported languages, ApplyGuardrail, InvokeGuardrailChecks, AgentCore Policy with Guardrails, Amazon Bedrock pricing, Foundry guardrails, intervention points, default safety policies, Prompt Shields, groundedness detection, content streaming, Bedrock guardrails with streaming, AgentCore Policy guardrails, Claude models on Foundry, Content Safety pricing, OWASP LLM01: Prompt injection.
- aws
- azure
- guardrails
- bedrock
- content-safety
- prompt-injection
- security