Explore governance and identity for agents
An agent that can access systems, take actions, and interact with users needs to operate under clear controls. This unit covers how agents get a proper identity, how accountability is established, and which governance controls apply—by default or by explicit configuration—based on the platform it was built on.
Give your agent an identity
Every agent built on the Microsoft platform gets a dedicated identity in Microsoft Entra. Microsoft Entra Agent ID is the identity service for this: Copilot Studio agents receive an Entra Agent ID automatically at creation; Foundry agents receive a dedicated Entra service principal when published as an Agent Application. Both give the agent a controlled identity for authenticating to downstream systems.
Two identity constructs are central to how this works.
An agent identity is the specific identity for a particular running agent instance. At runtime, the agent authenticates to downstream systems using scoped OAuth tokens, with no manually managed credentials or secrets.
An agent identity blueprint is a reusable policy template that teams define once and apply across all agents of the same type.
Note
Microsoft Entra Agent ID (the dedicated agent identity subtype) is currently in preview for Copilot Studio agents.
Register and govern agents through a central platform
Microsoft Agent 365 is the central governance platform for the Microsoft agent ecosystem. It gives organizations a single place to discover, review, and manage agents built with Copilot Studio, Agent Builder, and Foundry, as well as agents from other vendors. Foundry-built and third-party agents require explicit registration.
Registering an agent in Microsoft Agent 365 establishes accountability: It assigns the agent to an owner (the maintaining team) and a sponsor (the business accountable party), so every agent in the tenant has a named responsible party.
Microsoft Agent 365 also manages the lifecycle: An approval pipeline for deploying agents to users, integration with Microsoft Entra lifecycle workflows for identity governance, and connections to Microsoft Defender, Microsoft Intune, and Microsoft Purview for security, compliance, and data protection.
Microsoft Agent 365 works with agents built on Microsoft platforms (Foundry, Copilot Studio, and Agent Builder) and with pre-integrated agents from third-party sources available in the Microsoft 365 admin center.
Important
Microsoft Agent 365 licensing requirements determine which governance and security capabilities are available to your organization. For plans and pricing, see Microsoft Agent 365: The Control Plane for Agents. For licensing details, see Microsoft Agent 365 Licensing FAQs.
How governance inherits from your development platform
The development platform you chose has governance implications. The three Microsoft development platforms ship with different governance defaults:
| Development platform | Governance inheritance |
|---|---|
| Microsoft 365 Copilot | Inherits Microsoft 365 compliance, DLP, retention, and audit controls by default |
| Microsoft Copilot Studio | Power Platform DLP policies apply to all agents; Microsoft 365 compliance and audit controls apply when deployed to Teams or Microsoft 365 Copilot channels |
| Microsoft Foundry | Requires explicit configuration of Azure role-based access control (RBAC), policies, and logging; governance doesn't come by default |
Teams building on Foundry take on governance configuration as an explicit responsibility, not an inherited default. Every access control policy, every logging configuration, and every compliance control has to be set intentionally.
When licensed, Microsoft Agent 365 provides a unified governance layer across all three development platforms, giving organizations a consistent view regardless of where each agent was built. That helps, but it doesn't eliminate the configuration work that Foundry requires.
Governance involves multiple stakeholders
Governance doesn't sit entirely with the development team. Identity blueprints, approval pipelines, and compliance configurations pull in security, identity, and operations stakeholders. How much coordination that requires depends on the agent's risk profile and the platform on which it was built.
Guiding question: Based on the development platform you explored, which governance areas require explicit configuration by the development team, and which are inherited by default?