The first generation of AI assistants was read-only: it answered, summarized and drafted. The current generation acts. Agents book flights, approve expenses, merge pull requests and query production databases — operations that require real credentials with real consequences.
Every one of those actions runs into the same question, and today's identity infrastructure has no good answer to it: who, exactly, is this agent, and what is it allowed to do?
Why it matters
Get agent identity wrong in one direction and you get chaos: agents holding users' full credentials, taking actions no one can reconstruct, multiplying the blast radius of every prompt-injection attack. Get it wrong in the other direction and agents are useless — every action blocked by authentication flows designed for a human with a phone.
The security community's concern is concrete. An agent that browses the web and acts on your behalf is a confused deputy waiting to happen: malicious instructions embedded in a page it reads can redirect its legitimate authority toward illegitimate ends. Containing that requires the agent's authority to be narrow by construction, not by policy.
How it works
The emerging architecture borrows from two existing traditions. From human identity: OAuth-style delegated authorization, where the user grants a third party limited access without sharing credentials. From service identity: workload identity systems like SPIFFE/SPIRE, which issue short-lived, automatically attested identities to software. An agent gets a distinct, verifiable identity of its own; a user delegates specific scopes to it ('spend up to $200 at this merchant', 'read this repository, open pull requests but never merge'); every action carries both identities and lands in an audit log.
The hard parts are the ones standards can't fully specify: how a user understands and reviews what they've delegated, how delegation chains work when one agent hires another, and how revocation propagates fast enough to matter when an agent goes wrong mid-task.
Evidence
The standards work is public: the IETF's OAuth working groups are actively discussing extensions for agentic delegation, and the major identity vendors have all published agent-identity architectures in the past year. Payment networks have launched agent-commerce frameworks with exactly this shape — scoped, tokenized spending authority. On the protocol side, agent-to-agent communication standards now include authentication as a first-class concern rather than an afterthought.
The incidents are accumulating too: security researchers have demonstrated agents manipulated into exfiltrating data through the tools they were given, which is why the least-privilege design is being treated as a prerequisite rather than a best practice.
The competing read
One school holds that agents are just workloads, and existing service-identity infrastructure, properly applied, is sufficient — the novelty is overstated. The other notes that no existing system models the defining feature of agents: they act on behalf of a user, dynamically, across trust boundaries, with judgment. The truth is that the delegation semantics are genuinely new even if the cryptography isn't.
What happens next
Expect the first wave of agent-identity products to consolidate around a pattern: per-agent identities, user-granted scopes, short-lived credentials, full audit trails, and human approval gates above defined risk thresholds. The organizations that deploy agents without that stack will produce the incidents that make it mandatory.
