AI Agent Identity (Agent 365) Meets Access Governance

When Microsoft unveiled Agent 365 at Ignite last November, it highlighted an important step forward: giving AI agents identities. Yet it also exposed a broader challenge: governing agent behavior once those identities are in place.

The product is now generally available and I’ve seen a lot of positive feedback from the industry. At present, Agent 365 may be the most credible agent-identity layer in the industry. And, the gap between agent identity and agent access governance is now well understood by anyone who's tried to use it in production.

At the end of the day though, Agent 365 functions in line with Entra and Microsoft’s DNA. It’s primary strength is telling you who the agent is and it works best in the Microsoft ecosystem. 

Agentic Access Governance, on the other hand, is an entirely different piece of the puzzle and its function is to decide what that agent should do, what it does in real time and whether those align.

How it works: Entra Agent ID and Agent 365

Entra Agent ID treats agents as first-class identities. Entra Agent ID gives each AI agent its own identity object in Entra:

• Agents created in Copilot Studio and Azure AI Foundry are automatically assigned an Agent ID in Entra, with no extra work for developers.
• Those identities live alongside users, apps, and service principals, so you can apply familiar controls: Conditional Access, group/role assignments, and lifecycle operations.

That’s a big step up from agents reusing human accounts or generic app identities with unclear ownership.

On top of Entra Agent ID, Agent 365 adds a management and observability layer:

• An agent registry that inventories agents, their owners, and relationships to people and data
• Dashboards and telemetry to track how agents behave and where they’re connected
• Policy hooks back into Entra and the broader Microsoft security stack to enforce guardrails and block misbehaving agents

As Microsoft weaves Agent 365 more tightly into the Microsoft 365 and Entra ecosystem (including E5-centric stories), most organizations will naturally want to turn it on where it’s available. And they should: for Microsoft-centric agents, it’s the right foundation.

The immediate following question that arises, especially in a hybrid, multi-cloud environment, is: What does Agent 365 handle well, and what do we still need to solve?

From the time Agent 365 was announced, to when it became generally available, many of us in the industry wondered whether this was just another positioning announcement. Was it a claim with little product-substance, or would we see an operable solution tried and tested?

Here are some of the facts:

• Agent 365 is now a real, priced and supported product. It GA'd on May 1, 2026, for $15/user/mo standalone, or bundled in the new M365 E7 SKU at $99. 
• Agent 365 operates as a full security suite and requires other Microsoft products for best functionality. Defender for Agents (shadow-AI discovery) and Purview for Agents (DLP for agent-touched data) joined Entra Agent ID and the Agent Registry.
• Real partner integrations shipped. Adobe, n8n, Zendesk, and others now ship as registered agents. The ecosystem improved, as we expected.

Gaps that still remain:

• The line stops at identity. Agent 365 governs who the agent is and how it signs in. What the agent carries and uses to actually do its work, the downstream OAuth grants, API keys, MCP tokens, connector credentials, and vault secrets, is still outside scope.
• Ungoverned agents remain. Even inside Microsoft, pre-existing Copilot Studio agents aren't retroactively assigned Agent IDs. M365 Copilot agents acting on behalf of users inherit the user's blast radius. Drafts and third-party agents are still on you.
• Agent posture and misconfiguration remain the dominant risk. Microsoft's own top-10 Copilot Studio risks reads as posture, not identity: hardcoded secrets, oversharing, confused deputy, and unmanaged MCP tools.

‍

Perfect Identity Doesn't Solve Access Governance

The enduring problem with AI agents isn't only who they are. It's how much they're allowed to do. Agents tend to be over-granted permissions. Examples include an unassuming Graph scope, a connector permission, an OAuth grant, or a tool they keep forever, used or not.

Microsoft's top-10 Copilot Studio risks reads as a catalog of over-access patterns:

• Oversharing: agents shared org-wide inherit the maker's SharePoint reach
• Maker-credential confused deputy: the agent uses the creator's credentials, so every consumer inherits the creator's privileges
• Hardcoded secrets in agent definitions: broad credentials handed to the agent by default
• Unmanaged MCP tool calls: agents reach out to tool servers with tool-side permissions nobody is governing

Agent 365 inventories the identity object. It doesn't surface a Copilot bot configured with ten tools that only ever uses three, or a published agent running on a maker's broad credentials.

Closing the over-access gap requires two capabilities, and they sit on either side of the runtime:

• Access posture. Continuous discovery of every agent (Microsoft-managed or not), scoring of what's granted versus what's actually used, ownership assigned, drift detected, and over-access flagged before the agent runs.
• Agentic Access Management (AAM). Provision access at runtime by turning standing entitlements into short-lived, intent-aware, least-privilege sessions. The agent acts with the minimum it needs, exactly when it needs to.

Together, they answer what Agent 365 doesn't: not just who the agent is, but what it's allowed to do, what it's actually doing, and whether that's the least access needed to accomplish its business objective.

Missing From the Registry: Even Microsoft-First Shops Have Agents Outside Entra

Walk into any all-in-Microsoft enterprise and you'll find AI agents that Agent 365 doesn't reach running alongside the ones it does. The gaps aren't theoretical edge cases. They're the agents your developers, contractors, and partners are using today.

Shadow AI on user endpoints. Microsoft does have a story here, and it's worth being precise about where it works and where it doesn't. Defender for Cloud Apps, paired with Defender for Endpoint, can discover SaaS-based generative AI usage like ChatGPT, Claude, and Gemini in a browser tab. It catalogs the apps, scores their risk, and lets you sanction or unsanction them. That covers the cloud AI traffic, but only on devices that are onboarded to Defender for Endpoint. Contractor laptops, partner machines, and personal devices that never went through MDE onboarding are invisible to it, regardless of whether they're touching corporate data through SaaS or VPN.

Local AI agents are a harder gap. Cursor, Claude Desktop, Ollama, and similar tools that run as binaries on the endpoint, not as browser sessions, sit outside SaaS discovery entirely. Agent 365 added a local-agent detection capability at GA, but at launch it covers only agents built on Microsoft's OpenClaw platform. Microsoft has said GitHub Copilot CLI and Claude Code support will follow, but they're not shipping today. So a developer running Claude Code or Cursor on a managed Windows laptop is not in the Agent 365 inventory, and a contractor running anything on an unmanaged machine isn't either.

Non-Microsoft agent platforms. AWS Bedrock AgentCore and Google Gemini Enterprise agents are technically in the program at GA, but only as registry sync, in public preview, with no runtime enforcement. You can pull their inventories into the Agent 365 view, but you cannot govern what they do at runtime through Entra. Claude (Claude Code, the SDK), OpenAI Assistants, LangChain, and CrewAI workflows are entirely outside the program. Microsoft's documented path for bringing third-party agents into Entra governance is a manual SDK integration per agent, which most teams don't have the headcount or vendor cooperation to execute.

Agent classes inside the Microsoft estate. Copilot Studio agents created before March 18, 2026, or before your tenant opted in to Entra Agent ID, were built when Copilot Studio still issued legacy app-registration service principals. Microsoft has not shipped an automated migration to convert those service principals into Entra Agent IDs. There is a documented manual path that involves rebuilding the agent fresh with Agent ID enabled and then decommissioning the original, but for any production agent with active users, Microsoft's own guidance is to leave it on its legacy service principal and wait for an automated migration to ship. In practice, this means a significant portion of the Copilot Studio agents already in production today will stay outside Entra Agent ID governance for the foreseeable future.

GitHub Copilot Coding Agent is a different kind of gap. It runs in GitHub's identity plane, not Entra. Its PR activity and audit trail live on the GitHub side, and nothing about them correlates to your Entra human identities natively. The agent that's writing code against your repos is governed somewhere else entirely.

Microsoft is direct about the limit in their own documentation: agents that aren't integrated through the SDK can't be governed at the agent identity level.

Where Access Governance Comes In

Access governance starts from a different premise, that the agent surface is wider than any one tenant. Continuous discovery across IDPs, clouds, vaults, SaaS, and endpoints, regardless of whether a device is enrolled in MDE or Intune. EDR-based detection of shadow AI agents on user machines, covering local agent binaries beyond OpenClaw. Coding-agent actions correlated back to human identities across the source-control plane, not just the Entra plane.

The agents Microsoft can't see, you still own. And the surface is only getting wider.

A Registry Tells You What Exists. Posture Tells You What's Wrong.

Most enterprises have gone from zero to hundreds of AI agents in eighteen months. The population is doubling, then doubling again, while ownership turns over, scopes drift, and the tools each agent calls multiply.

An agent registry is necessary infrastructure. It isn't the hard part. Knowing an agent exists doesn't tell you:

• Whether the agent's granted scopes still match what it actually does
• Whether it has a current human owner, or whether the maker left six months ago
• Whether it's calling tools or connectors it was never meant to call
• Whether one agent is delegating to another agent, and whether that chain is governed
• Whether what it's doing today resembles what it was approved to do at provisioning

These are continuous questions, not one-time registrations. Agent populations don't stop changing. New agents get built every week, scopes get widened to fix a bug, owners change jobs, tools get added. A registry captures the agent at the moment it was created. Posture captures it on Tuesday at 3pm.

Access governance treats the population as the unit of analysis. Continuous discovery across every plane the agent might live in. Ownership assigned and re-verified as people move. Drift detection on scopes, tools, and downstream credentials. Agent-to-agent chain mapping. Compliance baselines layered across the whole population, not per-agent.

Twelve months from now, the question your IAM team has to answer isn't how many agents you have. It's what they're all doing, with whose access, and whether that's still appropriate. The directory answers the first question. Access governance answers the second.

AI Agents Are the Newest Non-Human Identities

Agent governance isn't a new discipline. It's the newest front in one your identity team already fights. AI agents are non-human identities, the same class as the service accounts, API keys, and OAuth tokens that have outnumbered your human users for years and gone largely ungoverned. The difference is that agents act with human-like autonomy, so their over-access does more damage faster.

That's why we don't treat agents as a separate tool. The Oasis Platform governs the full non-human identity spectrum in one control plane, from a decade-old service account nobody owns to an AI agent minted this morning. Same questions for both: who owns it, what can it reach, what does it actually use, and is that the least access it needs. Same answers: continuous discovery, ownership, drift detection, and runtime least-privilege access.

Agent 365 governs agent identity inside Microsoft. Non-human identity management governs every non-human identity, agents included, across Microsoft and every other platform you run. The agent problem is real. It's also the leading edge of a much larger one, and the teams that treat it that way won't be solving it twice.

Better Together, A Layered Approach For Success

I firmly believe that joint customers are better off with both Oasis and Agent 365 in their environment. The latest news accompanying the GA of this product affirms that Microsoft is building the identity layer for AI agents in the largest enterprise estate in the world. We're building the access governance layer for AI agents everywhere, including inside that estate.

Turn Agent 365 on where it's available. Use Entra Agent ID. Pull Defender for Agents and Purview for Agents into your security operations. The industry is better off because Microsoft is investing here.

And then layer access governance on top, to handle the agents Agent 365 doesn't reach, the over-access it doesn't surface, and the continuous posture questions a registry isn't designed to answer.

Agent identity meets access governance. The full picture takes both.

‍