Prompt Injection Guardrails: AWS vs Azure Compared

Prompt injection guardrails from the two biggest clouds work only when they are wired the way each platform expects, and both hide a default that silently weakens protection: Amazon Bedrock will not filter prompt attacks unless you tag user inputs explicitly, and Azure leaves document attack detection off until you enable it yourself. Protection that exists but is not active is where most teams get burned. This guide compares the two implementations, lists the defaults that matter, and gives a setup order you can apply to a production endpoint this week.

How Each Guardrail Works

Amazon Bedrock Guardrails exposes a dedicated PROMPT_ATTACK filter alongside its content filters. It recognizes three attack classes: jailbreaks that try to bypass the model’s own safety training, prompt injection that tries to override developer instructions, and prompt leakage that tries to extract the system prompt. The last class is only available in the Standard content filter tier, not the Classic tier, which matters if you inherited an older guardrail configuration. Microsoft splits the same problem differently. Prompt Shields analyze two channels: a user prompt attack channel that scans what users type, and a document attack channel that scans retrieved documents, emails and web pages for hidden instructions that try to hijack the model session. The two vendors disagree on where the filter lives: Bedrock evaluates the tagged portion of the prompt inside the InvokeModel call, while Azure offers both an in-line filter on Foundry model deployments and a standalone Azure AI Content Safety API that only annotates, leaving the blocking decision to your application.

Bedrock Prompt Attack Setup

Follow this order, because the tagging step is the one that breaks silently:

1. Create a guardrail in the Bedrock console or with the CreateGuardrail API and set a filter with type PROMPT_ATTACK in the contentPolicyConfig.
2. Choose the action: Block replaces the content with your blocked-input message, while Detect (inputAction NONE) returns detection information without intervening.
3. Set the inputStrength threshold to Low, Medium or High, and pick the Classic or Standard content filter tier.
4. Wrap every user-controlled span of the prompt in the guardContent input tags before calling InvokeModel or InvokeModelWithResponseStream.

The fourth step is not optional hygiene. Without the tags, the filter simply does not evaluate the user portion of your prompt, so a guardrail that passed a console test can sit inert in production. Agent builders should also note a hard boundary: the prompt attack filter never evaluates tool results or tool definitions, so instructions that arrive through tool outputs bypass this control entirely and need a separate path, such as scanning tool responses in your own middleware. If you run the serving layer yourself instead of on Bedrock, the guardrail question moves into your stack — our writeups on autoscaling GPU serving by queue depth and HNSW index tuning for retrieval cover the plumbing that sits behind whatever filter you build.

Azure Prompt Shields Setup

On Microsoft Foundry the split defaults are the trap: user prompt attack detection is on by default while document attack detection is off by default, so a RAG pipeline that ingests external pages is unprotected on the exact channel that indirect prompt injection prefers. Configure in this order:

1. In the Foundry portal, open Guardrails and create a guardrail with the User prompt attack risk selected at the user input intervention point.
2. Add the Document attack risk and choose the intervention point — user input for model API calls, or tool response for agents on supported tools.
3. Choose annotate or block per control; each result returns detected and filtered flags you should log.
4. If you use the standalone Azure AI Content Safety API instead, submit the userPrompt and the documents array, and implement your own blocking logic on the attackDetected response.

For document-heavy workloads, Azure adds an extra layer called Spotlighting. It transforms third-party document content so the model treats it as less trustworthy than direct prompts, but spotlighting has no direct cost yet inflates document tokens through base-64 encoding, which can raise the bill and push large documents past input size limits. A known side effect is that model responses mention base-64 encoding even when nobody asked about it, so test the user experience before rolling it out.

Coverage Compared

Non-English Limits

For teams serving users in Portugal and the rest of the EU, there is a second, quieter gap. Microsoft states plainly that the detection models are primarily trained and evaluated on English content, and performance can vary for non-English inputs. That means a threshold tuned on English red-team prompts is an untested guess for Portuguese, Spanish or French traffic. Before trusting a block action, run your own evaluation set: a few dozen representative attacks and an equal number of benign prompts in every language your product actually serves, then measure false positives on the benign set. If the false-positive rate is unacceptable, run document and prompt scanning in annotate mode, log the detected flags, and escalate flagged turns to human review for the first weeks. Treat vendor guardrails as a detection signal you calibrate, not a compliance checkbox you tick.

Sources

• AWS — Detect prompt attacks with Amazon Bedrock Guardrails
• Microsoft — Prompt Shields in Azure AI Content Safety