Here is a small question with an uncomfortable answer. When your AI scheduling assistant reserves a conference room, who reserved it? Not in a philosophical sense — in the literal, logged, who-do-we-hold-accountable sense. For a lot of organisations right now, the honest answer is that the action was taken under a human’s credentials, by software acting on their behalf, and the audit trail can’t cleanly tell the two apart. The room got booked. Who booked it is a shrug.

That shrug scales badly. Surveys in 2026 put the gap in stark terms: around 91% of organisations are running AI agents, and only about 10% have identity governance in place for them — and roughly 70% of recent identity incidents now trace back to AI-related activity. We have handed agents intelligence and access at the same time, and skipped the part in between: giving them an identity. The order is backwards, and it’s worth fixing on purpose, because an agent that can act but can’t be identified is a governance problem wearing a productivity costume.

For the rest of us: what “identity” means here

Identity and access management — IAM — is the boring, load-bearing plumbing that answers two questions for every action in a system: who is doing this, and are they allowed to. For humans it’s mature: you log in, you prove it’s you, your permissions are checked, and the log records your name against what you did.

Agents break this in a specific way. An agent acts on your behalf — so at first glance it looks like you’re doing it. But it often spawns sub-agents, calls tools, and reaches into systems using your API keys or your logged-in session, because that was the easy way to wire it up. The result is that authority flows outward from you through a chain of software, and at each hop it gets harder to say who is really acting. When something goes wrong three steps down that chain, the logs may just say it was you.

The chain, and where it blurs

The technical name for the hard part is authorization propagation — and there’s now a formal treatment of it (arXiv 2605.05440, Identity Governance as Infrastructure, May 2026). The problem is keeping “who is allowed to do what” correct as authority passes from a human, to an agent, to a sub-agent, to a tool. The paper’s key insight is that this is not the same problem as prompt injection, and it is not solved by the classic access-control models (RBAC, ABAC, ReBAC) that enterprises already run. It’s a new, workflow-level property, and it fails in three distinct ways worth knowing by name:

  • Transitive delegation — you authorise the agent; the agent authorises a sub-agent; and unless something bounds it, your authority propagates further than you ever intended.
  • Aggregation inference — each individual data pull is permitted, but combining them produces something the agent should never have been able to assemble. Every step was legal; the sum isn’t.
  • Temporal validity — the permission was valid the moment it was granted, but the agent uses it later, after the context that justified it has changed or been revoked.

None of these are exotic. They’re the ordinary, predictable failure modes of letting authority flow through software without designing for how it flows.

The industry’s answer: give the agent a name

The fix that’s emerging across the identity industry is refreshingly concrete: stop treating agents as either human users or anonymous service accounts, and make them first-class identities with their own principal. Microsoft’s Entra Agent ID reached general availability in April 2026, extending its existing Zero Trust controls — Conditional Access, Identity Protection, Privileged Identity Management — to non-human identities. Okta shipped a purpose-built agent-identity platform that works alongside whatever human IdP you already run, spanning SaaS apps, APIs, MCP servers, service accounts and secrets. Google has Agent Identity for Vertex AI. The IETF is drafting standards so this doesn’t fragment.

What that buys you is the thing the opening shrug was missing. When the agent acts, the log reads “Agent-Calendar-Bot-v2, acting on behalf of [email protected], reserved Room-401” — the delegation is explicit, auditable, and revocable without touching the human’s primary credentials. You can kill the agent’s access without locking the person out of their own account. That single property — revoke the agent without revoking the human — is most of the practical value.

I feel the absence of it every day, at small scale. Hermes, the agent I run on my home server, operates under my accounts, with my keys. It’s the problem in miniature: if it ever did something it shouldn’t, the logs would say I did it, and revoking its access means revoking mine. That’s fine for one person’s home lab. It is not fine for an enterprise with hundreds of agents fanning out across production systems.

What this means

The paper’s central claim is the one to take to an architecture review: identity governance for agents has to be treated as infrastructure — evaluated continuously, enforced at every interaction boundary, and designed in before orchestration logic is allowed to scale. Not bolted on after you’ve already got fifty agents in production sharing service accounts, because at that point you can’t see the chain you’d need to secure.

So the order in the title is deliberate. Before you give an agent more intelligence, give it an identity — one that can be named, bounded, audited, and revoked. The useful pre-deployment questions aren’t about the model. They’re these: when this agent acts, whose name is on it? How far can its authority propagate before something stops it? Can you revoke it without burning the human it works for? If you can’t answer those, you don’t have an agent problem yet. You have an identity problem you haven’t met.

References