Guardrails, Prompt Shields and the tool-response scan

Lesson 3 of 5 in Microsoft Foundry Agents in Practice: Identity, Boundaries, Guardrails, Traces, Bills.

Foundry gives guardrails a precise structure, and learning the vocabulary is most of the work. A guardrail is a named collection of controls. Each control specifies three things: a risk to detect, the intervention points to scan, and a response action.

There are four intervention points, and the last two are what make this an agent feature rather than a chat feature:

user input — what the human sent
tool call — the arguments the model wants to send to a tool (preview, agents only)
tool response — what the tool sent back (preview, agents only)
output — what the model is about to say

The tool-response scan is the interesting one. A chatbot filter watches the two ends of a conversation. An agent reads documents, search results, web pages and API payloads mid-loop, and that content is attacker-reachable. Scanning tool responses is the platform admitting that tool output is untrusted input — the poisoning channel every agent has and most guardrail products ignore.

Where a Foundry control can intervene in the agent loop

User input
Intervention point 1. Jailbreak attempts and disallowed content are caught here — the classic chat filter position.
Model reasons over context
The model sees the system instructions, the conversation history and every tool result appended so far. Anything in that context can influence the next decision.
Tool call or final answer?
Model-directed control flow: the platform does not know in advance which way this goes, which is why controls attach to points rather than to steps.
Tool call scanned (preview)
Intervention point 2. The arguments the model wants to pass — a query, a recipient, a path — before the runtime executes anything.
Tool executes
Toolbox connections, MCP servers, OpenAPI tools, code interpreter, web and file search. This is where the agent touches the outside world.
Tool response scanned (preview)
Intervention point 3, and the agent-specific one. Prompt Shields document-attack detection runs here, looking for instructions hidden in returned content — cross-prompt injection.
Output scanned
Intervention point 4. The last chance before the response reaches the user or a downstream system.
Response delivered

Prompt Shields is the control most relevant to agents, and it detects two distinct attack types that people constantly conflate.

User prompt attacks are jailbreaks — the human in the conversation trying to talk the model out of its instructions. Scanned at user input. (This detector was previously called "jailbreak risk detection", which is why older material uses that name.)

Document attacks are hidden instructions embedded in third-party content — the class the Foundry agents documentation names cross-prompt injection attacks (XPIA), and what the rest of this academy calls indirect prompt injection. These are scanned at both user input and tool response, which is the whole point: the attacker is not the user, so watching the user is not enough. Responses come back with annotations carrying detected and filtered booleans, so your traces can tell you whether something was seen and whether it was blocked — two different facts.

Interactive sorting exercise: Each card is one thing that could go wrong. Sort it to the intervention point where a Foundry control would have the best chance of catching it — or to "no filter will catch this" when the answer is an authority problem rather than a content problem.

Spotlighting (preview) — make untrusted content look untrusted

A structurally different idea from classification. Spotlighting tags third-party document content and base-64 encodes it so the model treats it as less trustworthy than the user and system prompts. Instead of trying to spot the malicious sentence, it changes the status of the channel the sentence arrived on.

The documented trade-offs, as of September 2026: it is off by default, has no direct cost, but inflates document token counts — you pay for it in tokens, not licence fees. It is available only for models used via the Chat Completions API, and there is a known side effect where the model may mention the base-64 encoding in its answers. Check the current Prompt Shields page before designing around it.

Network egress controls (preview) — hosted agents only

Configured within the same guardrail (the Responsible AI policy), egress controls govern an agent’s outbound connections so it reaches only allowed destinations. They apply only to hosted agents.

This is the one control on the list that is not a classifier, and therefore the one an attacker cannot talk their way past: egress control is the reason a successful injection ends as a failed connection instead of an exfiltrated dataset. If you take one configuration action from this lesson, take this one.

Toolbox-level guardrails — govern the tool, not every agent

Guardrails (Responsible AI policies) can be applied to tool inputs and outputs at the Toolbox level, alongside centralized credential injection, token refresh and policy enforcement through Entra ID and OAuth identity passthrough.

The operational value is that the control lives with the tool. Ten agents consuming the same Toolbox inherit one policy and one credential story instead of ten drifting copies — the same argument as centralising a firewall rule rather than shipping it in every application.

What guardrails do not cover

They apply to Foundry Agent Service agents, not to every agent registered in the Foundry Control Plane. They are preview at the agent intervention points. They are classifiers, so they have false negatives — and a false negative on a document attack means the injected instruction reaches the model with your agent’s full authority.

Which is why the coverage question worth asking is not "is the filter on?" but "what happens on the run where it misses?" If the answer is "the agent could email customer data to an arbitrary address", the missing controls are egress, tool scope and RBAC — not a stricter filter.

Filters are one layer. They are not the defence.

Every capability in this lesson is real and worth turning on. None of them is a boundary. Prompt Shields and the content-safety controls are statistical classifiers operating on adversarial input, which means a determined attacker is playing a game they can eventually win on some fraction of attempts — and an agent that runs a thousand times a day only needs to be fooled once.

So treat guardrails as the layer that reduces volume and produces signal, and put the guarantees where the model cannot argue with them: narrow role assignments on the agent identity, tool scopes that cannot reach data the task does not need, egress allowlists so exfiltration has nowhere to go, and approval gates on irreversible actions. The guardrails catalogue in the security domain builds this out layer by layer; the Foundry-specific lesson is simply which layer each Azure feature is.

Key terms: guardrails, prompt injection, Prompt Shields, XPIA, tool-output poisoning, egress control

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.