A collections manager asks an agent why a customer's overdue balance grew. The answer may draw on a Power BI measure, customer records in Microsoft Fabric and a credit policy document. Change one detail and the governance question changes: the requester sits outside the account's region, the answer is headed for a public Teams channel, or the manager asks the agent to open a collections case.

Governing an agent therefore means more than permissioning a database. It covers which agents exist, which identity each one uses, what it can read, how it is protected from attack, how its behavior is tested, and whether a particular answer or action may go ahead. Microsoft spreads those decisions across several products, each answering one question:

  • Microsoft Agent 365: which agents exist, and who owns them?
  • Microsoft Entra Agent ID: which identity is acting, and what may it reach?
  • Microsoft Fabric and Power BI: which records may be read, and what do they mean?
  • Microsoft Purview: is protected data handled under policy?
  • Microsoft Defender: is the agent exposed, misconfigured or under attack?
  • Microsoft Foundry and Copilot Studio: is this version ready, and does this live interaction stay within configured guardrails?
  • The application and its accountable owner: may this particular answer or action be released?

The last question has no packaged Microsoft answer. The rest of this article explains each component, where it acts in the agent lifecycle, and how the application closes that final gap. The Microsoft Agentic AI Stack shows where these governance services sit around the runtime, models and tools.

The governance system

Each component owns a different control decision

Matrix of seven governance components against six lifecycle stages: register, connect, test, run, validate, and improve and retire. Agent 365 acts at register and improve and retire. Entra Agent ID acts at register, connect, and improve and retire. Fabric and Power BI act at register, connect and run. Purview acts at register, connect, run, and improve and retire. Foundry and Copilot Studio act at connect, test, run, and improve and retire. Defender acts at run and improve and retire. The application and business owner act at validate and improve and retire.
No stage is governed by a single product, and only the application-owned row acts at the validate stage. That row is a responsibility, not a Microsoft product.

How Governance Follows the Agent Lifecycle

The same components appear at different moments in an agent's life:

  • Register: Agent 365 records the agent and its owner. Entra provides the agent identity and sponsor. Fabric and Purview establish the governed data boundary.
  • Connect: Entra authorizes the agent. Fabric, Power BI and other systems enforce source permissions. Purview and Copilot Studio policies can restrict supported data sources, connectors and channels.
  • Test: Foundry or Copilot Studio evaluation uses repeatable cases to test answer quality, task completion, safety and tool behavior.
  • Run: Source permissions constrain retrieval. Foundry guardrails inspect configured intervention points. Purview and Defender detect or block supported data and security risks.
  • Validate: The application holds a consequential output as a candidate, checks evidence and business rules, then releases it, retries, abstains or requests human approval.
  • Improve and retire: Traces, audit records, security investigations, feedback and verified outcomes feed the next regression set. Agent 365 and Entra support ownership changes, access removal, blocking and retirement.

Keeping the stages apart prevents a common category error: an inventory service is not an evaluator, and an evaluator is not a runtime guardrail.

Agent 365 and Entra Govern the Estate and Its Access

Microsoft Agent 365 is the estate-level control plane. It gives administrators a registry of agents with their owners, activity and risk context, and coordinates controls from Entra, Purview and Defender. Administrators use it to discover or onboard agents, assign accountability, and block or retire them. Policy templates bundle controls from Entra, Purview, SharePoint and Defender for agent activation; changing a template does not retrofit agents that were already approved.

Agent 365 has been generally available to commercial customers since May 1, 2026. It is licensed per user, is included in Microsoft 365 E7, and is available as an add-on to Microsoft E5, A5 and Business Premium (or to Microsoft Defender Suite plus Microsoft Purview Suite).

Microsoft Entra Agent ID gives an agent a governed identity. Authentication establishes which agent is calling, authorization determines which resources it may reach, and sponsors and revocation support its lifecycle. Agent ID itself is available to all Microsoft Entra customers. Extending Entra security features to agents, such as Conditional Access, ID Protection risk detection and identity governance with access reviews, requires Agent 365 licensing.

Together, Agent 365 and Entra make an agent visible and accountable, provided it actually authenticates through the governed identity. They establish authority, not whether a source fits the question or an answer suits its audience.

Fabric and Power BI Govern What Can Be Read and What It Means

Fabric has several access layers: workspace roles, item permissions, OneLake security, and security on individual engines and Power BI semantic models. OneLake roles can restrict tables, folders, rows and columns for eligible read identities. Workspace Admins, Members and Contributors already have broader access, so the effective identity and query path matter more than a generic statement that Fabric is secure.

A Fabric data agent answers natural-language questions over selected Fabric sources, read-only and with the caller's effective permissions. Sharing the agent does not grant access to its sources, and a separate orchestrator may still hold write tools. Talk to your data explains how data agents and Power BI's Prep data for AI features focus answers without replacing authorization.

Access alone is not enough. A collections agent needs the accepted overdue-balance measure, the right time grain, a current refresh and an accountable owner. Without those semantic-model definitions, an agent can be permitted to read data that is still unfit for the decision.

Purview and Defender Cover Different Risks

Microsoft Purview is centered on the data and its handling. Depending on the workload, it classifies and labels information, applies Data Loss Prevention (DLP) policies, records audit evidence, enforces retention and supports investigations. Coverage varies by agent platform, workload, identity, channel, policy and license, so Purview is not a universal filter for every Foundry, Copilot Studio, Fabric, Teams or external MCP route.

Microsoft Defender is centered on exposure and hostile behavior. Defender for Cloud surfaces exposed AI workloads, misconfiguration and attack paths, while Defender capabilities integrated with Agent 365 and Defender XDR detect, investigate and, in supported contexts, block malicious agent or tool activity.

Purview helps show whether protected data was handled under policy. Defender helps show whether the workload was attacked or misused. Neither judges whether an allowed statement is accurate or suitable for its audience.

Foundry and Copilot Studio Govern Agent Behavior

Foundry evaluation measures an agent's outcome and the process behind it. Depending on the agent and evaluator, teams test relevance, groundedness, task completion, safety and tool use against datasets, while tracing and the Agent Monitoring Dashboard observe production behavior. Several of these capabilities are in preview. Evaluating production agents with Microsoft Foundry covers them in depth.

Foundry guardrails act at a different moment. Controls can be applied at four intervention points: user input, tool call, tool response and output. Tool call and tool response are in preview and take effect only for tools that support moderation, currently Azure AI Search, Azure Functions, OpenAPI, SharePoint grounding, Fabric Data Agent, Bing grounding, Bing Custom Search and Browser Automation. Each control's documented action decides whether it blocks or only annotates.

Copilot Studio has its own evaluation and governance surfaces. Makers can run repeatable tests against a Copilot Studio agent, and administrators can use data policies to restrict knowledge sources, connectors, HTTP access, channels, triggers or unauthenticated publishing. Copilot Studio evaluation does not cover every agent type, including Fabric data agents.

Evaluation, Guardrails and Response Validation Are Different

Each control answers a different question:

  • Pre-release evaluation: is this version ready, based on representative cases and acceptance criteria?
  • Runtime guardrails: does this live interaction contain a configured and supported safety, injection, data or threat risk?
  • Pre-display validation: is this particular answer or action authorized, evidenced and correct for its destination?

Microsoft provides the first two through product-specific capabilities. The third is an application design. For consequential answers, treat model output as a candidate: hold it server-side with the effective identity, source identifiers, retrieved evidence, tool arguments and policy results. Apply supported runtime controls, then run deterministic checks for destination, schema, allowed operation, current values and business rules before releasing, retrying, abstaining or routing to human review.

Azure AI Content Safety groundedness detection can be one signal in that path. It compares text with supplied grounding material, which tests consistency with that material rather than truth in general.

Pre-user validation

Qualifying a version is not the same as releasing a live response

Three control moments for an agent response. Before release, evaluations qualify a version. During a live request, a candidate result is held server-side while supported Microsoft runtime controls inspect defined risks and an application-owned business gate checks identity, destination, schema, source values and business rules. The result is then released, retried or abstained, or sent for human review. After release, traces and feedback become regression cases.
Evaluation qualifies the version; runtime controls and the application's gate decide what happens to each live result. Native coverage depends on the configured product, intervention point and action.

Read, Disclose and Act Are Separate Authorities

The application-owned gate matters because retrieval, disclosure and action are different permissions.

A finance lead may be allowed to retrieve an account's collections history in a private session, while a post of the same answer to a public channel is held for audience review. A regional manager may ask the question while row security excludes accounts outside the region. An agent may explain a proposed collections case but still need a narrowly scoped action tool and a human approver before creating it.

A realistic policy test

The same data question changes as the context changes

Illustrative policy matrix for a collections agent with columns for read source, disclose answer and write action. A finance lead's private account question is allowed and answered privately. A regional manager asking about an account outside the region is denied the restricted row and gets no account answer. A finance lead's post to a public channel is allowed to read but held for audience review. A finance lead's request to create a collections case is allowed to read and answered privately, while the write goes through an approval gate.
An illustrative policy design. Fabric permissions decide the read column, destination policy decides disclosure, and the action tool's own approval decides the write.

The action tool should enforce its own identity, operation allowlist, parameter validation, approval and audit event. A natural-language prompt is not an enforcement boundary.

External Agents Create Another Boundary

A published Fabric data agent can serve as an MCP tool for a compatible external client, and Foundry or Copilot Studio agents can call governed Fabric capabilities. In either design, schemas and query results cross into another client, runtime or model provider.

Review the calling identity, region, client terms, telemetry, retention, model boundary and output channel. A service principal still needs permission to the data agent and its sources, and delegated-user and application identities should not be assumed to behave identically.

Governance Decisions to Make

The Microsoft components each remove a different class of risk. Connecting them to one agent's job still requires these decisions:

  • which agents are registered in Agent 365, who owns each, and whether Agent 365 licensing covers the Entra controls you plan to rely on;
  • which identity each agent uses, and which sources and operations it may reach;
  • which semantic definitions are authoritative for the agent's important claims;
  • which Purview, Defender and Foundry guardrail controls apply on this agent's actual route;
  • which destinations and audiences each answer may reach;
  • which actions need human approval, and how reviewed failures become regression cases.

Reliancy can help map these components to an agent lifecycle, identify the uncovered decision boundaries, and design evaluation and pre-display validation that match the business risk. Discuss an agent-governance architecture with Reliancy.

Sources and Product Documentation

All articles