Gartner projects that 40% of enterprise applications will embed task-specific AI agents by the end of 2026 — up from under 5% in 2025. NIST stood up an AI Agent Standards Initiative in February 2026 with agent identity as a core pillar. Vendors shipped accordingly: Microsoft took Entra Agent ID to general availability this spring, and CrowdStrike unveiled Continuous Identity for AI Agents. Yet in most shops I talk to, nobody can answer the first audit question: how many AI agents hold credentials right now, and who owns each one?
That gap is the subject of this guide. Agents are not service accounts and they are not users — they are a third identity class that needs its own lifecycle, its own least-privilege model, and its own promotion path from assisted to autonomous. Here is how to build that before your auditors, or your attackers, find the hole first.
What changed
Three things landed inside twelve months. First, scale: agent adoption crossed from pilot to default, and every major SaaS suite now ships agents that request credentials on day one. Second, standards: NIST’s February 2026 initiative put agent identity on the formal standards track, while SPIFFE workload identity and the Shared Signals Framework moved from niche to vendor-adopted, and OAuth-based authorization in the Model Context Protocol became the de facto pattern for agent-to-tool access. Third, products: Entra Agent ID hit GA, CrowdStrike and Zscaler previewed risk-adaptive access for agents across the Zero Trust Exchange, and Google pushed its Agent2Agent protocol into open governance.
The takeaway a VP can repeat: the “there’s no tooling yet” excuse expired in 2026. What remains scarce is an operating model.
Why it matters
Your IAM stack assumes two identity classes. Humans get joiner-mover-leaver workflows, MFA, and a manager. Machines get service accounts and API keys — static, predictable, narrowly scoped, and (in theory) inventoried. Agents break both models. They behave dynamically like humans, vary their access patterns by task, spawn and retire in hours like containers, and — the hard part — act on behalf of specific users, which creates delegation chains your directory was never asked to represent.
The risk math is ugly. An over-scoped agent credential doesn’t get tired, doesn’t trip lockout thresholds, and generates activity that looks plausible at machine speed. Prompt injection turns any autonomous agent into a confused deputy: the attacker doesn’t steal the credential, they borrow the agent that already holds it. My verdict is blunt: an agent with standing broad privileges is a breach waiting for a well-crafted input. If your organization is formalizing AI oversight more broadly, this is the identity chapter of the story we covered in our enterprise AI governance frameworks guide — governance without identity enforcement is a policy PDF.
Treat agents as first-class identities
The fix is conceptually simple: give agents the same lifecycle rigor you give employees, adapted for machine tempo. In practice that means:
- Provision from a template. Every agent identity is stamped from an approved blueprint that pre-defines scopes, owner, and expiry — Microsoft’s Agent Identity Blueprint construct is the clearest productization of this idea so far.
- Named human owner. No owner in the directory, no credential. Orphaned agents are the new orphaned service accounts, at ten times the volume.
- Least-privilege scopes with expiry. Rule of thumb: no agent credential should live longer than 90 days, and high-privilege scopes should be granted per task, not per agent.
- Separate delegated and autonomous permission sets. An agent acting for a user should carry that user’s constraints; an agent acting alone should carry far fewer rights and far more logging.
- Behavioral baselining. If you can’t attribute an API call to a specific agent and its human sponsor within one hop, don’t grant the scope.
- Deprovisioning tied to the workflow. When the automation retires, the identity retires the same day — automatically.
The vendor field: who does what
No single vendor covers the whole problem. Broadly, you’re assembling three layers: a directory of record for agent identities, a runtime authorization and risk layer, and the agent platforms themselves, which decide how identity is expressed in the first place.
| Role in the stack | Strongest at | Watch out for | |
|---|---|---|---|
| Microsoft | Directory of record (Entra Agent ID, GA 2026) | Blueprints, Conditional Access, and ID Governance extended natively to agents | Licensing tied to Agent 365 / E7 tiers; strongest inside the Microsoft estate |
| CrowdStrike | Runtime identity risk (Continuous Identity for AI Agents) | Per-action authorization, SPIFFE + Shared Signals, no standing privileges | An overlay, not an IdP — you still need a directory of record |
| Zscaler | Inline zero-trust enforcement for agent traffic | Risk-adaptive access via the Zero Trust Exchange and CrowdStrike integration | Not an identity provider; agent-to-agent east-west policy still maturing |
| Google Cloud | Agent platform + IAM service identities | Open Agent2Agent protocol; per-agent identities via Cloud IAM | Governance tooling spread across IAM, Agentspace, and Vertex |
| Anthropic | Agent platform (Claude, MCP) | OAuth-based MCP authorization as a de facto tool-access standard | Lifecycle governance deliberately left to your IdP; MCP server auth quality varies |
| OpenAI | Agent platform (Agents SDK, enterprise admin controls) | Fastest build path; SSO and SCIM on the enterprise tier | Tool credentials default to long-lived API keys unless you engineer otherwise |
A few sharper notes. Microsoft is the only vendor treating agents as directory citizens — agent identities, agent user accounts for on-behalf-of scenarios, and governance reviews that work like employee access reviews. If you’re an Entra shop, start there; just model the Agent 365 licensing cost before you scale, because per-user pricing on a per-agent problem deserves scrutiny. CrowdStrike is attacking the runtime layer: every agent action re-authorized in real time against identity, human sponsor, and context, which is the correct architecture for high-privilege agents — but it presumes you’ve already got clean identity data to reason over. Zscaler’s bet is that agent traffic is still traffic, and its CrowdStrike integration makes access decisions respond to live identity risk; if you’ve already retired your VPN estate along the lines of our ZTNA migration guide, extending those policies to agents is an increment, not a project.
The platform vendors matter just as much, because they set defaults. Google Cloud’s Agent2Agent protocol and IAM-backed agent identities give multicloud shops an open pattern, though you’ll assemble the governance story yourself. Anthropic’s MCP authorization spec pushed OAuth scoping into the agent-tool boundary, which quietly did more for least privilege than most products — but Anthropic leaves identity lifecycle to your IdP by design. OpenAI gives enterprises SSO, SCIM, and admin controls on the ChatGPT Enterprise side and a fast Agents SDK on the build side; the gap to watch is tool credentials, which drift toward long-lived keys unless your platform team enforces short-lived issuance.
Adaptive autonomy: promote on evidence
The most useful governance idea of this cycle is adaptive autonomy: agents earn independence the way junior admins do. Start every agent in assisted mode — human approves each consequential action. Promote to supervised mode after a defined evidence bar: I use 100 logged runs, an error rate under 2%, and zero attempted out-of-scope calls. Promote to autonomous only for the specific tasks with that track record, with an automatic demotion trigger on any anomaly. The promotion log is your audit artifact.
Wire the demotion trigger to your detection stack, not to a quarterly review. Agent anomalies unfold in minutes, and this is exactly the telemetry the current generation of AI-driven SOC tooling ingests well — we compared the contenders in our AI SOC platforms analysis.
What to do about it
- Inventory first. Discover every credential an agent holds today, including shadow agents inside SaaS suites. Expect the count to be 3–5x what anyone estimates.
- Assign ownership. Every agent gets a named human owner and a business justification, or it gets disabled.
- Pick your control plane deliberately. Directory of record (Entra Agent ID or your IdP’s equivalent) plus a runtime risk layer for high-privilege agents. Don’t let six teams pick six patterns.
- Enforce short-lived credentials. 90-day maximum, per-task issuance for privileged scopes, automated rotation.
- Stand up autonomy gates. Assisted, supervised, autonomous — promotion on logged evidence only, demotion on anomaly automatically.
- Extend access reviews to agents. Same quarterly cadence as privileged human accounts. If your review tooling can’t see agents, that’s a selection criterion now.
The bar to clear before end of year is modest: complete inventory, named owners, and expiring credentials. Do those three and you’re ahead of most of the Fortune 500.
Frequently asked questions
What is AI agent identity management?
It’s the discipline of giving each AI agent a unique, governed identity — provisioned from a template, scoped to least privilege, owned by a named human, monitored behaviorally, and deprovisioned when the workflow ends. It extends IAM’s joiner-mover-leaver model to non-human actors that behave dynamically.
How is an AI agent different from a service account?
A service account does one predictable thing with static permissions. An agent varies its behavior by task, acts on behalf of different users, can invoke other agents, and may be created and retired in hours. Static credentials and annual reviews — tolerable for service accounts — fail outright for agents.
What is the biggest security risk of agentic AI?
Over-scoped standing privileges combined with prompt injection. An attacker doesn’t need to steal a credential — they manipulate an agent that already holds one. Per-action authorization and least-privilege scoping are the primary controls.
Do AI agents need their own identities in Entra ID?
If you run a Microsoft estate, yes — Entra Agent ID (GA in 2026) exists precisely so agents stop borrowing user accounts or generic service principals. Elsewhere, the same principle applies: one agent, one identity, one owner, whatever your directory of record is.
Enterprise Techie publishes vendor-honest analysis like this daily — get the brief by email, free.