Guardrail Limits
Azure Prompt Shields in 2026: Limits, Pricing, and What It Does Not See
Prompt Shields is Microsoft's managed detector for jailbreaks and indirect prompt injection. The limits that decide what it can see (10,000 characters per call, five documents, and a 1,000-character window inside Foundry guardrails) matter more than the marketing. Here they are with October 2026 prices and a test plan.
TL;DR (October 2026):
- The standalone Prompt Shields API (
text:shieldPrompt, api-version2024-09-01) accepts a user prompt of up to 10,000 characters plus up to five documents totalling 10,000 characters. - Inside Microsoft Foundry guardrails, Microsoft documents that only the first 1,000 characters of text are moderated. Anything past that is outside the guardrail's view.
- The free F0 tier gives 5,000 text records a month at 5 requests per second. S0 runs at 1,000 requests per 10 seconds and lists at $0.375 per 1,000 text records in East US. One text record is up to 1,000 characters.
- The verdict is a single boolean per input (
attackDetected). There's no score and no threshold to tune, and Microsoft says Prompt Shields was tested with English only.
Prompt Shields is the prompt injection detector in Azure AI Content Safety. Microsoft renamed it from "Jailbreak risk detection" in March 2024 and made it generally available in August 2024. It's now one control inside the Foundry guardrails system. Most teams switch it on and never read the limits page. That page holds the numbers that decide what Prompt Shields can see, what it costs, and where a pentester should put a payload. This page collects them from Microsoft's documentation and price list as of October 2026.
Prompt Shields limits and pricing at a glance
| Item | Value (October 2026) | Source |
|---|---|---|
| Max user prompt length (standalone API) | 10,000 characters | Content Safety service limits |
| Documents per call | Up to 5, total 10,000 characters | Content Safety service limits |
| Text moderated by Foundry guardrails | First 1,000 characters | Content Safety service limits |
| Current GA API version | 2024-09-01 | Prompt Shields quickstart |
| F0 (free) quota | 5,000 text records per month | Azure pricing page |
| F0 rate limit | 5 requests per second | Content Safety overview |
| S0 rate limit | 1,000 requests per 10 seconds | Content Safety overview |
| S0 pay-as-you-go price | $0.375 per 1,000 text records (East US list price) | Azure retail prices API |
| Text record size | Up to 1,000 Unicode code points; 7,500 characters = 8 records | Azure pricing page |
| Text commitment tier | 1M text records a month for $338, overage $0.338 per 1,000 | Azure retail prices API |
| Language testing | English only (may work in others, quality varies) | Region availability page |
| Spotlighting | Preview, off by default, Chat Completions API only, no direct cost | Prompt Shields concepts |
Prices differ by region and currency, and the public pricing page renders them from a calculator. The figures above come from Microsoft's own retail prices API for the eastus region and the "Content Safety" product. Check your region before you budget.
What Prompt Shields actually detects
Microsoft splits the feature into two shields, and they work at different points in the request.
Shield for user prompts
This shield catches direct attacks, where the person typing is the attacker. Microsoft lists four subtypes:
- Attempt to change system rules: asking for an unrestricted assistant, or telling the model to ignore its rules and earlier turns.
- Embedding a conversation mockup: fake conversation turns pasted into one message.
- Role-play: a persona without the system's limits, or giving the system emotions and opinions.
- Encoding attacks: character transformations, ciphers, generation styles and other variations meant to slip past the rules.
Shield for documents
This shield catches indirect attacks: instructions hidden in third-party content such as emails, files and web pages. Its categories are manipulated content, access to system infrastructure, information gathering, availability, fraud and malware. The four user-prompt subtypes apply to documents too. In Foundry, document attacks are scanned at both the user input and the tool response intervention points. User prompt attacks are scanned at user input only.
That tool response hook matters for agent builders. It's one of the few managed guardrails that claims to inspect what a tool returns, and tool output is where most indirect injection lands in practice. We cover that in indirect prompt injection in browser agents. Compare Amazon Bedrock Guardrails: its prompt attack filter does not evaluate tool results at all in the Converse API.
The API shape and what the response leaves out
The standalone call is a POST to {endpoint}/contentsafety/text:shieldPrompt?api-version=2024-09-01 with two fields: userPrompt (a string) and documents (an array of strings). The response has userPromptAnalysis.attackDetected and one documentsAnalysis[].attackDetected per document. Both are booleans.
{
"userPromptAnalysis": { "attackDetected": false },
"documentsAnalysis": [ { "attackDetected": true } ]
}
Three things follow for anyone wiring this into production:
- There's no confidence score. You can't move a threshold to trade false positives for recall. To change sensitivity you change what you send: shorter segments, cleaned markup, or the document field instead of the prompt field.
- The subtype isn't returned. The concept page lists categories, but the standalone response doesn't say which one fired. Triage false positives by replaying inputs, not by reading a label.
- The documents field is per call, not per conversation. Five documents and 10,000 characters is enough for a few retrieved chunks. A long RAG context or a large tool result has to be split across several calls, and each one is billed.
Through Foundry the shape changes. The completion carries annotations with detected and filtered booleans under prompt_filter_results, and a guardrail can be set to block or only annotate. Microsoft's troubleshooting advice for false positives is to move from block to annotate and log the hits. That works for a pilot. Left in place, it means nothing is blocked.
Why the character limits are the real attack surface
Every input classifier has a window, and an attacker's first question is where that window ends. Prompt Shields has two.
The 10,000-character API window. If your code truncates text to fit the limit before calling the API, everything after the cut is never scanned. If you send oversized input without truncating, check how your client handles the error. A wrapper that treats an error as "no attack" fails open, and long inputs bypass detection.
The 1,000-character Foundry window. Microsoft's service limits page states that "the first 1000 characters for text scenarios will be moderated using Guardrails." Read literally, a payload placed after the first thousand characters of a long user message, or deep inside a long tool response, sits outside what the guardrail moderates. Test this on your own deployment before you rely on Foundry guardrails as the injection control for long inputs. Placing a payload at the start, in the middle and at the end of a long input is a cheap test, and it tells you a lot.
Pentest note: for any length-limited detector, the first three test cases are a payload at character 0, a payload just past the documented window, and a payload split across two chunks your application scans separately. The third one catches chunked scanning that never overlaps its windows.
What Prompt Shields costs in practice
Billing counts text records, not requests. A record is up to 1,000 characters, so a 500-character input is one record and a 7,500-character input is eight. Assuming each call counts as one text input, a chat app sending 1 million requests a month at about 2,500 characters each (prompt plus a couple of retrieved snippets) uses 3 records per call. That's 3 million records, which costs about $1,125 a month at the East US pay-as-you-go rate. The 1M-record commitment tier ($338 a month) only pays off if your volume is steady and close to that size.
The free tier works for prototypes and CI checks: 5,000 records a month is a few thousand short test prompts. At 5 requests per second it can't sit in front of real traffic.
Spotlighting: useful, with a cost Microsoft states plainly
Spotlighting is a preview feature for document attacks. The service base64-encodes document content and tags it as lower trust, so the model is less inclined to follow instructions inside it. Microsoft lists three trade-offs: base64 inflates the token count, which can raise model cost or push a long document past the input limit. It only works for models used through the Chat Completions API. The model may also tell users that the content was base64-encoded. It's off by default. If you enable it, re-run your quality evaluations, because some models handle encoded context worse than plain text.
Spotlighting is also a reminder that encoding works in both directions. The same base64 that marks a document as untrusted is a classic way to smuggle a payload past text classifiers. Our article on encoding-smuggling prompt injection covers the attacker side.
How to test a Prompt Shields deployment
- Map where it runs. Is it called on the user message only, on retrieved documents, on tool responses, or on all of them? Each gap in that list is a place to put a payload.
- Probe the windows. Put the same payload at different offsets in inputs of 900, 1,100, 9,900 and 10,500 characters. Note the verdict and whether the model complied.
- Swap the channel. Send a payload that's detected in
userPromptthroughdocumentsinstead, and the other way round. The two shields are trained for different threat models. - Go beyond English. Microsoft says the shields were tested in English only. Translate your detected payloads into the languages your users write in and measure the detection rate.
- Paraphrase until it passes. A boolean classifier still has a decision boundary. Rewrite detected payloads in plainer, less "attacky" language. Our piece on why prompt-injection filters keep failing explains why this nearly always works in the end.
- Score by action, not verdict. A missed detection only matters if the model then does something it shouldn't. Measure whether a tool fired, data left or a constraint broke.
Prompt Shields is a reasonable outer layer and costs little at chat-message sizes. It isn't a boundary. Pair it with tool scoping and human approval on irreversible actions, as set out in the 2026 LLM security checklist.
FAQ
- What is the maximum input size for Azure Prompt Shields?
- For the standalone Azure AI Content Safety API, the user prompt can be up to 10,000 characters, and you can add up to five documents with a combined total of 10,000 characters. When Prompt Shields runs as part of Microsoft Foundry guardrails, Microsoft documents that the first 1,000 characters of text are moderated.
- How much does Prompt Shields cost?
- Prompt Shields is billed as text records on the Content Safety S0 tier. A text record is up to 1,000 characters. As of October 2026 the East US pay-as-you-go list price is $0.375 per 1,000 text records, and a 1 million record monthly commitment is $338 with overage at $0.338 per 1,000. The F0 free tier includes 5,000 text records per month.
- What are the Prompt Shields rate limits?
- The F0 tier is limited to 5 requests per second. The S0 tier allows 1,000 requests per 10 seconds. Microsoft asks customers who need more to contact the Content Safety team.
- Does Prompt Shields return a confidence score?
- No. The standalone API returns a boolean attackDetected for the user prompt and for each document. In Foundry, annotations carry detected and filtered booleans. There is no numeric score or adjustable threshold for Prompt Shields.
- Does Prompt Shields scan tool outputs?
- In Microsoft Foundry, the document attack shield runs at the user input and tool response intervention points, so tool responses can be scanned for indirect attacks. The user prompt attack shield runs at user input only. If you call the standalone API, you decide what to send, so tool output is only scanned if your code passes it in the documents field.
- Which languages does Prompt Shields support?
- Microsoft states that Prompt Shields was tested with English only. It can work in other languages, but quality may vary, and Microsoft recommends doing your own testing.
- What is Spotlighting in Prompt Shields?
- Spotlighting is a preview feature that base64-encodes document content and marks it as lower-trust input so the model is less likely to follow instructions inside it. It has no direct charge, is off by default, works only with models used through the Chat Completions API, and increases token counts, which can raise model cost or push long documents past input limits.
Related reading
- Amazon Bedrock Guardrails prompt attack filter (2026): the AWS equivalent, with numeric scores and a tool-result gap.
- Google Model Armor pricing and limits (2026): the Google Cloud equivalent with a 65,536-token window.
- Llama Prompt Guard 2: 86M vs 22M: the open-weight classifier you can host yourself.
Microsoft's own description of the two shields and Spotlighting is on the Prompt Shields concepts page.