Quick answer. As of September 2026, govern AI built in Microsoft Foundry with Entra ID sign-in and Foundry roles, an assigned guardrail with Prompt Shields, Purview with user-context tokens, Defender for Cloud AI threat protection and Azure Policy, in that order. Per Microsoft, “Agent guardrails are in preview”.
Two limits Microsoft states shape the order. Microsoft’s Role-based access control for Microsoft Foundry, read on 2026-09-23, says that with key-based authentication “the key grants full access without role restrictions”. And Microsoft’s AI threat protection in Microsoft Defender for Cloud, read the same day, lists its cloud availability as “Commercial clouds: Yes” and “Azure Government: No”.
When the Security Review Hears That the App Inherits Azure Controls
When a Foundry app reaches its security review, someone will say it sits in Azure and inherits Azure’s controls. The subscription around the app may well be governed already. The controls specific to the model, the agent and the prompts are configuration someone still has to do. Microsoft’s What are hosted agents?, read on 2026-09-23, says in its guidance on connecting an agent to other systems and services: “It is your responsibility to manage whether your data will flow outside of your organization’s compliance and geographic boundaries and any related implications, and that appropriate permissions, boundaries, and approvals are provisioned.”
This page assumes Foundry is already the platform. If that choice is still open, start with Copilot Studio vs Azure AI Foundry: Which One Fits Your Compliance Posture?. What follows names the Microsoft control that logs, blocks or alerts on each risk once the app is built in Foundry, and what each one does not reach.
If the App Still Uses Keys, Start with Identity
If developers built the first version against an API key, no role assignment governs that access. Microsoft’s RBAC page for Foundry, cited above, says: “RBAC roles apply when you authenticate using Microsoft Entra ID. If you use key-based authentication instead, the key grants full access without role restrictions. Microsoft recommends using Entra ID authentication for improved security and granular access control.”
With Entra ID in place, Microsoft’s examples on the same page assign roles to Entra groups rather than to individuals, and they include: “To build agents, run traces, and use core Foundry capabilities, assign Foundry User to the Microsoft Entra group.” And: “To allow interaction with agents without broader development access, assign Foundry Agent Consumer to the Microsoft Entra group.” That second role is the one that keeps people who use an agent separate from people who build it.
Hosted agents carry identities of their own. Microsoft’s hosted agents page, cited above, says: “Every Hosted agent deployed to a Foundry project gets its own dedicated Microsoft Entra ID (agent identity) and dedicated endpoint”. It also says: “For external resources (for example, your own Azure Storage), assign RBAC roles manually to the agent’s Microsoft Entra ID.” An agent identity given broad roles for convenience reaches everything those roles cover, so its roles are scoped like any other identity’s.
When You Assume the Default Filter Covers the Agent
When a team says content filtering is on, the question is which guardrail each model deployment uses and, for agents, where guardrails are in preview, which guardrail each agent uses. Microsoft’s Guardrails and controls overview in Microsoft Foundry, read on 2026-09-23, says “Microsoft Foundry provides safety and security guardrails that you can apply to core models and agents. Agent guardrails are in preview.” It defines the unit plainly: “A guardrail is a named collection of controls.”
The default behavior matters more than the menu. According to Microsoft’s guardrails page:
- “By default, models are assigned the Microsoft.DefaultV2 guardrail.”
- “If no custom guardrail is assigned, the agent inherits the guardrail of its underlying model deployment.”
- “Risks are detected in an agent based on the guardrail it’s assigned, not the guardrail of its underlying model. The agentic guardrail fully overrides the model’s guardrail.”
- “The guardrail system currently applies only to agents developed in the Foundry Agent Service, not to other agents registered in the Foundry Control Plane.”
- “Some risks in Preview aren’t yet supported for agents. When controls involving those risks are added to a guardrail and the guardrail is applied to an agent, those controls don’t take effect for that agent.”
Read together, and with agent guardrails in preview, an agent given its own guardrail is checked against that guardrail and not its model deployment’s, and a control for a preview risk that agents do not yet support does not take effect for the agent. Nor can content filtering on models sold by Azure be switched off at will: “For Models sold by Azure, only customers who have been approved for modified Guardrails can turn them off.”
Prompt Shields sit inside the same guardrail. Microsoft’s Prompt Shields in Microsoft Foundry, read on 2026-09-23, says “Prompt Shields detects and blocks adversarial inputs to large language models” and “In Foundry, Prompt Shields is part of the guardrails and controls”. Its table of attack types lists two: user prompt attacks, “Previously called Jailbreak risk detection”, and document attacks carried in third-party content such as documents and emails. When a shield does not fire, Microsoft’s first troubleshooting step is: “Verify the guardrail is assigned to your deployment or agent.”
When Purview Policies Do Not Reach the App
If your Purview policies already govern Microsoft 365, it is reasonable to expect them to reach a Foundry app. Microsoft’s Use Microsoft Purview to manage data security & compliance for Microsoft Foundry, read on 2026-09-23, lists what reaches Foundry and the conditions attached.
First, Purview has to be connected, by either of two configuration steps Microsoft lists: “Enable Microsoft Purview Data Security in the Microsoft Foundry Control Plane using the Microsoft Foundry portal.” Or: “Enable Microsoft Purview Data Security for Microsoft Foundry in Microsoft Defender for Cloud in your Microsoft Azure portal.”
Second, audit and policy management come under different terms. The same Purview page says: “Managing policies for Microsoft Foundry AI interactions with Microsoft Purview requires you to enable pay-as-you-go billing in your organization. Note that Microsoft Purview Audit includes Microsoft Foundry data as part of the Microsoft Purview license.” Microsoft’s Audit logs for Copilot and AI applications, read the same day, lists “custom applications built using Microsoft Copilot Studio and Microsoft Foundry” among the Microsoft applications “included in Audit Standard”.
Third, policies act only when the call carries user context. Microsoft’s Purview page for Foundry says: “Microsoft Purview Data Security Policies for Foundry Services interactions apply to API calls that use Microsoft Entra ID authentication with a user-context token, or for API calls that explicitly include user context.” And: “For all other authentication scenarios, user interactions are displayed in Microsoft Purview Audit and AI Interactions with classifications in DSPM for AI Activity Explorer only.” In practice, an app that calls the model under its own identity, without passing user context, falls in that second group: audit records, no policy enforcement.
The rest of what Microsoft documents for Foundry on the same page includes:
- Audit: “Like other activities, prompts and responses are captured in the unified audit log.”
- Data loss prevention: “Support today is only available for a DLP policy that blocks prompts based on sensitive information types. This requires the configuration of a PowerShell cmdlet that’s scoped to a specific Entra-registered AI app.”
- Retention: Microsoft’s steps “create a retention policy to retain interactions with Microsoft Foundry by selecting the location Enterprise AI apps”.
- eDiscovery: Microsoft’s steps create an eDiscovery case and a search for these interactions.
Under retention and under eDiscovery, Microsoft notes a prerequisite for prompts and responses: each “requires a collection policy”.
When the Subscription Is in Azure Government
If the app runs in an Azure Government subscription, check the threat-alert layer before anything else. Microsoft’s Defender for Cloud page, cited above, describes the plan this way: “Defender for Cloud’s AI threat protection works with Azure AI Content Safety Prompt Shields and Microsoft’s threat intelligence to provide security alerts for threats like data leakage, data poisoning, jailbreak, credential theft, and more.” It adds: “Defender for Cloud currently supports text tokens only. Image and audio tokens aren’t scanned.”
Its availability block lists “Commercial clouds: Yes” and “Azure Government: No”. Microsoft’s Support matrices for Defender for Cloud, read on 2026-09-23, agrees: under its note that “NA indicates that the feature isn’t available”, the Defender for AI Services plan reads GA for Azure and NA for Azure Government, and the AI services features on the same table, “Suspicious prompt evidence”, “Data security for AI interactions” (preview in Azure), “AI model security” (preview in Azure) and the data and AI security dashboard, are NA for Azure Government.
So a Foundry app in a government subscription cannot count on a Defender alert for prompt attacks, and any control planned in its place is confirmed available in that region before the design depends on it. The same check applies to every other control on this page; this page states no other government-cloud availability. If part of the estate runs hybrid, the platform question is covered in Which AI Platform Best Supports Hybrid Cloud Deployments in Highly Regulated Environments?.
When a Setting Needs to Hold After the Pilot Team Leaves
Settings made by hand in one project drift once the next team builds the next app. Microsoft’s Cloud Adoption Framework page Guidance to set up your organization’s AI governance process, read on 2026-09-23, says its process “follows the NIST Artificial Intelligence Risk Management Framework (AI RMF) and NIST AI RMF Playbook”; which framework your organization adopts is covered in Which AI Governance Framework Should a Regulated Enterprise Adopt?.
The same Microsoft page advises: “Use platforms like Azure Policy and Microsoft Purview to enforce policies automatically across AI deployments, and regularly assess areas where automation can improve policy adherence.” It pairs that with manual enforcement where automation is insufficient. Microsoft’s Govern Azure platform services (PaaS) for AI, read the same day, is specific about models: “Model governance sets controls to keep AI models safe, reliable, and ethical. It uses Azure Policy to restrict which models can be deployed.”
Microsoft’s Azure Policy built-in policy definitions for Foundry Tools, read on 2026-09-23, lists the built-in definition “Foundry model deployments should only use approved models”, which Microsoft describes as applying to “model deployments in Microsoft Foundry” so that they “only use models explicitly approved by the organization, based on configured model identifiers or publishers.” Its listed effects are “Audit, Deny, Disabled”. Which effect to assign, Audit or Deny, is your organization’s decision. Azure Policy fundamentals outside AI are covered in Azure Security Best Practices: The Basics Enterprises Still Get Wrong.
In Foundry itself, Microsoft’s What is Microsoft Foundry Control Plane?, read the same day, describes where these come together: its Compliance pane lets you “Define and enforce protections through deep integrations with Azure Policy, Defender, and Microsoft Purview.”
When This Order Is the Wrong One
The order above is i3’s recommendation, not Microsoft’s, and it is wrong in three situations.
A prototype on synthetic data with no user-facing endpoint does not need Purview policy management, and the pay-as-you-go billing it requires, on day one; identity and guardrails still apply from the first deployment.
An estate whose AI runs in Copilot Studio rather than Foundry is governed through Power Platform instead, and the comparison page linked above covers that choice.
A subscription in Azure Government cannot lean on Defender’s AI plan, per Microsoft’s availability listing cited above, so the weight shifts to the other controls on this page, each confirmed available in that cloud first.
What These Controls Do Not Replace
When the review asks who is accountable for the AI system, no control on this page answers it: each one logs, blocks or alerts, and accountability sits in the governance model covered by Enterprise AI Governance for Microsoft Environments. The records these controls produce are also evidence a framework mapping can use, which is a separate piece of work from switching them on.
When an Outside Architect Is Worth the Call
When the control design has to be written down before the review, an outside architect is useful for four design tasks in this sequence: auth and role design, guardrail assignment policy, Purview enablement and user-context design, and subscription-level policy. For the build itself, see Custom AI Copilot Development on the Microsoft Stack.
i3solutions maps governance to named control families, enforces it in the platform through Entra ID, Purview, and Azure Policy, and evidences it continuously rather than reconstructing it at audit.
Delivery is senior and US-based. An i3solutions engagement does not produce managed-service ownership, a replacement for the internal team, open-ended scope expansion, or vendor lock-in. Your own team runs the controls once the design is handed over, and the wider practice is in Custom AI Consulting Services for Governed Microsoft Enterprise AI.
Key Takeaways
- Work in this order: identity and Foundry roles first, then guardrails and Prompt Shields, Purview with user context, Defender for Cloud where your cloud offers it, and Azure Policy last.
- According to Microsoft, a key grants full access without role restrictions, so key-based access sits outside every role assignment.
- An agent’s assigned guardrail fully overrides its model’s guardrail, and Microsoft says agent guardrails are in preview.
- According to Microsoft, Purview data security policies act on Foundry calls only with user context; other calls reach audit and activity explorer only.
- Microsoft lists Defender for Cloud’s AI threat protection as not available in Azure Government.
Frequently Asked Questions
How do you govern AI built in Microsoft Foundry?
Switch on Microsoft’s controls in order: Entra ID authentication with Foundry roles in place of keys, an assigned guardrail with Prompt Shields for each model deployment and, in preview, each agent, Purview Data Security with user-context tokens, Defender for Cloud AI threat protection where the cloud offers it, and Azure Policy at the subscription. According to Microsoft, agent guardrails are in preview.
Does Microsoft Purview cover Azure AI Foundry apps?
Yes, once Purview Data Security is enabled from the Foundry portal or from Defender for Cloud. According to Microsoft, audit of Foundry data is part of the Purview license, while managing policies requires pay-as-you-go billing, and data security policies apply only to calls that carry user context; other calls appear in audit and activity explorer only.
Is Defender for Cloud AI threat protection available in Azure Government?
No. Microsoft’s Defender for Cloud documentation lists AI threat protection as available in commercial clouds and not in Azure Government, and its support matrix marks the Defender for AI Services plan as not available there.
Do Foundry agents use the model’s content filter or their own?
It depends on assignment. According to Microsoft, agent guardrails are in preview; an agent with no custom guardrail inherits its model deployment’s guardrail, while an agent with its own guardrail uses that guardrail alone, which fully overrides the model’s. Some preview risk controls do not take effect for agents.
Why should Foundry apps not use API keys?
Because, according to Microsoft, Foundry role assignments apply when you authenticate with Microsoft Entra ID, while a key grants full access without role restrictions. Microsoft recommends Entra ID authentication, and Purview data security policies apply only to calls that carry user context.
Plan the Controls for Your Foundry App
If a Foundry app is heading into its security review and the control design is not written down yet, the next step is a conversation about your estate.
