Governing Multiple AI Models Against Microsoft 365 and Fabric Data in 2026

Most enterprises now run more than one AI model against the same Microsoft 365 and Fabric data: Microsoft 365 Copilot, agents in Copilot Studio, Azure OpenAI and Claude deployments in Microsoft Foundry, and sometimes a model router in front of them. This EPC Group guide sets out how to govern that estate with one set of rules for identity, retrieval authorization, routing, evaluation and logging. Every statement below comes from Microsoft Learn, read on November 7, 2026, and links are in the sources list at the end.

What multi-model AI governance has to cover

Multi-model AI governance is not a separate policy per model. It is one control set applied to every model that can reach company data, with the differences between models written down instead of assumed. Five questions decide it:

• Data path: who operates the model, under which terms, and where prompts are processed.
• Identity: whose permissions the model or agent uses when it reads data.
• Retrieval authorization: what stops retrieval from returning content the person asking can't see.
• Routing: which model is allowed for which class of data, and who can change that.
• Evaluation and logging: how you prove each model still behaves, and how you reconstruct what it read.

The data path, model by model

The same model family can sit under different terms depending on where you use it. Microsoft documents these differences directly:

Three consequences follow. First, "Claude" is two different governance cases: inside Microsoft's Copilot products the Microsoft DPA applies, while in Foundry Anthropic's own terms apply. Second, Microsoft turns Claude on by default for most commercial tenants outside the EU, EFTA and UK, so the decision has usually been made before anyone reviews it. Third, Claude models aren't available for federal customers in GCC or for any customers in GCC High and DoD, so a routing policy for a government tenant starts from a smaller list. For data at rest, Microsoft states that stored data, including the abuse monitoring store for Global and Data Zone deployments, stays in the customer-designated geography.

Identity: one identity model for every model

The most important control is the same for every model: the identity an agent uses decides what it can read.

• On behalf of the user. In the OAuth on-behalf-of flow, Microsoft states that roles remain attached to the user and never to the application acting for them. Microsoft Entra best practice is to use on-behalf-of for interactive agents, client credentials with minimal application permissions for autonomous agents, and to avoid application permissions when delegated permissions would suffice.
• Agent identities. Microsoft Entra Agent ID is generally available, and each agent created in Copilot Studio gets an agent identity in the tenant. In Foundry, a new agent identity starts without resource permissions, and Microsoft's guidance is least privilege per tool call, preferring a resource or resource-group scope over subscription-wide access. Foundry's mode in which the agent identity acts on behalf of the user is in preview.
• Consent is not access. Microsoft notes that consent authorizes delegated permissions but doesn't grant the user access to data the resource would otherwise deny.
• Conditional Access. Agents can't satisfy interactive controls like MFA, so Microsoft recommends separate policies built on identity filters, risk signals and named locations.
• No shared keys. For Foundry, Microsoft recommends Microsoft Entra ID and managed identities for production; a key-based connection grants full access without role restrictions.

Retrieval authorization: what the model may read

Retrieval is where most multi-model designs leak, because a search index or a connector can flatten permissions that existed at the source.

Microsoft 365 Copilot only surfaces organizational data to which the user has at least view permission, and the semantic index honors that identity boundary during grounding.

Azure AI Search offers four approaches to document-level permissions. Only security filters are generally available, and Microsoft is explicit that the principal in a security filter is just a string the application supplies, not an authenticated identity. Built-in ACL and RBAC enforcement, Purview sensitivity label enforcement and SharePoint ACL ingestion are in preview. With SharePoint ACL ingestion, permission changes on a parent scope aren't picked up automatically on later indexer runs. For the full SharePoint permission model, Microsoft points to a remote SharePoint knowledge source that calls SharePoint through the Copilot retrieval API, where results respect applicable permissions and labels.

Sensitivity labels classify and protect content, and their effect on AI depends on usage rights. Microsoft states that the EXTRACT usage right determines whether Copilot or agents can display text from encrypted content; with VIEW but not EXTRACT, Copilot won't summarize the content but can link to it. Labels applied to groups and sites aren't inherited by the items inside them.

Labels are not row-level security. In the Power BI service, sensitivity labeling does not affect access to content; access is managed by Power BI permissions, and row-level security restricts data at the row level through roles. Two details matter for AI tools: row-level security only restricts users with Viewer permission, not workspace Admin, Member or Contributor roles, so the identity an AI tool uses against a semantic model has to be a Viewer for row filtering to apply; and label protection is applied only on supported export paths, not when data is exported to .csv. Purview protection policies can use labels to block access to a whole Fabric item, which is item-level control, not row filtering.

A model routing policy

Routing is a written policy before it is a feature. Microsoft gives you the levers:

• Model router in Foundry routes each prompt in real time to the most suitable model, across models from OpenAI, DeepSeek, Meta, xAI and Anthropic. Microsoft states that it doesn't store prompts and routes only to eligible models based on your access and deployment types, honoring data zone boundaries, and it recommends comparing model router with your current baseline before relying on it.
• Microsoft 365 admin center. An AI Administrator or Global Administrator turns Anthropic on or off as a subprocessor, and access can be scoped to specific users or security groups, enforced across Microsoft Copilot and Copilot Studio. "Anthropic models with Data Retention" stay off until an admin explicitly opts in.
• Copilot Studio and Power Platform. Makers select the model when they create an agent. Enabling a provider in Microsoft 365 doesn't make its models available in Power Platform; a Power Platform admin also has to allow it. Outside the United States, Claude models in Copilot Studio are marked GA with cross-geo processing, and Anthropic and xAI models in Copilot Studio aren't FedRAMP authorized.

An example policy, to adapt rather than copy:

The evaluation set

Run one evaluation set against every model and every agent, so a change of model is a measured change.

• Foundry built-in evaluators cover quality (coherence, fluency), retrieval (groundedness, relevance), safety and security, and agent behavior such as tool call accuracy and task completion. Content safety evaluators use a 0 to 7 severity scale with a default pass threshold of 3. The agent-only prohibited actions and sensitive data leakage evaluators are in preview, as are the Task Completion, Customer Satisfaction, Task Adherence and Intent Resolution agent evaluators.
• Continuous evaluation in Foundry samples live traffic as it occurs; the dashboard views, recurring evaluations, red team scans and alerts are in preview.
• Copilot Studio agent evaluation generates test sets that simulate real scenarios, adds four safety evaluators, and can run from CI/CD through REST APIs or connectors. Because evaluations run as the signed-in user, permission-aware testing means rerunning the set as each test persona.
• Model changes trigger reruns. If an admin removes access to an external model, Copilot Studio agents using it change to another suitable internal model, or fail if none fits. Treat that as a model change and rerun the set.

Logging and oversight

• Purview Audit (Standard) logs Copilot and AI app interactions automatically, including custom applications built with Copilot Studio and Foundry; audit logs for non-Microsoft AI applications use pay-as-you-go billing. The AccessedResources property records each resource Copilot accessed for a request.
• Model provenance. Audit logs for Microsoft Copilot and Copilot Chat include the model provider and model name when a request is processed, but Microsoft notes they might not be available for every request when Auto is selected, so treat model-name logging as scenario-dependent.
• DSPM for AI covers Copilots, agents and other AI apps that use third-party models, and can capture prompts and responses from Entra-registered AI apps, the ChatGPT Enterprise Connector and applications built on Foundry.
• Foundry tracing, built on OpenTelemetry, is generally available for prompt and hosted agents and in preview for workflow and external agents; monitoring data lives in Application Insights.

Failure handling and content safety

Foundry's default safety policy turns on core harm filters and user prompt attack detection; document attack detection is off by default and must be enabled. The guardrail system applies to Foundry Models sold by Azure, and Microsoft states that Foundry doesn't provide built-in content filtering for Claude models at deployment time, so a Claude deployment needs its own content safety layer configured at inference. For models sold by Azure, abuse monitoring uses automated review with human review as necessary, and customers who meet Limited Access criteria can apply to modify it. For "Anthropic models with Data Retention" in Microsoft's Copilot products, Anthropic stores most inputs and outputs for up to 30 days.

How EPC Group approaches multi-model AI governance

EPC Group builds the control set once and applies it to every model: an inventory of each surface with its data path and terms, agent identities with least privilege and on-behalf-of access where people are in the loop, retrieval that keeps source permissions, a written routing policy by data class, one evaluation set rerun on every model change, and Purview audit and DSPM for AI coverage. See our multi-AI governance approach, AI governance consulting, agentic AI governance, the Azure AI Foundry enterprise guide and Microsoft Purview services.

Frequently asked questions

Does Microsoft 365 Copilot use Claude, and under whose terms?

Claude models are available in Microsoft Copilot, Researcher, Copilot Studio, Power Platform and Copilot in the Microsoft 365 apps, and Microsoft turns them on by default for most commercial tenants outside the EU, EFTA and UK. Anthropic acts as a Microsoft subprocessor there, so the Microsoft Product Terms and DPA apply, except for models labeled "Anthropic models with Data Retention", which need an admin opt-in.

Is Claude in Microsoft Foundry covered by the Microsoft DPA?

No. In Foundry, Anthropic is the seller and operator of Claude models and acts as an independent data processor under Anthropic's terms. With the Azure-hosted versions, prompts and outputs never leave Azure; with the Anthropic-hosted versions, data might be processed outside Azure.

Are sensitivity labels a substitute for row-level security?

No. In the Power BI service, labels don't affect access to content; row-level security filters rows, and only for users with Viewer permission. Labels classify and protect content, including on supported export paths.

Can an AI agent see more data than the person who asked?

Not when it acts on behalf of that person: in the on-behalf-of flow, roles stay with the user, and consent doesn't grant access the resource would deny. An autonomous agent uses its own identity, which in Foundry starts with no resource permissions, so it sees only what you grant it.

Do Foundry content filters cover every model?

No. Foundry's guardrail system applies to models sold by Azure, and Microsoft states that Foundry doesn't provide built-in content filtering for Claude models at deployment time, so Claude deployments need content safety configured at inference.

Sources

Microsoft Learn, accessed November 7, 2026: Foundry Models overview, Models sold directly by Azure, Claude models in Foundry, Claude hosting comparison, Deployment types, Model router, AI providers as Microsoft subprocessors, Select an agent model in Copilot Studio, External models in Copilot Studio, Allow external models in Power Platform, On-behalf-of flow, What are agent identities, What's new in Agent ID, Agent ID best practices, Foundry agent identity, Foundry user delegation, Foundry authentication, Foundry RBAC, Document-level access in Azure AI Search, Security filters, SharePoint ACL ingestion, Copilot data, privacy and security, Purview considerations for Copilot, Sensitivity labels in Power BI, Row-level security, Fabric protection policies, Foundry observability, Risk and safety evaluators, Agent evaluators, Monitor agents, Copilot Studio agent evaluation, Audit Copilot and AI apps, DSPM for AI, Agent tracing, Default safety policies, Guardrails overview, Claude data privacy in Foundry, Azure OpenAI data privacy, Abuse monitoring.