← Back to all articles
Challenges

(2/3) The Best Map We Have of the Agentic Identity Problem

By Marc Molas·June 23, 2026·9 min read

In the first post of this series I laid out why agentic AI breaks the identity stack: every system we built assumes a human at the keyboard, and agents take that assumption down on day one. I promised the clearest map I could find of the terrain. This is that map.

Most "AI identity" content right now is a vendor explaining why the answer is the thing the vendor sells. This is the opposite of that, which is exactly why I trust it. Identity Management for Agentic AI was prepared for the OpenID Foundation, lead-edited by Tobin South, written through 2025 with the AI Identity Management Community Group and Stanford's Loyal Agents Initiative, and reviewed by a long bench of identity engineers. It is a standards-body survey, not a pitch. It tells you what already works, what is emerging, and — the rare part — what nobody has solved yet. I have read it more than once. Here is what stayed with me.

Today's stack works — inside one company, for an agent that waits

The paper splits cleanly in two: immediate solutions for the agents we ship today, and the future-looking problems for the agents we are about to. The honest verdict on the first half is one sentence, and I would frame the whole field around it:

"Agents and today's authentication and authorization patterns can work for synchronous agents using multiple tools across a single trust domain, but not asynchronous or multi-domain contexts."

Read that twice. Inside one company, for an agent that acts while you wait, the foundations hold. OAuth 2.1 with PKCE secures the flow. You externalize the decision to an identity provider or a policy decision point instead of hard-coding it — the Policy Enforcement Point / Policy Decision Point split that NIST wrote down a decade ago. You manage the agent's lifecycle with the same machinery you use for employees: SSO to log in, and SCIM to provision and, critically, to de-provision. The paper points at experimental work to give SCIM a first-class AgenticIdentity resource type, so an agent becomes a managed entity with owners and group memberships rather than an orphaned API key. None of that is exotic. A competent platform team can build it now.

Two conditions hold that whole picture up, though: synchronous, and single trust domain. Break either and you are in the second half of the paper, where the solved problems run out.

The real contribution is naming the future problems precisely

What makes this document worth your evening is that it refuses to wave at the hard parts. It enumerates them, with the candor of people who have actually tried to build this.

It starts with the most basic question — what is an agent's identity, anyway? — and lays out four architectural models instead of pretending there is one answer: the enhanced service account (a workload identity enriched with agent_model, agent_version metadata — the likely near-term enterprise pattern); the delegated user sub-identity (an identity derived from and bound to the user's session, the real "on-behalf-of" flow); federated trust (an interoperable fabric across domains, built on something like OpenID Federation); and sovereign, portable identity (each agent holding its own keys and a globally unique identifier, via schemes like DIDs). Proposals such as OpenID Connect for Agents are trying to standardize the identity claims underneath. The paper does not crown a winner, because there is not one yet. That restraint is the tell of authors who know the territory.

Delegation, not impersonation, is the spine of the whole thing

If I had to compress the paper's argument to one move, it is this: stop letting agents impersonate users, start letting them carry delegated authority. Today an agent acts with your credentials and the audit log cannot tell you apart — the black hole I described last time. The fix is a true on-behalf-of flow where the access token carries two distinct identities: the user who delegated (in the sub claim) and the agent acting (in the act claim). One clean, auditable link from the first step.

The power, and the difficulty, shows up with recursive delegation — one agent handing a sub-task, and a slice of its authority, to another. Like a Russian nesting doll, the paper says, and it means it as a warning. A resource server at the end of a five-hop chain has to cryptographically verify the entire path back to the original human, not just the last agent that called it. That demands scope attenuation: provably narrowing permission at every step. The paper is refreshingly concrete about the options — OAuth 2.0 Token Exchange for centralized, hub-and-spoke setups, and capability tokens like Biscuits and Macaroons for decentralized ones, where a holder can mint a more restricted version of a token offline, authority embedded in the credential itself under an object-capability model. This is the part most production agent systems get wrong in 2026. They run every agent at one authorization level with all the tools, and call a system prompt a boundary.

And the problem that shadows all of it: revocation, which the authors flatly call "a critical, and largely unsolved, problem." Offline-attenuated tokens make it worse — revoke the parent and there is no clean way to reach the children already delegated downstream. The emerging answers are honest but partial: the Shared Signals Framework to propagate revocation events near-real-time, and the pragmatic move of bounding a credential by execution count so a delayed revocation still caps the damage.

Governance has to move from clicks to code

The first post argued that human-in-the-loop oversight collapses under scale into consent fatigue — "an unmanageable deluge of permission prompts" that "paradoxically reduces security." The paper's answer is the one I would give, and it is structural, not motivational. You do not fix consent fatigue by asking people to pay closer attention. You move governance off the click and into code.

Three patterns it lays out, in increasing sophistication. Policy-as-code: an admin defines the agent's operational envelope once — budget limits, data tiers, call velocity — and the system enforces it programmatically. Intent-based authorization: the user approves a high-level intent in natural language ("book my travel for the conference"), and the system compiles it into a bundle of least-privilege permissions. Risk-based dynamic authorization: routine actions pass automatically, and only an anomalous request triggers an out-of-band human approval through CIBA. The connective idea is a hybrid — use the model to translate fuzzy human intent into a formal, machine-readable policy, then let the deterministic system hold the line even if the agent misreads the instruction. The human approves something intuitive; the runtime enforces something exact. That gap, between intuitive and exact, is where safety actually lives.

Then there is the money

The section I did not expect to be the most clarifying is the economic one. An agent's real utility shows up when it can transact — buy data, pay for an API, settle a purchase — and the entire e-commerce security model assumes a human present at the point of sale. Take the human out and you need new rails.

The paper maps three layers that are already forming. FAPI, the OpenID Foundation's high-security profile, hardens OAuth for irreversible financial actions with sender-constrained tokens. Google's Agent Payments Protocol introduces the Mandate — a cryptographically signed artifact of intent, split into an Intent Mandate ("here is what I authorized") and a Cart Mandate ("here is the specific purchase that met it"), so a non-repudiable audit trail exists for an autonomous transaction. And KYAPay proposes a "Know Your Agent" process that, in the paper's words, extends "traditional KYC/KYB identity verification to the agent itself," emitting a token that bundles verified identity with payment information. Sit with that phrase — Know Your Agent. The market is already reaching for KYC-shaped accountability for agents. It just has not reached for it in a way that protects the human behind the agent. Hold that thought.

The one knot the paper leaves open

For all its range, the document keeps returning to a single tension it is too honest to resolve, and it is the one I have been circling for a week.

"The very traceability needed for audits enables cross-domain tracking that can create comprehensive and potentially sensitive behavioral profiles. Selective disclosure mechanisms — leveraging cryptographic techniques like zero-knowledge proofs and anonymous credentials — offer a path forward… but integrating these techniques with existing identity standards and regulatory requirements remains a significant challenge."

There it is again, stated by the people best placed to know. To make an agent accountable you attach identity; attach identity and you build surveillance. Zero-knowledge proofs and anonymous credentials are named as the path through the wall — prove "a real, liable human stands behind me" without revealing which human — and then named, just as plainly, as not yet integrated with the standards and the regulators that would make them real. Path marked. Door unbuilt.

The paper's own conclusion frames the work of this decade as three shifts: true delegation over impersonation, scalable governance over consent fatigue, and interoperable trust over proprietary silos. I would add the line the authors put almost in passing, because it is the constraint that rules out the lazy answers: whatever we build, "it must not become a walled garden." The well-funded move here is a centralized agent-identity service you rent. The paper, correctly, says the open agent economy cannot run on one company's permission.

So that is the map: the foundations are real, the future problems are named with unusual honesty, and the hardest of them — accountability and privacy at the same time, with no central gatekeeper — is left as an open challenge with a cryptographic direction and no built road.

I have been building the road. In the third and last post I will sketch, at a high level, how I would take that open knot apart — how an agent can prove there is a real, liable, verified human behind it without anyone ever learning who. Not as a survey of other people's ideas this time. As the approach I have been spending my nights on.


Source: OpenID Foundation, Identity Management for Agentic AI (lead editor Tobin South, with the AI Identity Management Community Group and Stanford's Loyal Agents Initiative), October 2025. All quoted text is from the paper.

Ready to build your engineering team?

Talk to a technical partner and get CTO-vetted developers deployed in 72 hours.