AI Agent Identity Management: Treating Autonomous Agents as First-Class Identities

In most enterprises right now, AI agents are running with the security profile of an intern — except the intern has access to production databases, can execute API calls at machine speed, never sleeps, and was issued credentials by a developer who forgot to write down what those credentials can actually do.

This is not a hypothetical. A 2026 survey of more than 900 security practitioners by Aembit and the Cloud Security Alliance found that 80.9% of teams have AI agents in active testing or production, but only 21.9% treat them as independent identity-bearing entities. The rest are running on shared API keys, inherited service accounts, or static credentials embedded in code. In the same dataset, 68% of organisations cannot reliably distinguish between agent activity and human activity in their logs, and 74% admit that agents typically end up with more access than they need.

The same survey produced the most telling statistic of the lot: 97% of enterprise security leaders expect a material AI-agent-driven security incident within the next twelve months. Only 6% of security budgets are currently allocated to addressing this risk.

Gartner has flagged “Identity and Access Management Adapts to AI Agents” as one of the six cybersecurity trends with broad enterprise impact in 2026. The market is moving accordingly: Palo Alto Networks closed its $25 billion acquisition of CyberArk in February 2026, and Cisco is reportedly in talks to acquire Astrix Security in the $250–350 million range — both deals explicitly framed around the identity layer for AI agents.

The market signal is clear. The practical question is what to do about it before the budget catches up to the risk.

Why traditional IAM breaks for agents

Identity and access management was designed for humans interacting with deterministic systems. The implicit model is: a user logs in once a day, holds a session for some hours, performs a roughly predictable set of actions, and logs out. Permissions are assigned to roles, roles are assigned to users, and access decisions get made at session start and trusted for the rest of the session.

AI agents violate every assumption in that sentence.

Agents are ephemeral. A single workflow may spin up a dozen agents, each handling one task, each lasting seconds to minutes. There is no daily login. There is no session in any meaningful sense.

Agents are non-deterministic. Two invocations of the same agent with the same input may take different action paths, call different tools, and access different resources. Static permission assignments cannot keep up.

Agents act faster than monitoring can react. A human user accessing 200 records in an hour is suspicious. An agent accessing 200 records in 90 milliseconds is normal — possibly. The behavioural baselines that work for humans collapse against machine-speed action.

Agents inherit, escalate and chain. When a user tells an agent to “find the latest sales data and email a summary to the team,” the agent may invoke five other agents, call three SaaS APIs, query two databases, and trigger an email. Each step potentially crosses a permission boundary. Traditional IAM has no language for this — there is no concept of “the user authorised the parent agent, but should that authorisation cascade to the child agent that the parent agent invoked?”

Agent identity drifts. The permissions that made sense when an agent was deployed may not match what it actually does six weeks later, after the LLM behind it has been updated and the workflow it serves has evolved. Static role assignments do not capture this drift; nothing in conventional IAM detects it.

The cumulative effect is that agents tend to accumulate permissions over time, get issued long-lived credentials they then share across tasks, and operate in a way that no one in the security organisation can audit. The Cloud Security Alliance and Oasis Security report in early 2026 found that 78% of organisations had no formal policies for creating or removing AI identities; 92% lacked confidence that their existing IAM tools could manage AI and NHI risks; and 79% had moderate-to-low confidence in their ability to prevent NHI-based attacks.

This is the gap.

The framework: identity, invocation context, secretless execution

The clearest articulation of what an agent identity model should look like came out of the second NHIcon conference in early 2026 from David Goldschlag at Aembit. His framework rests on three pillars, and every credible vendor approach in the market now maps to some version of these.

Pillar 1 — Identity. Each agent is a first-class, cryptographically anchored identity, not a username/password pair, not a static API key, not a service account inherited from another system. The identity should encode useful attributes: who created the agent, what its capabilities are, what training provenance it has, what behavioural envelope is expected. This is the information IAM systems need to reason about agent activity.

Pillar 2 — Invocation context. Every action the agent takes carries the context in which it was taken: which user authorised this workflow, which parent agent invoked this child agent, what task is being performed, what time and from what environment. This is what makes audit possible. Without it, an agent is just an opaque actor doing things in your environment.

Pillar 3 — Secretless execution. The agent never holds a long-lived secret. Credentials are issued at the moment of action, scoped to the specific resource and task, and expire on completion. An identity broker or gateway sits between the agent and the resources it accesses, so the agent’s only credential is the proof of its identity to the broker.

That third pillar is the one that does the most work. If an agent never holds a static credential, the catastrophic failure mode of “attacker compromises the agent and exfiltrates its long-lived API key” is structurally impossible. You replace it with a much smaller risk: that an attacker compromises a single in-flight, scoped, expiring credential — which is recoverable rather than catastrophic.

The CyberArk research function summarised the underlying point well at the end of 2025: for human users, attackers now target session cookies post-authentication; for non-human identities, the equivalent target is the API key or access token. The defensive principle is the same in both cases — minimise the lifetime and scope of any credential that can be stolen. For human users, that means short sessions, MFA on sensitive actions, and continuous re-authentication for risk events. For agents, it means ephemeral credentials issued just-in-time per task.

Agent classification: not all AI agents need the same governance

The other discipline that matters is recognising that “AI agent” describes very different things, and the right governance depends on which kind you are dealing with.

The cleanest taxonomy comes again from Aembit and is increasingly the industry shorthand:

User-driven agents (“on-behalf-of”): agents that perform tasks a human explicitly initiated and which run in that user’s context. The classic example is an executive assistant agent that books meetings, drafts responses, and pulls reports for a specific user. The dominant risks here are rights inflation (the agent inherits the user’s broad entitlements as an always-on capability) and attribution failure (you can see the agent acted, but cannot reliably tie the action to which human authorised it). The governance question is: how do you ensure that just because the user can access something, the agent operating on their behalf does not always do access it, and that every action is auditable back to the human who triggered it?

Workload-driven (autonomous) agents: agents that operate as long-running services, often without a human in the loop for any given action. Background workflows, server-side data pipelines, MCP-speaking tool-using agents. The dominant risk here is credential hygiene: these agents traditionally depend on static, long-lived secrets embedded in code or configuration, and a single compromise yields persistent access. The governance question is: how do you make these agents secretless, with workload-attested identity and ephemeral credentials issued at action time?

The two classes need different controls. A user-driven agent governance model is fundamentally about session and delegation — making sure the agent acts within the user’s authority but not beyond it, and that the audit trail ties every action to the authorising human. A workload-driven agent governance model is fundamentally about workload identity and credential lifecycle — proving the agent is what it claims to be, and never letting it hold a credential longer than it needs.

Most enterprises in 2026 have a mix of both, and the industry’s bigger error is treating them with a single, undifferentiated “AI agent policy” that does neither well.

Vendor landscape

The market for AI agent identity has bifurcated into platform players (large IAM and security platforms extending into the space) and pure-play startups (purpose-built for the agent identity problem). Both approaches have legitimate use cases.

If you are choosing where to start, the practical question is which problem is most acute: discovery (you don’t know what agents exist), governance (you know they exist but cannot enforce policy), or runtime control (you need to broker credentials at action time). Astrix and Oasis are strong on discovery and governance. Aembit and Microsoft’s Agent 365 are strong on runtime brokering. CyberArk under Palo Alto increasingly covers all three for enterprise customers. The three problems are sequential — you cannot govern what you have not discovered, and you cannot broker runtime credentials for what you have not governed — so most organisations end up working through the layers in order rather than picking one tool to solve everything.

For broader IAM strategy questions like Okta vs Microsoft Entra ID vs Ping Identity, the agent identity question is increasingly the deciding factor. Microsoft’s Entra Agent ID and Agent 365 give Microsoft-heavy estates a significant pull toward Entra, while multi-cloud organisations are increasingly looking at independent brokers like Aembit specifically to keep agent identity portable across clouds.

A practical sequence: what to do first, second, third

The temptation when looking at a problem this size is to commission a strategy and deliver nothing for nine months. The CISOs making real progress are doing the opposite — small, sequential moves that compound.

Months 1–2: Discovery. Run a non-invasive discovery pass to find what agents, MCP servers, and AI-bearing service accounts actually exist in your environment. Astrix, Oasis, and Microsoft’s Entra reporting all support this. The output you want is a single inventory with three columns: what the agent is, what it has access to, and who owns it. Most organisations are surprised by the count and even more surprised by the third column — frequently empty.

Months 3–4: Classify and govern. Bucket the discovered agents into the user-driven vs workload-driven taxonomy. For each category, define a minimum control set: for user-driven agents, scoped delegation and per-action attribution; for workload-driven agents, secretless execution and short-lived credentials. Establish ownership: every agent gets a human owner accountable for it, with a quarterly review obligation.

Months 5–6: Runtime brokering for the highest-risk agents. You will not retrofit secretless execution onto every agent in six months. You can do it for the highest-risk ten or twenty — those with access to production data, customer PII, or financial systems. Insert an identity broker (Aembit, Oasis, CyberArk, or Microsoft Entra Agent ID depending on your stack) for these agents and migrate them off static credentials.

Months 7–9: Continuous monitoring. Add behavioural analytics for non-human identities. AWS GuardDuty’s anomalous-IAM-behaviour findings, Google SCC service-account behavioural detections, and dedicated NHI behavioural platforms (Andromeda, Token, Aembit) all play here. The goal is to detect identity drift — when an agent’s actual behaviour starts to diverge from its expected envelope.

Ongoing: Quarterly review. Treat AI agent identity governance like a privileged-access programme. Quarterly review of every agent’s permissions, owner, and necessity. Decommission anything that has not been used in 90 days. NIST SP 1800-35 already provides reference architecture for this; it is the implementation discipline that is rare, not the guidance.

What this connects to

Agent identity does not sit in isolation. It is the foundation layer for several other AI security problems and intersects directly with other governance work:

• Agentic AI security at the CISO level. Identity is the control plane. Our agentic AI security playbook treats identity as one of three foundational pillars (alongside oversight and reversibility); this article is the deep dive on that pillar.
• Shadow AI. Agents created in unsanctioned tooling are the inventory blind spot you most want to close. Discovery for shadow AI and discovery for shadow agents are increasingly the same workflow.
• Agentic SOC. When your own SOC starts running on AI agents, those agents need identity governance applied to themselves. The detection-engineering team is also the customer for the agent-IAM platform.

The market signal — the Palo Alto / CyberArk deal, the Cisco / Astrix talks, Microsoft Agent 365, Aembit’s GA launch at RSAC 2026 — is pointing in one direction. Identity is becoming the control plane for AI security in the same way it became the control plane for cloud security a decade ago. The organisations that get ahead of this in 2026 will be the ones whose agents are governed by design when the inevitable incident happens. The ones that wait will be doing forensics on incidents whose blast radius they cannot even map, because the agents in question never had identities in the first place.

Frequently asked questions

Are AI agents just a special case of non-human identities? Mostly yes, with important differences. AI agents share the core NHI characteristics — they are not humans, they need credentials, they act on systems — but their non-determinism and tool-using behaviour create governance problems that traditional NHI tooling was not built for. A service account does the same thing every day. An AI agent might do something different every minute. NHI platforms are extending to cover agents, and dedicated AI agent platforms are extending to cover broader NHI use cases. The market is converging.

Do we need a new IAM system, or can we extend our existing one? Both, in sequence. Your existing IAM system (Okta, Entra, Ping) is staying — humans still need to log in. The question is whether you bolt on agent identity capabilities to that platform (Microsoft is the clearest example with Entra Agent ID and Agent 365) or run a dedicated agent identity broker alongside it (Aembit, Oasis, Astrix). The answer depends on your existing stack and how multi-cloud you are. Microsoft estates lean Entra-native. Multi-cloud and broker-pattern-comfortable teams lean to dedicated platforms.

What about the MCP protocol — is identity built in? The Model Context Protocol does not solve agent identity by itself. It standardises how agents access tools and resources, which is necessary but not sufficient. Identity for MCP-speaking agents still requires an external broker or gateway — which is precisely the gap that Aembit’s MCP Identity Gateway and similar offerings are positioned to fill.

How does the EU AI Act affect agent identity governance? Significantly, and this is under-discussed. The AI Act’s high-risk classification and human-oversight requirements implicitly require that you can attribute every consequential AI action to a specific authorised entity. Without proper agent identity and invocation context, that attribution is not possible — which means the compliance documentation you owe regulators cannot be produced. Agent identity is increasingly a compliance prerequisite, not just a security improvement.

What is the single biggest mistake organisations are making right now? Letting developers create agents that hold long-lived API keys to production resources, with no inventory, no owner, and no monitoring. Six months later nobody remembers the agent exists, the developer has left the company, and the credential is still active. This is the modern equivalent of the abandoned service account that has been the source of countless breaches over the last twenty years — and the same pattern, played out faster, at greater scale, with more access. Fixing this is genuinely the highest-leverage thing most security organisations can do this year.