The problem nobody's saying out loud
Businesses are rolling out AI agents faster than they can govern them. That's not a hunch — it's a measured finding. A recent survey by security firm Gravitee found that only around 22 percent of organizations treat agents as independent identities with their own lifecycle. The rest let agents reuse shared API keys, human login credentials, or generic service accounts. 88 percent of respondents had experienced a confirmed or suspected agent-related security incident in the past year.
Non-human identities — service accounts, API keys, and now AI agents — already outnumber human users somewhere between 45-to-1 and over 100-to-1 in many organizations. According to KPMG figures, the number of machine identities per enterprise grew from roughly 50,000 to 250,000 between 2021 and 2025. Agents aren't just another version of the same problem. They're worse, because unlike a static service account, they can request new access dynamically, chain actions together autonomously, and get created faster than an IT department can register them.
This isn't hypothetical. It's already been documented in practice.
The incident that shows what can actually go wrong
On March 31, 2026, Palo Alto Networks' threat intelligence team Unit 42 published a report called "Double Agents." It found that Google Vertex AI Agent Engine gave every agent a default project-level service account with far more access than necessary. A compromised or manipulated agent could read every Google Cloud Storage bucket in the project, pivot into Google's own infrastructure, and pull private container images from registries that should have been locked down. Google's response was to recommend customers configure their own scoped service account instead of the default.
The interesting part isn't that Google did something uniquely bad. It's that the default configuration — broad access, granted automatically, with no time limit — is exactly the pattern most platforms still lean on.
Teleport's 2026 survey of 205 security leaders and architects put a number on the consequence: organizations that gave AI agents broad access had a 76 percent probability of a security incident. Organizations that scoped access to the specific task had 17 percent. That's more than four times the risk with broad access — and 61 percent of incidents involved exposure of sensitive data.
That's why Gartner placed "identity and access management adapting to AI agents" among its top cybersecurity trends for 2026, while simultaneously warning that over 40 percent of agentic AI projects will be scrapped by 2027 — partly because risk controls weren't in place from the start.
What Microsoft Entra Agent ID actually is
Microsoft's answer is to give every AI agent its own governable identity in Entra — not unlike a service principal, but purpose-built for agents. Entra Agent ID reached general availability in April 2026, and Microsoft Agent 365 — the governance layer around it — became generally available on May 1 the same year.
The model consists of four object types. An agentIdentityBlueprint is the template: it defines what kind of agent it is, and what rights it inherits at creation. An agentIdentityBlueprintPrincipal is the blueprint's presence in a given tenant — relevant for agents used across multiple organizations. agentIdentity is the actual authentication identity the agent uses. And agentUser is an optional, linked user account for agents meant to behave more like a colleague than a background tool — with its own mailbox and Teams presence.
These identities aren't typically created manually by an admin — they're created by the platform the agent runs on. Microsoft Foundry automatically creates a template and a dedicated identity for every published agent. Copilot Studio can do the same (in preview). Teams developers create templates via the Developer Portal.
One point worth noting: owner and sponsor are two separate, explicit fields in Entra — not the same thing. Sponsor is the formal accountability relationship: a human responsible for decisions about the agent's access and lifecycle, notified as access nears expiry, and able to approve or deny extension.
Access Packages: the mechanism that makes access governable
This is the core of the whole model – and the reason we consider it fundamental to safe agent usage.
An Access Package is a bundle of resources — security groups, directory roles, or API permissions — that can be granted through a governed request-approval-expiry process. What's new is that this mechanism now applies to agent identities, not just humans.
Access can be requested three ways: the agent can request it itself, programmatically, via Graph API. The sponsor can request it on the agent's behalf through the My Access portal. Or an admin can assign it directly. The request goes through one to three configurable approval stages — typically the resource owner, an IT admin, or both.
One limitation is worth knowing before you plan a setup: only security groups, directory roles, and API/OAuth permissions can be added as resources in an agent package. Application roles, SAP roles, and SharePoint Online site roles can't be added directly. If an agent needs access to a specific SharePoint site, the workaround is to create a security group, add that group to the package, and then grant that group access on the SharePoint site — an indirect route, but a working one.
The time limit isn't a detail — it's the point
Once access is approved, it's time-bound with a defined start and end date. It's a hard cutoff: when the deadline passes without the sponsor acting, the agent loses access. The sponsor is notified beforehand and can request an extension — but that triggers an entirely new approval round, not a silent renewal. There's no automatic "just keep going" path.
This is the difference between ordinary least privilege and what the security community calls Zero Standing Privilege. Least privilege is about limiting how much access an identity has at any given time. Zero Standing Privilege asks a stricter question: should this identity have any access at all right now, between tasks? Under zero standing privilege, an agent has nothing to steal while idle. A stolen API key with permanent access is exploitable around the clock. An agent identity with no access between tasks is the opposite.
We should be honest about one thing our research couldn't confirm precisely: what happens to a task in progress the moment access expires mid-work. The general pattern in Entra is that authorization is evaluated when a token is issued or refreshed, with Continuous Access Evaluation enabling near-real-time revocation for supported resources — but this isn't explicitly documented for this exact scenario. It's worth testing yourself before you assume a running job stops cleanly.
Conditional Access and identity protection, layered on top
Starting in early July 2026, with completion expected by early August, Microsoft is rolling out two new service plans: Conditional Access for Agents and Identity Protection for Agents. As we write this, the rollout is still in progress in some tenants — check availability in your own tenant before promising it to a client.
Conditional Access can target the agent identity itself (app-only flow), the agent's linked user account, or the blueprint — where the policy is inherited by every agent derived from it. It can't be targeted at "all users" as a bulk category; agents must be addressed explicitly.
Identity Protection for Agents detects, among other things: admin-confirmed compromise, malicious activity early in an agent's life, directory reconnaissance, failed access attempts, matches against Microsoft threat intelligence, unusual sign-in spikes, and access to unfamiliar resources. A "Learning Mode" suppresses false positives for new or rarely used agents. The available actions are to confirm compromise, dismiss as safe, or disable the agent entirely.
The honest picture: what's still missing
No new platform is flawless, and it wouldn't be credible to pretend Entra Agent ID is.
Microsoft's own FAQ document, updated June 26, 2026, lists several known limitations: the standard admin-consent flow doesn't yet work for agent identities — admins have to grant permissions directly. There's no support for dynamic groups for agent user accounts, only manually assigned ones. If a template is approved in another tenant, there's no notification — it has to be checked manually against the Graph API. And agent identities can't use standard SSO, OIDC, or SAML sign-in pages.
We also found no public customer case studies for Entra Agent ID or Access Packages yet — Norwegian, Nordic, or international — beyond Microsoft's own demos. That's not in itself an argument against adopting it, but it's worth knowing: you're early, not late, if you set this up now.
One piece of good news, particularly relevant to us: third-party platforms like n8n and AWS Bedrock are actually supported, via the Entra Auth SDK or workload identity federation with OAuth2/OIDC. That means agent automation built outside Microsoft's own ecosystem can still be governed through the same identity and access framework — which makes the whole model far more relevant to businesses that mix Microsoft 365 with their own automation tooling.
What it actually costs
Microsoft Agent 365 is sold as a standalone add-on at $15 per user per month, or as part of Microsoft 365 E7 at $99 per user per month — a bundle that also includes M365 E5, Copilot, and Entra Suite, at roughly a 15 percent discount versus buying each separately. Access Packages additionally require Entra ID Governance P1.
It's not priced as a pure enterprise-only product out of reach for mid-size businesses — it's priced per user, like most M365 add-ons. But Microsoft's own recommendation is to license "everyone who interacts with, manages, or sponsors" an agent, which can inflate the seat count quickly in an organization that takes governance seriously from the start. That's exactly the kind of calculation we help clients get right before it becomes a surprise on the invoice.
Why we think this is fundamental
We already build RBAC setup into every delivery — it's not something we bolt on afterward. What Entra Agent ID and Access Packages give us is the concrete mechanism that lets us say the same thing about agents that we've always said about people: access should be justified, time-bound, and someone should be accountable for it.
That's not because the technology is flawless. We just listed what it doesn't do yet. It's because the alternative — agents with standing, unlimited access because nobody took the time to set up anything better — is exactly the pattern that produced the Google Vertex AI incident, and exactly the pattern Teleport's numbers show is more than four times as risky. Access Packages aren't the only thing that makes an agent safe to use. But without them, you have no real way to prove, after the fact, that the agent only had access to what it actually needed, for the time it actually needed it.
That's the difference between trusting an agent because you hope it goes well, and trusting it because you can show exactly why.
AI doesn't start with technology. It starts with structure.