Microsoft Agent 365 and Entra Agent ID landscape
How Agent 365, Entra Agent ID, Purview, Defender, and Intune divide the work of governing agents.
Why this matters
Most enterprises in 2026 have thousands of "agents" already: Copilot chats, Copilot Studio bots, Power Automate flows, ISV agents inside Teams, third-party agents from AWS Bedrock, plus every custom LangChain / OpenAI Agents SDK / Semantic Kernel prototype a developer left running. No two of them speak the same identity model. That's the problem Microsoft's stack solves at the platform level. If you understand nothing else from this module, understand how the pieces snap together — every downstream lesson depends on it.
Learning objectives
- State clearly what Microsoft Agent 365 and Microsoft Entra Agent ID each are, and why they are two things.
- Map the Microsoft stack onto the vendor-neutral picture from Module 1-2.
- Identify which Microsoft product owns which agent-lifecycle concern.
- Know when not to reach for the Microsoft primitives.
1. Two products, one control plane
There is one common source of confusion: are Agent 365 and Entra Agent ID the same thing? No — but they need each other.
| Product | Role | Analogy for humans |
|---|---|---|
| Microsoft Entra Agent ID | Identity and access foundation for agents. Issues identities, credentials, tokens; enforces authN + authZ policies. | Entra ID / Azure AD, but for agents. |
| Microsoft Agent 365 | Enterprise control plane: registration, visibility, governance, lifecycle, notifications, observability, MCP tool access, running-across-M365 capabilities. | Microsoft 365 + Intune + Entra Suite, but for agents. |
Together they deliver five capabilities that Microsoft brands as pillars:
- Identity — Entra Agent ID gives every agent its own principal, blueprint, credentials, and (optionally) a user account it can act as.
- Observability — Agent 365 SDK emits OpenTelemetry spans for every agent invocation, tool call, and LLM inference; sign-in and audit logs are stamped with
idtyp=agent(oridtyp=userfor agent user accounts). - Governance — Blueprints, sponsors, access packages, lifecycle workflows, agent registry in the M365 admin center. Owned by Entra ID Governance.
- Security — Conditional Access, ID Protection, Defender for Cloud Apps, Purview DLP labels — all extended to agents.
- Lifecycle — Create → onboard (sponsor + owner assigned) → deploy → monitor → deprecate → retire; each step is enforceable, not a wiki page.
Under the hood these are stitched together from Entra, Defender, Purview, Intune, and Microsoft Foundry / Copilot Studio. Agent 365 is the "single pane" that connects them so you don't have to.
2. Where Entra Agent ID sits in the Microsoft stack
+-------------------------------------------------------------------------+
| Microsoft Agent 365 (control plane) |
| |
| Agent registry | Sponsor / access packages | M365 admin console |
| Notifications | OTel observability | Governed MCP tooling |
+---------+---------+-------------+---------------+---------+-------------+
| | |
v v v
+---------------------+ +--------------------+ +----------------------+
| Microsoft Entra | | Microsoft Defender | | Microsoft Purview |
| (Agent ID) | | for Cloud Apps / | | (DLP, Insider Risk, |
| - blueprint | | XDR / MDCR | | eDiscovery, audit) |
| - agent identity | | - risky signals | | - labels, retention |
| - agent user acct | | - prompt shields | | - agent activity log |
| - Conditional Acc. | +--------------------+ +----------------------+
| - ID Protection |
| - ID Governance |
| - Global Secure |
| Access (network) |
+---------------------+- Identity primitives live in Entra Agent ID.
- Runtime protection (real-time threats, DLP, network security) lives in Defender, Purview, and Global Secure Access.
- The unified admin surface + agent-native tooling live in Agent 365.
If a customer asks "do I need Agent 365 if I already have Entra ID?" — the honest answer is: Entra Agent ID gives you the identity + policy plumbing; Agent 365 is what an M365 admin actually opens to run the environment.
3. Mapping to the vendor-neutral module
You already learned the abstract concepts in Modules 1-2. Here's the Microsoft crosswalk:
| Vendor-neutral concept (Modules 1-2) | Microsoft equivalent (this module) |
|---|---|
| Agent as a first-class principal | Agent identity (idtyp=agent) — Lesson 10.2 |
| Agent registry / source of truth | Blueprint + M365 admin center Agent registry — Lessons 10.2, 10.7 |
| Delegated (on-behalf-of) | Agent OBO flow — Lesson 10.3 |
| Service identity | Autonomous agent flow (client_credentials) — Lesson 10.3 |
| Agent-as-user (digital worker) | Agent's user account — Lessons 10.2, 10.3 |
| Workload identity (SPIFFE / IRSA / WIF) | Federated Identity Credential (FIC) on the blueprint — Lessons 10.3, 10.9 |
| Dynamic Client Registration (RFC 7591) | Programmatic blueprint / identity creation via Microsoft Graph — Lesson 10.2 |
| Token Exchange (RFC 8693) | jwt-bearer grant + blueprint impersonation — Lesson 10.3 |
| Consent + scoped grants | Static requiredResourceAccess + dynamic consent + InheritDelegatedPermissions — Lesson 10.4 |
| Policy-as-code (OPA / Cedar) | Conditional Access + custom security attributes — Lesson 10.5 |
| ITDR (Identity Threat Detection & Response) | ID Protection for agents (risky agents) — Lesson 10.6 |
| Governance (JML, access reviews) | ID Governance: sponsors, access packages, lifecycle workflows — Lesson 10.7 |
| Audit + provenance | Sign-in + audit logs (idtyp=agent); Agent 365 SDK OTel spans — Lesson 10.8 |
| Network segmentation for agents | Global Secure Access (SWG for Copilot Studio agents) — Lesson 10.8 |
| MCP as tool protocol | Agent 365 SDK tooling packages + governed MCP catalogue — Lesson 10.8 |
| Third-party agents (Bedrock, n8n, Ollama, LangChain) | Sidecar SDK / Workload Identity Federation — Lesson 10.9 |
Keep this table handy — it's the only thing you need to explain the Microsoft stack to a Keycloak / Auth0 / Okta veteran.
4. When the Microsoft stack is the right answer
Choose Entra Agent ID + Agent 365 when at least one is true:
- You are an M365 tenant already; agents will read/write mail, calendar, Teams, SharePoint, OneDrive.
- Your admins already run Entra ID Governance, Defender, Purview.
- You need compliance evidence stitched across identity + data protection + audit for regulated workloads (finance, healthcare, public sector, telco).
- You have Copilot Studio adopters — Copilot Studio agents automatically get an agent identity if you enable that setting.
- You are building agents on any platform (LangChain, OpenAI SDK, Bedrock, n8n) and want a single governance plane — the sidecar (10.9) lets you plug them all in.
5. When to not start with the Microsoft stack
Be honest with customers where a different pattern is stronger:
- AWS-native shop with no M365. Use Bedrock's own agent identity + IAM Identity Center + Verified Permissions. Wire to Entra Agent ID only for cross-cloud federation later (Lesson 10.9).
- Multi-cloud, no M365 tenant. Start from SPIFFE (Module 2) + your IdP of choice (Keycloak / Auth0 / Okta). You'll pay Microsoft's licensing tax otherwise.
- You are the IdP (Auth0, Descope, WorkOS, Stytch). Your own agentic-authentication primitives are your product; you don't outsource identity.
- Prototype / research / student. Any free-tier Keycloak (from
00_setup/) is faster to spin up than a full Entra tenant with Agent 365 licensing.
The Microsoft stack is optimised for enterprise scale + M365 gravity, not for zero-cost experimentation.
6. What "buying Agent 365" actually gets you
Common misconception: Agent 365 is a single SKU that flips agents "on". Reality:
- Base identity constructs (blueprint, agent identity, agent user account) — free with any Entra tenant.
- Agent 365 license per user — required if agents will use M365 apps / data / activity, and required for Conditional Access / ID Protection / ID Governance targeting of agents.
- P1 / P2 Entra licenses — required for the security features you'd want.
- Bundled path: Microsoft 365 E7 (E5 + Agent 365 + Entra Suite) is the "give me everything" SKU.
Design implication: for early pilots you can develop against blueprints + agent identities with just an Entra tenant and pay per-user licenses only when you go into production across M365. Don't buy the full bundle on day 1.
7. Common pitfalls when adopting this stack
- Treating Agent 365 as MDM for agents — it's more than that; ignoring the identity + governance layers will bite you at audit.
- Creating agents as regular app registrations ("just a service principal") — you'll miss sponsor accountability, inheritable permissions, ID Protection detection, and the M365 admin center will call them shadow agents.
- Reusing one blueprint across environments (dev / test / prod) — blueprint-level credentials + policies are then shared. Split them.
- Buying Agent 365 licenses for users who never touch agents.
- Building a parallel Splunk-only audit pipeline and forgetting that sign-in logs + Purview activity already emit agent events natively — you end up double-paying.
- Assuming "we bought E7" means the tenant is safe — Conditional Access and ID Protection policies still have to be configured and tested against agents specifically (Lessons 10.5, 10.6).
8. Self-check
- What's the one-sentence distinction between Agent 365 and Entra Agent ID?
- Name the five capability pillars Microsoft groups under Agent 365.
- Which Microsoft product owns real-time prompt-injection detection?
- Which license tier is minimum for ID Protection risky-agent detection?
- Give one scenario where you would not start with this stack.
9. References
- Microsoft Agent 365 docs — landing
- Why Agent 365 for enterprise
- How Entra supports Agent 365
- What is Microsoft Entra Agent ID?
- Vendor-neutral Modules 1, 2, 6, 7, 8 of this curriculum.
Sign in to save your progress and earn badges.