Celest Learn · Microsoft agent governance
How to govern AI agents across Microsoft
Start with one agent that matters. Name its business owner, inspect both the machine identity that lets it authenticate and any user-shaped collaboration identity it uses, and ask what it can reach, what it has done, who may approve a change, and how you will verify the result. Microsoft spreads those answers across several truthful but partial systems, so keep the evidence joined without pretending one screen knows everything. [2] [3] [7] [9] [10] [5] [6]
Start with one agent in one working session
You don't need to solve the whole estate before doing useful governance. Choose an agent people rely on, bring together the person accountable for the work and the person who understands the platform, and leave the session with one honest result and one named next step.
- Choose one agent tied to real work, important data, or a decision your team cares about.
- Name a business owner and a platform owner. One person may fill both roles, but the responsibilities are different.
- Open the source records you already trust. Record when each source was checked and whether it answered the question.
- Write down what is confirmed, what needs attention, what remains unknown, who acts next, and how the team will check the result.
These steps get a first review moving. The full seven-question operating loop also asks what the system of record says after work runs. That verification step is covered in Analytics is evidence, not authority.
Where to look in Microsoft
No single portal answers every governance question. Start with the row that matches the question in front of you, then keep the source and observation time attached to the answer.
Scroll horizontally to read the full table →
| Question | Start here | What it can establish—and what it can't |
|---|---|---|
| What agents exist? | Microsoft 365 admin center: Agent Registry and Agent Map | Visible inventory, ownership gaps, and lifecycle posture. It is a front door, not proof that every agent or relevant record is present. [1] [2] [3] |
| Who owns it, and what access does it have? | Microsoft Entra and linked agent identity records | Technical owner, business sponsor, runtime-facing agent identity, linked agent user, permissions, sign-ins, group memberships, licenses, and access policy. It doesn't establish whether the agent is useful or behaving well. [4] [5] [6] |
| What can it reach? | Copilot Studio and Power Platform | Environment, tools, connectors, knowledge, connections, sharing, and data policy. Configuration shows potential reach, not what happened in one run. [7] [8] |
| What has it done? | Copilot Studio analytics and Microsoft Purview | Operational usage and an auditable interaction record, with different coverage and retention. A gap in one source is not proof of non-use. [9] [10] |
| What is risky right now? | Microsoft Defender | Supported posture, recommendations, alerts, protection, and investigation. Unsupported tools or integrations remain outside that evidence. [11] |
| How did it run in an engineering workflow? | Microsoft Foundry tracing or GitHub AI controls, when applicable | Run-level traces or coding-agent policy and activity. Neither replaces tenant ownership, identity, or business-purpose evidence. [12] [13] |
Join the records without erasing their limits
Two admin screens can both be correct while answering different questions. Bring their records together, but keep four things attached to every answer: where it came from, when it was observed, whether the source was healthy, and whether another source disagreed.
Treat the runtime identity and the digital worker as different records
Microsoft now distinguishes between an agent identity and an agent user. The agent identity is the service-principal-shaped runtime record. The agent user is a user-shaped digital worker record linked one-to-one to a parent agent identity through identityParentId. That split is useful because the runtime principal and the collaboration principal don't answer the same governance questions. [5] [6]
- Use the agent identity to review owners, app-role assignments, delegated permission grants, and blueprint/runtime lineage.
- Use the agent user to review mailbox, chat, group membership, licensing, manager/direct-report relationships, and sponsor coverage.
- Do not treat one record as a substitute for the other. A healthy runtime principal doesn't prove that the user-shaped collaboration surface is licensed, assigned, governed, or even present.
Choose one honest next step
- Confirmed: record the evidence and choose when this agent should be reviewed again.
- Needs attention: name the owner and prepare one bounded proposal for the person who owns the affected boundary.
- Unknown: repair the missing access, telemetry, ownership record, or identity join before making a stronger claim.
What Celest does today
Celest's Agent Estate Review connects Microsoft evidence into one operating picture, produces source-backed findings, and creates a prioritized plan. It works read-only, so your tenant keeps running while the team decides what happens next. The review ends with that plan today; later action remains part of the control model.
As Microsoft formalizes agent identities and linked agent users, Celest's job isn't to blur them into one comforting avatar. It is to join them honestly so an organization can see who the digital worker is, what the runtime principal can do, who sponsors it, and which decisions still require a human authority boundary.
Limitations
- Microsoft product names, portal locations, roles, licensing, and source coverage change. Confirm the current boundary in your own tenant before treating a record as authoritative.
- No source listed here covers every agent type, tool, runtime, or interaction. Preview and integration-specific coverage must remain labeled.
- Analytics, audit, security, and platform traces have different retention windows and semantics. Missing data in one source doesn't prove inactivity or safety.
- This operating guide is not legal advice, a security certification, or a universal compliance checklist. Each organization must choose authorities, thresholds, and required evidence appropriate to its work.
Sources
External claims on this page use the primary sources below. Celest-authored definitions and design criteria are identified as our operating model.
- 1Microsoft Agent 365 overview
Microsoft Learn · Accessed 2026-07-27. Microsoft's current framing of Agent 365 as a control plane spanning agent registry, identity, security, governance, and interoperability.
- 2Manage agents in the Microsoft 365 admin center
Microsoft Learn · Accessed 2026-07-27. The centralized Agent Registry, ownership and unmanaged-agent views, and the boundary between central and product-specific controls.
- 3Roles and permissions for managing agents
Microsoft Learn · Accessed 2026-07-27. Tenant-wide and product-specific administrative authority for Microsoft agent governance surfaces.
- 4Manage agent identities in the Microsoft Entra admin center
Microsoft Learn · Accessed 2026-07-27. Agent identity records, technical owners, business sponsors, permissions, sign-ins, and identity lifecycle administration.
- 5agentIdentity resource type
Microsoft Learn · Accessed 2026-08-07. The service-principal-shaped runtime identity for Microsoft agents, including owners, sponsors, app-role assignments, and delegated permission grants.
- 6agentUser resource type
Microsoft Learn · Accessed 2026-08-07. The user-shaped digital worker record linked one-to-one to a parent agent identity, including group membership, licensing, mailbox/chat semantics, manager, and sponsors.
- 7Work with Power Platform environments in Copilot Studio
Microsoft Learn · Accessed 2026-07-27. The Power Platform environment boundary for Copilot Studio agents, resources, security, and governance.
- 8Data policies in Power Platform
Microsoft Learn · Accessed 2026-07-27. Connector and data-policy controls applied to Power Platform and Copilot Studio capabilities.
- 9Analyze agent performance and usage
Microsoft Learn · Accessed 2026-07-27. Copilot Studio activity, quality, tool, trigger, and knowledge analytics plus documented retention limits.
- 10Audit Copilot and AI application activity
Microsoft Learn · Accessed 2026-07-27. Microsoft Purview audit records for Copilot and AI application interactions and referenced resources.
- 11AI agent inventory in Microsoft Defender
Microsoft Learn · Accessed 2026-07-27. Defender's agent inventory, risk, recommendations, alerts, tools, identities, and investigation boundary.
- 12Set up tracing for AI agents in Microsoft Foundry
Microsoft Learn · Accessed 2026-07-27. Opt-in run-level tracing and Application Insights prerequisites for agents hosted in Microsoft Foundry.
- 13Enterprise policies and features for GitHub Copilot
GitHub Docs · Accessed 2026-07-27. The enterprise policy boundary for Copilot features, models, and coding-agent availability in GitHub.
- Author
- Celest
- Source revision
sha256:e653ba0372994cf754fefa4a21913b656fc5302d91e5855a62f62edccbb38060