Guardrails, security, and network isolation

Concept 14 showed how evaluations and the AI Red Teaming Agent surface unsafe answers, weak tool use, and adversarial tricks before users see them. Guardrails are the production controls that enforce those lessons on every request. A guardrail is a named set of controls in Microsoft Foundry. Each control names a risk to detect, one or more intervention points where Foundry scans for that risk, and an action to take when the risk is found.

Foundry applies guardrails to models sold by Azure and to agents built in the Foundry Agent Service. Agent guardrails are in preview. Guardrails use classification models from Azure AI Content Safety to flag harmful content. The guardrail system covers Foundry models sold by Azure except prompts and completions processed by audio transcription models. It does not apply to other agents that are only registered in the Foundry Control Plane without being developed in the Foundry Agent Service.

• You need a Foundry project, at least one model deployment, and a role that can manage guardrails, such as Foundry Account Owner.
• One guardrail can attach to many models and many agents in the same project.
• API configuration and app design can change how filtering behaves, so treat guardrails as part of your full design, not a switch you set once.
• Hosted agents can also use network egress controls (preview) in the same guardrail to limit outbound destinations; those rules apply only to hosted agents.

An agent that calls tools can fail in places a chat model never sees: unsafe arguments on the way out, or poisoned text coming back from a tool. Foundry therefore scans at four intervention points. User input is the prompt a person sends. Output is the final completion returned to that person. Tool call (preview) is the action and data the agent proposes to send to a tool, including which tool and its arguments. Tool response (preview) is what the tool returns inside the agent run, before it is stored in agent memory or shown to the user.

When you create a guardrail in the Foundry portal, you pick controls and assign each control to intervention points. For example, to block indirect attacks in tool responses, add an Indirect attack control, set the intervention point to Tool response, and choose Annotate and block as the action. Tool call and tool response checks need moderation support from the tool itself. Today that includes Azure AI Search, Azure Functions, OpenAPI, SharePoint Grounding, Fabric Data Agent, Bing Grounding, Bing Custom Search, and Browser Automation. If the agent uses other tools, controls at those two points do not run for those tools. Guardrail processing at each point adds about 50–100 ms of latency, depending on content length and how many controls are active.

For content risks such as Hate, Sexual, Self-harm, and Violence, each control uses a blocking level that decides which severity is stopped. Off means nothing is blocked for that risk, though annotations may still be returned. Low blocks only high-severity content and is the least restrictive setting available to all customers. Medium blocks medium- and high-severity content. High blocks low-, medium-, and high-severity content and is the most restrictive. All customers can turn off content harms for inputs; turning them off for outputs requires approved modified guardrails for models sold by Azure.

• Harm categories: Hate, Sexual, Self-harm, and Violence apply to both models and agents (agents in preview).
• User prompt attacks and Indirect attacks apply to models and agents; use them at user input, output, and— for agents—tool call or tool response as needed.
• Groundedness (preview) and Spotlighting (preview) apply to models but not to agents; if those controls sit on a shared guardrail, they still run for models but not for agents using the same name.
• Personally identifiable information (preview) and Task Adherence (preview) apply to both models and agents. Protected material for code and for text apply to both.
• When a risk is found, models can use Annotate or Annotate and block. Agents (preview) support Annotate and block only, not Annotate alone.

The capability reference groups related filters under trust and safety: harm category filters, Prompt Shields for jailbreak and prompt injection, groundedness detection, sensitive data (PII) detection, protected material detection, and task adherence for when an agent drifts from its assignment.

Models and agents can share one guardrail definition, but not every control runs on both. Controls tied to tool calls or agent-only risks simply skip model runs. More importantly, when an agent has its own guardrail assignment, that assignment fully replaces the guardrail on the underlying model deployment for agent traffic. Foundry detects risks on the agent using the agent guardrail, not the model guardrail.

Default rules help you predict behavior. Model deployments start with the Microsoft.DefaultV2 guardrail unless you change it. For agents, if you assign a custom guardrail, that guardrail is used. If you assign none, the agent inherits the guardrail from its model deployment. The agent uses Microsoft.DefaultV2 only when its deployment uses that guardrail or you assign it explicitly.

• If agent behavior does not match the guardrail you expect, confirm the guardrail is assigned to the agent in the Foundry portal or SDK, not only to the model.
• Remove or replace controls that rely on agent-unsupported preview risks such as Groundedness or Spotlighting when you tune agent safety.
• If harmful content passes through tools, verify controls exist for Tool call and Tool response and that preview features for the Foundry Agent Service are enabled for the project.
• If legitimate content is blocked, try a lower blocking level for that risk before you assume the classifier is wrong.

Imagine a Foundry prompt agent for an online shop. It reads order status from Azure AI Search and can trigger a refund function. Red teaming in Concept 14 showed jailbreak attempts on user input and indirect injection in search snippets. You create a guardrail named ShopSupportSafety in the Foundry portal and attach it to the agent, not only to the GPT deployment.

• At User input, enable User prompt attacks with Annotate and block so jailbreak prompts never reach the model.
• At Tool call (preview), add Violence or Hate at Medium if refunds or customer notes could carry harmful text into the function.
• At Tool response (preview), add Indirect attack with Annotate and block because search results may contain hidden instructions.
• At Output, keep Sexual, Self-harm, Violence, and Hate at Medium, and add Protected material for text if answers must not echo copyrighted policy text verbatim.
• Confirm Azure AI Search and Azure Functions are in the supported tool list so tool-stage controls actually run.

Suppose the model deployment uses Violence at High on input and output, but the agent guardrail sets Violence to Low on input and output and adds no Violence checks on tool stages. User messages and final answers are scanned at Low severity. Tool calls and tool responses are not scanned for Violence unless you add controls at those intervention points. That override pattern is deliberate: the agent guardrail is the source of truth for agent sessions.

Guardrails filter content; network isolation limits who can reach Foundry and where agent traffic may go. Microsoft Foundry splits the problem into inbound access to the Foundry resource, outbound access from the Foundry resource to other Azure services, and outbound access from the Foundry Agent client to dependencies such as private data sources or approved internet endpoints through virtual network injection.

For inbound isolation on a new resource, open the Azure portal, search for Foundry, select Create a resource, complete Basics, open the Networking tab, choose Disabled for public access, then select + Add private endpoint and match the region to your virtual network. For an existing resource, open Resource Management, Networking, Private endpoint connections, and select + Private endpoint. Approve the connection so status shows Approved; pending connections cannot carry traffic.

• Platform services such as the Foundry project, storage, Key Vault, container registry, and monitoring use Private Link for isolation.
• For agents, Foundry injects the Agent client into a customer-managed subnet instead of asking you to run separate compute for the service.
• Standard setup expects you to bring Azure Storage, Azure AI Search, and Azure Cosmos DB so agent data stays in your tenant; Basic setup can create managed resources during deployment.
• When you enable outbound virtual network injection, pick a subnet delegated to Microsoft.App/environments with size /27 or larger. Private endpoints to Search, Storage, and Cosmos DB are not created automatically—you add them on each resource.
• You cannot add outbound virtual network injection to an existing deployment later; redeploy Foundry to change outbound networking or the delegated subnet.

Foundry encrypts stored data with Microsoft-managed keys by default, using FIPS 140-2 compliant 256-bit AES. Customer-managed keys (CMKs) in Azure Key Vault or Azure Managed HSM add control over rotation, revocation, and auditing. CMK enforcement has limits: some capabilities need you to bring your own storage before CMK applies, and runtime compute may briefly unwrap data in memory even when rest storage is CMK-protected.

• For prompt agents with CMK, use bring-your-own Azure Cosmos DB, Storage, and Azure AI Search and configure CMK on each of those services separately.
• Hosted agent sandbox compute is ephemeral, but each session has a persistent $HOME filesystem on platform-managed storage that is not CMK-encrypted today.
• Revoking an active CMK blocks access to data encrypted with that key; fine-tuning downloads and new deployments can fail until access is restored.
• CMK for Azure AI Search is available only in select regions because of platform capacity; check regional availability before you design.
• Assuming model-level guardrails protect an agent after you assign a different guardrail to the agent.
• Enabling tool response controls while the agent calls tools that do not support moderation.
• Disabling public access but skipping private DNS, so clients inside the virtual network still resolve the public IP.
• Choosing Basic agent storage when policy requires CMK on agent state—you need customer-managed storage and partial CMK support at best for hosted agents.

Pair guardrails with the evaluation and red-team baselines you built in Concept 14, then validate network paths from a machine inside the virtual network before you promote an agent. Concept 16 covers governance at scale: control plane fleet monitoring, publishing, resilience, and cost controls that sit above single-project guardrails and private endpoints.

• Default guardrails, risk tables, blocking levels, and agent override rules. Guardrails and controls overview in Microsoft Foundry
• Step-by-step control setup, supported tools, and latency notes. Intervention points
• Private endpoints, virtual network injection, and tool traffic patterns. Configure network isolation for Microsoft Foundry
• CMK coverage by capability and compute stack limits. Customer-managed key encryption in Microsoft Foundry