Per-cloud mapping: Bedrock, Foundry, Gemini Agent Platform

AWS — Bedrock Guardrails + AgentCore Policy

Amazon Bedrock Guardrails is a policy object with six configurable safeguard types:

• Content filters — hate, insults, sexual, violence, misconduct, and prompt injections/jailbreaks, for text and images.
• Denied topics — your topic bounds, declared and enforced.
• Word filters — profanity and custom blocklists.
• Sensitive information filters — PII plus custom regex, with a choice of block or mask.
• Contextual grounding checks — hallucination detection against a reference source.
• Automated Reasoning checks — logic-based verification of responses against rules you define.

That is catalog rows 1, 2, 3 and 5 in one attachable object, which is why Bedrock Guardrails is the densest single mapping of the three clouds.

The agent-relevant change came in July 2026: AgentCore Policy gained support for Bedrock Guardrails, so 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 authorised agent actions. AWS’s framing is the one that matters architecturally: the checks run outside the agent’s code, where the agent cannot reason around them. And because tools and context sources route through the Gateway, a new tool inherits the same enforcement automatically instead of needing its own wiring.

Alongside the classifier-style checks, AgentCore Policy is where your deterministic rules live: attribute-based policies in the open-source Cedar language (permit/forbid over principal, action, resource, plus optional when conditions) evaluated against every agent action passing through the Gateway. Cedar conditions can read tool-call input attributes — the documented CDK example conditions on a coverage amount staying under a limit — which is exactly catalog row 4 with teeth.

What you still own: output sanitisation at your rendering boundary (row 8), session budgets (row 7), and the containment layer — Gateway egress auth, execution-role scoping, and the microVM session isolation AgentCore Runtime provides.

Azure — Microsoft Foundry guardrails + Prompt Shields

In Microsoft Foundry (the current brand; the lineage runs Azure AI Studio → Azure AI Foundry → Microsoft Foundry), a guardrail is a named collection of “controls”, and each control declares three things: a risk to detect, the intervention points to scan, and a response action. If you were designing a catalog from scratch, you would land on almost exactly this object model — which is why Foundry is the clearest teaching example of the pattern.

The four intervention points are:

• user input
• tool call — preview, agents only
• tool response — preview, agents only
• output

Those middle two are the ones most home-grown guardrail stacks lack, and they are where agent-specific risk actually lives. Classification models behind the controls come from Azure AI Content Safety.

Prompt Shields covers two attack types explicitly. User prompt attacks — jailbreaks — are scanned at user input. Document attacks — hidden instructions embedded in third-party content, i.e. indirect or cross-prompt injection (XPIA) — are scanned at both user input and tool response. Responses carry annotations with detected/filtered booleans, so you get the telemetry, not just the block. Foundry’s agents documentation names XPIA as a mitigated risk directly.

One enforcement precondition that is easy to miss: tool-call and tool-response scanning requires moderation support from the tool itself, and Microsoft publishes a supported-tool list (Azure AI Search, Azure Functions, OpenAPI, SharePoint Grounding, Fabric Data Agent, Bing Grounding, Bing Custom Search, Browser Automation). Controls configured at those points do not take effect for tools outside the list — so a custom or third-party MCP tool is unscanned unless you check. That matters precisely because tool response is the placement this lesson recommends most strongly.

Spotlighting (preview) is a different and interesting move: rather than classifying the injection, it tags third-party document content and base-64 encodes it so the model treats it as less trustworthy than user and system prompts. It is off by default, carries no direct cost, but inflates document token counts — and as of this check it is available only for models used via the Chat Completions API, with a documented side effect that the model may mention the base-64 encoding in its answers.

Two more Foundry surfaces belong on your map. Toolbox-level guardrails apply Responsible AI policies to tool inputs and outputs centrally, alongside credential injection and token refresh. And network egress controls (preview) are configured inside the same guardrail object, governing which outbound destinations an agent may reach — the only place in this lesson where a managed guardrail product reaches into the containment layer. Egress controls apply to hosted agents only.

Caveat with real design consequences: agent guardrails are in preview, and guardrails currently apply to Foundry Agent Service agents — not to other agents merely registered in the Foundry Control Plane.

Google Cloud — Gemini safety filters, Model Armor + Semantic Governance

Google’s platform is now branded Gemini Enterprise Agent Platform (the product page carries “formerly Vertex AI”, and the Vertex AI docs banner says its services are now part of Agent Platform). Expect to meet both names in the wild.

The model-level layer is configurable content filters over four harm categories — HARM_CATEGORY_HATE_SPEECH, HARM_CATEGORY_DANGEROUS_CONTENT, HARM_CATEGORY_HARASSMENT, HARM_CATEGORY_SEXUALLY_EXPLICIT — each with a threshold you set: BLOCK_LOW_AND_ABOVE, BLOCK_MEDIUM_AND_ABOVE, BLOCK_ONLY_HIGH, OFF, BLOCK_NONE, or unspecified. Two harm-block methods exist: SEVERITY (the default, using probability and severity scores) and PROBABILITY. Blocked responses come back with finishReason: SAFETY and per-category safetyRatings carrying probability and severity — usable telemetry if you log it.

The default that catches teams out: the docs state that for gemini-3.5-flash and subsequent models, OFF is the default value, while the REST reference lists BLOCK_MEDIUM_AND_ABOVE as the default for older models. If your catalog row for content harms says “handled by the platform”, on a current model that row may be doing nothing until you set thresholds explicitly. Set them in code, and assert them in a test.

Some filters are non-configurable and cannot be turned off: child sexual abuse material (CSAM) and personally identifiable information (PII/SPII). Blocked prompts return the PROHIBITED_CONTENT enum; responses can stop with an SPII finish reason.

The agent-layer control is Semantic Governance Policies: documented as “natural language constraints that you configure to govern AI agents through their tool calls”, applying to all agents on Agent Runtime. That is catalog rows 3 and 6 expressed in prose rather than code — powerful for expressing intent, and worth remembering that a natural-language policy is evaluated by a model, so it carries an error rate that Cedar-style deterministic rules do not. Pricing is metered as 1 Agent Compute vCPU-hour per 15,000 agent-model response evaluations, plus evaluation-model tokens, with billing commencing later in 2026 — so budget for it before it starts billing.

Where the gap actually is: the gap is in the Gemini safety filters, not in the platform. The configurable filters cover harm categories only — they do no injection detection. The injection row is answered elsewhere in Google Cloud: Model Armor ships a prompt-injection and jailbreak detection filter with configurable confidence thresholds and inspect-only or inspect-and-block enforcement, and documents integrations with Agent Platform, Agent Gateway and Gemini Enterprise. So read this platform as two layers, not one: model-level harm filters plus a separate screening product you attach deliberately. Verify Model Armor’s launch stage and per-integration limits (document screening is Gemini Enterprise only) before you rely on it, and re-check the current docs either way.