Integrating AI Agents With Microsoft Entra ID

AI agents don't behave like users, and they don't behave like the workloads Microsoft Entra ID was built to manage. They act on their own, run across sessions that outlive any single login, and chain calls across APIs and MCP servers at machine speed, making dozens of authentication decisions before a human notices anything happened. Microsoft's answer is Entra Agent ID, a framework that treats agents as identities with a lifecycle, an owner, and a Conditional Access policy attached to them. The old approach, bolting a service principal onto an agent and hoping someone tracks it, produced exactly the mess you'd expect: sprawling, unowned identities that nobody can account for, and nobody wants to own up to.

Traditional service principals were built for stateless, bounded jobs. A script runs, it calls an API, it finishes. There's no lifecycle concept, no owner field, no expiration date unless someone sets one by hand. That worked fine for a nightly batch job. It falls apart when the workload is an agent that persists for weeks, chains tool calls nobody explicitly authorized, and gets copied by three different teams who each spin up their own version with slightly different permissions attached.

The failure mode isn't hypothetical, and it isn't rare. The result is a common pattern of ad-hoc service principals accumulating across projects with no consistent policy governing them. Entro Security's State of Non-Human Identities report found 97% of non-human identities carry excessive privileges, which reads less like a statistic and more like a confession. Over-permissioning is the default here, full stop. It's the default setting, full stop.

Scale turns this from an annoyance into a structural problem. Agent counts inside the Microsoft 365 ecosystem grew 15-fold year over year, 18-fold inside large enterprises. IDC projects 1.3 billion agents deployed over the next three years. Run a 97%-over-permissioned baseline through that growth curve and the math stops being a punchline. Each agent, under the old model, is a one-off configuration: no template, no inheritance, no audit trail tying it back to whoever created it. That's the gap Entra Agent ID exists to close.

Microsoft Entra Agent ID and its path to general availability

Entra Agent ID entered public preview on May 19, 2025. It's an identity and security framework that extends Microsoft Entra's existing capabilities to AI agents, built into the Entra directory itself rather than bolted on afterward.

Agents created in Azure AI Foundry or Microsoft Copilot Studio get a unique identity automatically. No manual provisioning, no separate spreadsheet to track who made what. Third-party agents, built on platforms like AWS Bedrock or n8n, connect through the Microsoft Entra ID Auth SDK (a sidecar) or through workload identity federation. Either way, the agent lands in the same Entra directory as everyone else: access controls, role-based permissions, and audit trails managed from the same admin center that already handles employee identities. Standard protocols apply too, including OAuth 2.0, Model Context Protocol, and agent-to-agent communication.

An agent identity is a specialized service principal that holds no credentials of its own. It acquires tokens through OAuth flows rather than relying on long-lived static credentials. Microsoft also shipped an Agent Registry, a metadata repository giving security teams one place to see every agent in the organization, instead of hunting across five consoles that don't talk to each other.

On pricing: extending Entra's security features to agents requires Microsoft Agent 365. It's bundled into Microsoft 365 E7 (list price $99.00 per user per month) or sold as a standalone add-on at $15.00 per user per month, billed yearly, for organizations already running E5, A5, Business Premium, or the Defender and Purview suites. Microsoft also lined up partnerships with ServiceNow AI Platform and Workday Agent System of Record, so agents created in either platform are intended to receive a governed Entra identity through the partnership integration.

Agent identity blueprints and the parent-child model that replaces per-agent configuration

The fix here is structural, and it has a name: agent identity blueprints. A blueprint is a reusable template that defines an agent type's owners, sponsors, access envelope, and audit behavior once, up front, instead of re-deciding all of it every time someone spins up a new instance.

Individual agents inherit policy from their blueprint in a parent-child relationship. Change the blueprint, and every child agent inherits the update automatically. That's the direct fix for one-off configuration sprawl: instead of a hundred slightly different service principals with a hundred slightly different permission sets, there's one template and a hundred instances of it, governed identically. Anyone who's tried to audit a hundred hand-built service principals knows why that distinction is worth the whole article.

Ownership splits into distinct roles, too. Owners and sponsors each carry separate accountability under Microsoft's documentation, so no single person becomes the accidental keeper of an agent they forgot existed. Lifecycle governance is built in from day one: IT sets guardrails for the agents and for the humans managing them, so access assignments are intentional and time-bound rather than permanent by accident. Blueprints carry inheritable permissions, meaning least-privilege gets set once at the template level instead of negotiated agent by agent, argument by argument. When an agent gets decommissioned, cascade cleanup and soft-delete kick in automatically, so it doesn't linger as an orphaned identity holding active credentials nobody remembers granting.

Microsoft also provides tooling intended to streamline onboarding, so blueprint creation and identity provisioning can follow a consistent workflow instead of disconnected manual steps. Blueprints don't solve runtime policy enforcement, risk detection, or network-level controls on their own, though. That's a different layer, and it's next.

Extending Conditional Access, Identity Protection, and Privileged Identity Management to Agent Identities

Agents get the same identity-driven protections users and workloads already have: adaptive access policies, real-time risk detection, lifecycle management, network-level controls. None of this is agent-specific invention. It's the same machinery Microsoft already built, aimed at a new kind of identity.

Conditional Access applies in real time, blocking agents showing anomalous activity or agents acting on behalf of a user already flagged as risky. Policy gets enforced at the moment of the access attempt. Identity Protection layers on top, flagging unusual activity and tracing agents whose tokens have been compromised, so security teams remediate instead of finding the breach three weeks later in a log nobody read. Privileged Identity Management extends to agents too: time-bound, auditable access assignments instead of standing permissions that never expire and nobody revisits.

Network controls round it out. Agent network activity gets logged for audits and threat detection, web categorization applies to the APIs and MCP servers an agent talks to, file uploads and downloads can be restricted, and malicious destinations get blocked automatically. Microsoft Entra Internet Access adds Prompt Injection Protection, now generally available, defending against prompt injection at the network layer, plus data loss protection through Microsoft Purview to catch sensitive data before it leaves for an AI or SaaS application it was never supposed to reach.

Shadow AI gets its own treatment. Entra Agent ID surfaces unsanctioned tools and tracks usage trends, giving security teams sight of things they didn't deploy and didn't know existed until now. That matters given 76% of organizations now call shadow AI a definite or probable challenge, up from 61% in 2025. All of it gets logged for compliance in the same admin center as regular user activity, every sign-in, every action.

Administrators using the built-in Conditional Access Optimization Agent, one of Microsoft's Security Copilot agents, completed critical tasks about 43% faster, with nearly 50% better accuracy, and the agent improved detection of missing baseline security policies by 204%. Those numbers hold up on their own, but they also describe a task security teams run every single week whether they want to or not.

The three OAuth flows Entra Agent ID introduces and their applications

Entra Agent ID ships three OAuth flows, each built for a different way an agent operates. Picking the wrong one isn't a style choice, it's a security gap waiting to be found by whoever exploits it first.

The agent autonomous app flow covers agents acting entirely on their own authority, no user anywhere in the loop. The agent acquires tokens as itself. The agent on-behalf-of flow covers agents acting for a specific authenticated user, preserving that user's identity through the entire call chain and enforcing one hard rule: the agent can't do anything the user couldn't do. If a user lacks permission to delete a repository, the agent acting on their behalf can't delete it either, full stop, enforced at the protocol layer rather than trusted to a prompt instruction that a clever enough input could talk its way around. This is the flow that matters most, because it's the one closing the gap most teams get wrong: they assume the agent inherits the user's identity by default, when in practice that inheritance has to be built into the flow deliberately or it doesn't happen at all. The agent user flow handles cases where a human user's authentication context is involved in the agent interaction.

Across all three, agent identities never hold long-lived credentials. Tokens are short-lived and scoped, which is the mechanism that makes the no-standing-credentials principle real instead of a slide in a slide deck. On the MCP side, a production gateway validates incoming identity, typically via JWT, OAuth 2.0 with PKCE, or OIDC, and passes it downstream to MCP servers, so agents aren't all running under one shared service account that makes attribution impossible after something goes wrong.

The OpenID Foundation's October 2025 publication, "Identity Management for Agentic AI," concluded that current OAuth 2.0 and OIDC standards can secure many agent use cases when agents stay inside well-defined boundaries, but flagged three gaps that still need new standards work. Entra's flows sit on top of that evolving baseline, not past it. The MCP specification itself added OAuth 2.1 in its March 2025 revision, refined again in June 2025, and implementation quality across the ecosystem still varies a lot depending on who built the server and how carefully.

Connecting third-party agents, AWS Bedrock, n8n, and the sidecar pattern

Not every agent gets built on Microsoft's stack. Entra Agent ID accounts for that with two integration paths, and picking between them is mostly a question of what the source platform already supports.

The Microsoft Entra ID Auth SDK, deployed as a sidecar, is a lightweight process that runs alongside a third-party agent and handles Entra authentication for it, without requiring anyone to rewrite the agent's own code. Workload identity federation takes the other approach: it federates the agent's existing identity from its native platform directly into Entra, avoiding credential duplication and keeping one governed identity across platforms instead of two half-managed ones pointing at each other. Documentation confirms support for AWS Bedrock and n8n through both paths.

Anthropic made Workload Identity Federation generally available in June 2026, making long-lived static API keys optional in favor of short-lived, scoped credentials. That's the rest of the industry converging on the same federation model Entra already runs on, and that's not a coincidence.

The governance payoff: every agent, wherever it was built, is subject to the same Conditional Access rules, audit logging, and lifecycle policy as an agent built natively in Azure AI Foundry. The tradeoff is real engineering overhead, though. The sidecar adds a process dependency that has to be maintained and patched, and workload identity federation only works if the source platform actually supports OIDC token issuance, which not every third-party framework does yet. The sidecar exists specifically to cover that gap, at the cost of one more moving part to babysit.

Where MCP gateway infrastructure fits alongside Entra Agent ID

Anthropic released MCP in November 2024. By December 2025 it had racked up 97 million monthly SDK downloads, backing from every major AI lab, and governance as a founding project of the Agentic AI Foundation under the Linux Foundation. That's fast adoption for a protocol that didn't ship with an authentication framework baked in from day one.

That gap left organizations exposed. Security researchers have identified prompt injection, cross-tool data exfiltration, and tool poisoning as active risks, the kind that leaves an organization unable to run MCP servers at real scale without extra controls stacked on top.

An MCP gateway is that extra layer, and skipping it is the mistake most teams don't realize they've made until something's already gone wrong. It centralizes authentication and authorization for every tool invocation: one enforcement point across all connected MCP servers, instead of trusting each server to handle it independently and hoping they agree on what "authorized" means. It logs audit trails and usage metrics at the tool-call level. It enforces tool allow-lists with a deny-by-default posture, since an agent with too broad a tool surface is the practical shape of the excessive agency risk that security frameworks broadly flag as a top concern. And it handles caching, rate limiting, and per-key budget controls, which matters because a runaway agent loop can burn through an API budget in an afternoon, unsupervised and unbothered. Security practitioners broadly recommend exactly this gateway-centric approach for MCP, the same pattern organizations already apply to every other API surface they run.

Gateway auth standards line up with what Entra's flows already produce: OAuth 2.1 (added to the MCP spec in March 2025), SAML for enterprise SSO, OIDC for modern identity providers, and API token management for service accounts. That overlap is what makes Entra and a gateway complementary instead of redundant.

A few products show what this looks like in practice. Bifrost, from Maxim AI, runs as an HTTP gateway that deploys in about 30 seconds via Docker or NPX, integrates directly into Go applications, and supports clustering, in-VPC deployments, and HashiCorp Vault for secrets. Its governance model treats virtual keys as the core entity, with hierarchical budgets, rate limits, and per-key MCP tool allow-lists, plus audit logs built for SOC 2, GDPR, HIPAA, and ISO 27001. Kong added an Enterprise MCP Gateway in Kong AI Gateway 3.12, bringing OAuth-based MCP auth and observability. TrueFoundry, named a Representative Vendor in the 2025 Gartner Market Guide for AI Gateways, offers MCP gateway capability inside a broader AI Gateway platform. Cloudflare combines its AI Gateway, MCP Server Portals, and Cloudflare Gateway into one security architecture for MCP deployments.

Remember the split: Entra Agent ID governs who the agent is and what identity it carries. A gateway governs what the agent is allowed to call, and checks that the token's permissions actually match what the tool demands. Neither replaces the other. Running only one is like locking the front door and leaving every window in the house open, then wondering how someone got in.

The prompt injection and shadow AI risks that agent identity governance must account for

None of this identity architecture matters if the agent can be tricked into misusing permissions it legitimately holds. Prompt injection is the attack that does exactly that, and it has already produced real incidents with names attached.

EchoLeak, disclosed by security researchers at Aim Security (Aim Labs), was the first documented zero-click data exfiltration attack against Microsoft 365 Copilot. An attacker sent an ordinary email that the target user never opened. Later, an unrelated query from that same user caused Copilot's retrieval system to pull the email in as context, which triggered the leak. No click, no attachment, no user interaction required at any point. Separately, CVE-2025-53773 involved a hidden prompt injection embedded in pull request descriptions, which enabled remote code execution through GitHub Copilot.

Both cases point at the same structural truth: identity governance and runtime content inspection solve two different problems, and fixing one does nothing for the other. An agent can hold a perfectly scoped, short-lived, correctly governed token and still get manipulated into using that token in a way its owner never intended, simply because the content it processed told it to do something else. That's why Entra's network-layer Prompt Injection Protection and its data loss prevention capability exist as separate controls sitting alongside Conditional Access and Identity Protection.

Shadow AI compounds the risk, because a security team can't govern what it can't see. Unsanctioned tools, agents spun up outside official channels, third-party integrations nobody logged: all of it sits in the same blind spot that made ungoverned service principals a problem in the first place. The share of organizations calling shadow AI a definite or probable challenge climbed to 76%, up from 61% in 2025, and that shift is why visibility tooling like Entra Agent ID's shadow AI detection now counts as table stakes, not an extra. Somebody has to know what's actually running in the environment before anyone can decide how to govern it, and right now that somebody is running out of excuses.