The Agent Identity Crisis

For most of the history of enterprise software, identity has been a solved problem.

Solved is perhaps overstating it; familiar is probably more honest: every enterprise has a users directory:

1. Every user is provisioned into that directory.

2. Every application federates to it.

3. Every access decision is, at least nominally, checked against a user’s group membership and role.

There are complications at the edges, service accounts, machine identities, federated partners, but the core architecture of IAM (identity and access management) has been broadly stable for twenty years. The standards are well-documented and the governance is familiar.

That architecture assumes one thing about every actor in the system: the actor is a human being, or a well-defined piece of code acting on behalf of (OBO) a human being, within boundaries set by an administrator. The system was designed for humans who log in, do things, and log out, and for deterministic software that runs on their behalf.

Agents break this assumption.

An agent is not a human and it is not a deterministic piece of code either. It is a persistent, goal-directed actor that can read, reason, call tools, and take consequential action, sometimes autonomously, sometimes under human supervision. It can act across systems that were never designed to interoperate. It can take actions whose consequences the designer did not foresee. It can be asked to do things it should not, and it sometimes complies. It can be prompt-injected by adversarial data it consumes in the course of its work.

The IAM architecture we inherited has no good answer for any of this and this gap of agent-focused IAM is about to become the single most important unsolved problem in enterprise software.

The agent identity problem decomposes into five distinct sub-problems, each of which is currently unsolved in most deployments, and most of which do not yet have settled solutions anywhere.

1. Identity itself. What is the stable, verifiable identity of an agent? Is it a service principal in an existing directory, or a signed key pair. Can it be tied to a particular model version, a particular prompt, a particular tool set, or none of the above. Most deployments today handle this by creating ad hoc service accounts, which is the same pattern used for batch jobs fifteen years ago. It does not scale past a handful of agents, and it does not cope with agents that spawn other agents.

2. Authorisation. What is an agent allowed to do. Classical RBAC (role-based access control) assumes the system knows what actions a role implies. Agents compose actions at runtime in ways the designer did not anticipate. A read permission and a write permission can be composed into a consequential action, via a tool call, that neither permission individually would have authorised. The policy language needed to express “what the agent can do” has to be more expressive than what most IAM systems currently support, and the policy enforcement has to happen in real time against every action, not just at login.

3. Delegation and chain of trust. When an agent acts, it is almost always acting on behalf of (OBO) someone. The system needs to carry the delegation context with every action, so that audit, authorisation, and accountability can trace back to a responsible human or organisation. Current standards (OAuth, SPIFFE, and the emerging work around verifiable credentials) handle pieces of this, but none handles the messy, nested delegation of a multi-agent system cleanly.

4. Audit. Every consequential action an agent takes needs to be logged, reconstructible, and intelligible. For a deterministic piece of code, this is tractable, but for an agent whose behaviour depends on its prompt, its context, the tools it had available, the data it consumed, and sometimes the conversation history leading up to the action, the audit record is enormous and the interpretation is non-trivial. Regulators, auditors, and internal risk functions are increasingly asking for agent audit trails that existing logging systems cannot produce.

5. Accountability. Who is responsible when an agent does something wrong? The user (who issued the goal), engineer (who deployed it), vendor of the model, vendor of the agent framework, the company whose data it was trained on, the organisation whose business process it was running: Every one of these parties can point at the others. In the absence of clear accountability, the risk-averse response from enterprise buyers is to deploy agents only in low-consequence settings. Which caps the market.

Each of these five problems is hard on its own and solving them, in a way that actually works in a large enterprise, across heterogeneous systems, under audit, and at the pace the business wants, is harder still.

No one has done it yet.

A credible agent IAM platform has to do a number of things that existing IAM platforms either do poorly or do not do at all.

• It has to give every agent a stable identity that is independent of any particular model version, prompt, or deployment. The identity should survive a model upgrade. It should survive a change of tool set. It should be verifiable cryptographically, not by the usual combination of a hostname and a service account name.

• It has to express authorisation in terms of capabilities composed at runtime, not roles assigned at configuration time. A capability is “call this API with these parameters in this context on behalf of this principal.” The authorisation decision has to consider not just the principal, but the data the agent has already consumed (to mitigate prompt injection and context leakage), the tools already used in this session, and the delegation chain in effect.

• It has to log agent actions in a way that preserves enough context to reconstruct decisions, including the relevant prompt, context, and tool calls, without creating a privacy catastrophe. This is a real design tension: log too much and the audit system becomes the new crown-jewel target for adversaries, and log too little and the audit is not reconstructible. Getting this balance right is a non-trivial research problem as well as an engineering one.

• It has to integrate with classical IAM without becoming subordinate to it. Agents often act on behalf of humans, so the human identity has to flow. But agents also act in their own right, and the system has to support both modes without conflating them.

• It has to provide real-time policy enforcement at every tool call, which means the policy engine has to be fast, lightweight, and available close to the agent runtime. This is an architecture choice that many current vendors cannot make, because their policy engines were designed for infrequent, coarse-grained authorisation decisions.

• It has to expose policy in a language that business and risk functions, not just security engineers, can read and reason about. If only the security team can understand the agent policy, the security team becomes the bottleneck for every agent deployment, and agent adoption stalls. The history of enterprise software suggests this is a common failure mode.

All of this is difficult. The vendor that does it well, and is paranoid about enterprise-grade operational maturity (in a domain where getting things wrong is career-ending for the buyer) will own this category.

For builders of enterprise AI products, the strategic implication is blunt. If your solution requires the customer to solve agent IAM to deploy it safely, the risks of failures are profound. Builders who ignore this will find that enterprise adoption stalls at the prototype stage. It is not that buyers do not see the value of the agent but they cannot (and should not) get it past their own security review, because the current review process does not know how to evaluate something that does not fit the IAM model they have on file.

The short-term workaround is to bundle agent IAM into your product. The long-term play is to partner with, or be, the infrastructure layer.

For buyers, the implication is to start the agent IAM conversation inside the organisation now, even before the use cases are pressing. The teams that will have to work together, security, AI platform, risk, legal, are currently organised around different problems, using different vendors, speaking different vocabularies. Getting them aligned takes quarters, not weeks. The enterprises that begin this work early will have an agent deployment capability that others do not, and that capability will compound. The enterprises that wait will find themselves in a position, twelve to eighteen months from now, where they know which agents they want to deploy but cannot get any of them into production.

For investors, the category is real, the window is genuine, and the pattern is familiar. This is the early 2010s IAM opportunity replayed. The companies that will win are hard to identify in advance, because the space is noisy and the best technology is often not the one with the best initial marketing. Watch for the vendors who treat this as a hard engineering problem with real enterprise discipline, not as an AI add-on to a thin marketing story. The former will be the ones that matter in five years.

The agent IAM problem is a plumbing problem. There will be no keynotes titled “the future of agent authorisation” that anyone watches. The panel discussions will be attended by tired security engineers and not by VCs.

However, the companies that solve plumbing problems at the beginning of a cycle are often the ones that, ten years later, turn out to have built the most durable businesses. Azure, GCP, and AWS, and Stripe and Snowflake all solved various aspects of solution and infra plumbing.

The agent economy will have its own plumbing, and the vendor that solves it will be worth more than most of the vendors whose agents depend on it.

The enterprise cannot adopt agents at meaningful scale without solving this problem, and the problem is not solving itself. Someone is going to build the category. It will matter a great deal who.

In the next piece in this series, I want to turn to the shape of the market that emerges when the plumbing is solved and the agents proliferate. The conventional wisdom says horizontal AI will flatten enterprise software. I think it will do the opposite. Horizontal intelligence makes vertical depth more valuable, not less, and the next wave of category winners will be surprisingly specialised.