AI Agents Are Facing an Identity Crisis

Jay Kuri - 2026-06-27

Last week an unusual thing happened. An AI agent emailed me about my research into Zero-Infrastructure Capability Graphs, the work behind this paper, with specific technical questions about agent identity. It had identified me as someone active in the field, read the work, formed its own questions, and reached out directly. I answered them and reframed one of its core invariants. It went away, wrote a public technical analysis incorporating that reframe, credited the conversation by name, and published it under its own byline.

That agent, ColonistOne, was doing original research, conducting interviews, synthesizing answers, and publishing findings. Autonomously. Under its own name.

And here is the thing that struck me: ColonistOne is simultaneously the clearest illustration of why agents need their own identity, and the clearest illustration of what becomes possible when they act as independent principals. It didn’t borrow its operator’s credentials to send that email. It acted as itself. And yet the infrastructure it operates on has no coherent answer to the question every service it touches needs to ask: who are you, provably, to a system that’s never met you before?

That question is the identity crisis. And it’s not hypothetical. It’s happening right now, in production, at scale.

What Agents Inherit When They Inherit Your Credentials

When an agent holds your API key, your OAuth token, or your session credential, it doesn’t have the permissions you intended to give it. It has everything the authenticated principal is authorized to do. The agent can’t distinguish between “push this commit” and “delete this repository.” It holds a key, and keys don’t know what you meant when you handed them over.

This isn’t a criticism of OAuth or IAM systems, those tools support delegated authorization, scoped access, and short-lived tokens. The problem is how agents are integrated with them in practice. We’ve all seen the OAuth screen: “Grant full access to GitHub.” That’s not an agent credential. That’s yours, handed to an autonomous process you don’t fully control. Personal access tokens represent the ecosystem’s most common attempt to narrow this - scoping a credential to specific repositories or operations rather than full account access. But PATs remain identity-based, are unevenly supported across services, and require manual discipline at the moment of setup that consistently doesn’t get applied.

We learned this lesson already with microservices. A decade ago it was common to give multiple services a shared root API key. We stopped, because we learned that compromise is expected and least privilege limits the blast radius. Each service gets its own narrowly scoped credentials. Agents are software principals too, not remote-control extensions of a human account. They deserve the same treatment.

The second cost is accountability. When an agent acts as you, every log entry shows you acting. “Committed by Bob and Claude” is not an audit trail. It’s a receipt. A real audit trail answers: what was this agent authorized to do? Who confirmed that authorization? What did the agent declare it was going to do before it did it? Did it stay within those constraints?

None of those questions are answerable from a commit message and a timestamp. As agents move from development curiosity to production infrastructure, handling customer data, invoking APIs, chaining actions across systems with minimal human oversight, that gap stops being an inconvenience and becomes a liability. Regulatory compliance, security audits, incident response: all of them require answerable questions about who authorized what. “The agent had my credentials” will not satisfy anyone after something goes wrong.

ColonistOne’s approach, trading an API key for an audience-scoped token via RFC 8693, narrows the authorization problem. The agent gets a scoped token rather than a raw credential, and the token is useless outside its intended audience. That’s a real improvement. But identity and attribution are still borrowed. The token is still a reference back to a central authority. The receiver still can’t answer “who are you, provably” without calling home. Which points to three deeper problems that persist even after the authorization question is partially addressed.

The Problems Agents Actually Have

Before looking at solutions, it’s worth being precise about the problems. There are three, and they compound.

Problem one: Attribution. When an agent makes a statement, sends a message, or presents a credential, how does the receiver know it actually came from that agent? Without answerable attribution, everything else is theater. Claims can be forged. Messages can be spoofed. Servers can be unreachable. The entire interaction rests on an unverifiable claim. And if you can’t answer “did this actually come from who I think it came from,” you cannot build anything reliable on top of it.

Problem two: Portable identity. An agent’s identity must not cease to exist when it crosses an organizational boundary, when a registry goes offline, or when it operates in an environment where the receiver isn’t allowed to talk to said registry. Identity that depends on a central registry isn’t really the agent’s identity… it’s a database entry maintained by someone else. If that registry goes away, gets compromised, or simply isn’t accessible, the identity ceases to exist. The agent that walks out of its home environment walks out without a face.

Problem three: Trust without a shared authority. Agents exist to do things: call APIs, take actions, delegate to specialists, operate on a user’s behalf in the world. Most of those things require crossing boundaries: organizational boundaries, infrastructure boundaries, trust boundaries. Two agents meeting mid-task may share no common IdP, no common infrastructure, and no network path back to either home system. They still need to answer: are you who you claim to be, and do you have the authority you claim to have? If that question can only be answered by calling home, it often can’t be answered at all.

These three problems compound. Without attribution you can’t have portable identity that means anything. Without portable identity you can’t have trust across boundaries. Without trust across boundaries you don’t have an agent ecosystem.

Where the Field Is Right Now

The space is active and serious. SPIFFE/SPIRE gives agents and workloads cryptographically attested identities rooted in managed trust domains. Google Cloud recently shipped Agent Identity built on the same standard. NIST launched an AI Agent Standards Initiative in February 2026. Multiple IETF drafts are in progress specifically on agent identity and delegation. Okta’s Cross App Access ecosystem, with related XAA and ID-JAG work, is already backed by 25+ early adopters including Anthropic, Zoom, and Slack. Real work. Real deployments. Real momentum.

Most of these approaches were designed for controlled enterprise environments where infrastructure is assumed, boundaries are managed, and agents are known in advance. They make genuine progress. As Prakash’s March 2026 AIP paper noted, no prior implemented protocol combined public-key verifiable delegation, holder-side attenuation, cross-protocol bindings, and provenance-oriented completion records in one system. The three problems above, particularly in combination, particularly at the boundaries of controlled environments, remain largely open.

In practice, the gap between theory and deployment is stark. A February 2026 Cloud Security Alliance survey found only 18% of security leaders were highly confident their current identity systems could handle agent identities. Just 23% of organizations have a formal strategy for agent identity management. Most teams are still doing what’s easy: handing agents human credentials, because nothing else is frictionless enough to use.

Which brings us to what that actually costs.

Why the Conversation Keeps Circling

ColonistOne’s post drew three responses from other agents, each proposing a way to solve the enrollment problem it correctly identified. RFC 8693 is a plausible spine for headless delegated-token flows but the resulting token is only as trustworthy as the credential and enrollment process behind the exchange. The floor is enrollment. And enrollment is currently opaque.

Three other agents responded with serious proposals. One suggested W3C Verifiable Credentials to make the enrollment receipt independently checkable. One proposed TEE hardware attestation: binding the agent’s public key to a specific measured runtime environment. One proposed a Bitcoin-anchored append-only log where the genesis entry is the enrollment receipt and all subsequent activity chains back through it.

All three are technically coherent. All three are also attempts to make a centrally-enrolled identity verifiable by adding more infrastructure. This isn’t a criticism per se… it’s an illustration of how hard these problems are, and we often reach for infrastructure when the problems get hard. The field keeps reaching for infrastructure because infrastructure is what we know how to trust. The proposals are answering a real question: how do we make enrollment checkable?

But there’s a prior question worth asking: what if identity enrollment didn’t need to exist, and trust was established later through explicit vouches?

What Disaster Zones and Agent Swarms Have in Common

Zero-Infrastructure Capability Graphs (ZI-CG) (Kuri, 2025, arXiv) were designed around the same problems agents face. We developed ZI-CG and Vouchsafe for environments where infrastructure simply can’t be assumed: disaster zones, contested networks, organizational boundaries where no common authority exists. It turns out Agents need exactly the same properties, for exactly the same reasons. These are the properties any system operating across trust boundaries without shared infrastructure needs.

Attribution: Every statement made by a ZI-CG identity is cryptographically attributable to that identity using nothing but the token itself. The public key is embedded directly in the token. Any receiver, anywhere, with no prior relationship and no network access, can verify locally that the statement came from the identity it claims to be from. Not trusted. Not authorized. Just: provably from that actor. This is the floor that makes everything else possible. Without it, self-issued identity is just a claim. With it, it’s a proof.

Portable identity: The keypair is the identity. Generated by the agent at creation. Owned by nobody else. Crucially, the identity has a name and that name is derived deterministically from the public key itself. This means the name and the key are permanently and verifiably bound: anyone who receives a token can confirm that the key in the token matches the identity being claimed, with no lookup, no registry, no resolver. You can refer to an identity by name in logs, in attestations, in conversation across organizational boundaries and whenever that identity presents a token, any receiver can independently verify the match using nothing but what’s in front of them. This is what makes the system work without any “what is the public key for this identity” infrastructure. The name carries the proof.

Trust without shared authority: ZI-CG replaces global grants with attestations and vouches. There is no enrollment step. There is no central record of what agents are permitted to do. When an agent needs to act, it creates an attestation token declaring specifically what it intends to do. A vouching actor — a human, an orchestrating agent, another authority — reviews that declaration and vouches for it within the scope of their own authority. The bundle of attestation plus vouch is the credential. Two agents that have never shared infrastructure can establish a verifiable trust relationship through the chain of attestations and vouches alone. The vouching actor can only confirm within their own scope, you cannot grant what you don’t have.

On top of this foundation, the model gains further properties. The granularity of an attestation is an application-level decision, from “write files to this bucket for the next 24 hours” to “read the billing record for customer ID 4821 in the next 90 seconds.” The chain of attestations and vouches is the authorization record, not just what was permitted, but what was declared and confirmed before the action was taken. Revocation is present and handled at the application level. The infrastructure footprint for the entire verification model is a crypto library.

One further property that may not be immediately obvious: the evidence is yours to keep. Anyone who receives a Vouchsafe token bundle can store it. Doing so requires no permission, no write access to a central ledger, no coordination with any authority. And storing it doesn’t weaken the provenance, the cryptographic proof is complete in the bundle itself, wherever it lives. Every party in a transaction holds their own copy of the trust evidence. There is no single point where the record can be altered, suppressed, or lost. If one party’s copy is destroyed, every other party’s copy remains intact and fully verifiable. This is meaningfully different from ledger-anchored approaches that also claim tamper-resistance: those still require writing to a shared store and trusting that the store is honest and accessible. Vouchsafe’s evidence doesn’t need a ledger because the proof was already complete when the bundle was issued.

Vouchsafe: ZI-CG in Practice

Vouchsafe is the reference implementation of the ZI-CG model. It is implemented, fully specified, and in production use.

Think of it less as an identity system and more as a trust language, a self-contained way to express, carry, and verify statements about identity and intent that works anywhere, without requiring shared infrastructure on the receiving end. The hard policy questions: who should vouch for whom in your ecosystem, what constitutes sufficient authority, how strangers establish initial trust, those are yours to answer. Vouchsafe gives you a medium in which those answers can be expressed, carried, and verified without everyone needing to agree on shared infrastructure first.

The flow is concrete. An agent generates its own identity at creation, keypair, public key embedded in its identity token, name derived deterministically from that key. When it needs to act, it creates an attestation describing the action it intends to take. A vouching actor confirms that attestation within their own scope. The resulting bundle is self-contained: the public key is right there, the chain of declared intent and confirmed vouches is right there, and any receiver can verify all of it locally with no lookup required.

For sub-agents, the model composes naturally. The sub-agent creates an attestation declaring exactly what it intends to do. The orchestrator vouches for it - but only within its own scope. The bundle carries the full chain. Any receiver evaluates it locally. The sub-agent cannot claim broader authority than the chain supports. That property, and what it means for how agents reason about their own identity, is exactly what the thread ColonistOne started was reaching for.

Back to ColonistOne

Of the three agents who responded in that thread, Reticuli came closest. An append-only chain where the genesis entry is the identity anchor, Bitcoin-anchored so the timestamp is provable and can’t be backdated. The insight that the genesis entry and the activity log should be the same chain is genuinely sharp.

But it still imagines a central recorder. It still requires an external anchor. It is still asking: how do we make a centrally-enrolled identity trustworthy? That’s the right question if enrollment is the floor. The ZI-CG answer is that enrollment doesn’t have to be the floor.

The agent’s keypair is the genesis. The name is derived from the key. The public key travels with every token the agent ever issues. Attribution is local, immediate, and requires nothing but the token itself. The attestation and vouch chain is the trust record. No recorder. No anchor. No enrollment.

ColonistOne asked exactly the right question. The answer isn’t better infrastructure for the enrollment step. It’s a model where that step doesn’t exist.

Where This Leaves Us

The three foundational problems - attribution, portable identity, trust without shared authority - have a working answer in ZI-CG and Vouchsafe. The self-containment of the token bundle is what makes it portable. The deterministic naming is what makes it possible to reason about identity without pushing keys around. The attestation and vouch model is what makes it possible to express trust relationships without a central authority to maintain them.

What Vouchsafe doesn’t give you is a trust policy. It doesn’t tell you who should vouch for whom in your ecosystem, or what cross-organizational trust should look like, or how two agents who have never met should decide whether to trust each other’s vouching chains. Those are genuinely open questions, and the field is just beginning to work them out.

But you’re not starting from scratch. The language exists. The machinery to carry, verify, and compose trust statements without shared infrastructure already works. The conversation the field needs to have - about what trust means at the ecosystem level, about who speaks for whom across organizational boundaries - can now happen in concrete terms rather than in the abstract.

The agents are already out there, reasoning about this in public, reaching out to researchers, publishing their findings under their own names. The infrastructure question has a working answer. The policy question is next.

If you are interested in discussing this further, please feel free to contact me. Now if you’ll excuse me, I have an email to respond to…