As AI agents take on more consequential actions, they need a way to prove who authorized them and what they’re allowed to do. In this post, we explore an identity model that preserves accountability without creating a new surveillance layer.
This blog is adapted from a talk by SpruceID Founder and CEO Wayne Chang at the Center for AI Safety’s Multi-Agent Ecosystems Workshop, held at Stanford University in August 2026.
An AI agent may operate autonomously, but its authority has to come from somewhere. Behind an agent is ultimately a person or an organization that sent it into the world with some ability to act on their behalf. Even when the chain includes multiple agents, models, tools, and services, that authority traces back to a principal: a natural person, or a legal entity with identifiable ultimate beneficial owners. This is not a new concept. Financial regulation already requires institutions to determine the natural persons who own, control, and benefit from a legal entity’s actions. The same principle applies when an agent acts: somewhere along the chain, a person authorized it and bears responsibility for its consequences.
That makes the identity problem for AI agents more complicated than simply asking, "Who is this agent?" The more important questions are: Who sent it? What authority did they give it? And how can a counterparty verify those answers without needing to know everything about the person or organization behind it?
Those questions become increasingly important as agents move beyond generating information and begin taking consequential actions: making purchases, submitting applications, interacting with government services, moving money, or entering into transactions. If an agent shows up to act on someone's behalf, the receiving party needs some way to establish not just what the agent is, but whether it is actually authorized to do what it is asking to do.
Identity is easiest when an agent stays inside one provider's stack. The platform knows which account created it, can connect that account to a verified user or organization, and can observe what happens within its own environment. In that setting, the provider can effectively vouch for the relationship between the agent and the principal behind it.
That model gets harder to sustain as agents become more composable. A useful agent may call one frontier model for reasoning, use an open-weight model for a specialized task, browse through a third-party service, and interact with external tools and APIs to complete the job. Each component may know something about the request it receives, but none necessarily sees the full chain of delegation. The person or organization behind the agent still exists, but the system acting on their behalf is now spread across multiple technical and organizational domains. The identity boundary has not disappeared so much as fragmented, creating a harder question: how do you preserve enough trust across those boundaries for a counterparty to know that an agent is legitimate and authorized, without forcing every vendor in the chain to identify and track the principal?
One way to preserve accountability is to keep the whole chain inside a single platform. If the same provider knows the verified user, the agent, every delegation, every action, and every counterparty, then attribution is straightforward. But the cost is a highly concentrated identity and activity graph. The platform gains an increasingly valuable proprietary dataset about how people and organizations use agents, while users become more dependent on the party that controls both the infrastructure and the history. Records this concentrated can also become attractive targets for regulatory or government access, creating a deeper sovereignty problem for individuals, companies, and states.
The opposite model is not much better. Once an agent is assembled across multiple vendors, no one sees enough of the system to vouch for the whole chain. Delegation may terminate at an API key rather than an accountable person. A legitimate agent, a stolen credential, and a convincing clone can look similar from the outside, while responsibility for a harmful action gets scattered across the model provider, browser, tool layer, and whoever supplied the credentials.
There is also an obvious but dangerous fix: attach the principal's identity to every interaction so each intermediary can verify who is behind the agent. That restores attribution by turning every service in the chain into another place where the owner can be observed and tracked. Instead of one centralized ledger, you get a distributed tracking mesh — different architecture, same surveillance outcome.
There is another way to think about the identity layer: instead of the platform maintaining the complete relationship between principal and agent, the agent carries the credentials it needs to establish that relationship for itself. An agent wallet could hold an identity credential that binds the agent to its principal, a payment credential issued by a bank or token issuer, and scoped capabilities defining what the agent has actually been authorized to do.
Those credentials do not need to come from a single provider. Different trusted issuers can attest to different facts, and the agent can present the relevant proof to each counterparty rather than exposing its principal's identity everywhere it goes. Credentials and capabilities can also be revoked at their source when authority changes.
The underlying model is already moving from pilots to population-scale infrastructure. In 2021, roughly 65 million people were eligible for cryptographic credentials held in wallets. That number now exceeds 840 million, driven by U.S. mobile driver's licenses now accepted at TSA checkpoints in 21 states and Puerto Rico, passport-derived and national digital IDs from Apple and Google, and the rollout of EU Digital Identity Wallets under eIDAS 2.0.
These credentials are designed to be held by the individual and presented on their terms rather than repeatedly recreating an identity record with every service they use.
That creates an intriguing foundation for agent identity. The same kind of credential a person can use to prove their identity at a TSA checkpoint could also help anchor an agent acting on their behalf. The agent does not need to carry a universal dossier about its owner; it needs a way to prove the specific things a counterparty needs to know, including where its authority comes from and whether that authority covers the action it is attempting.
The need for agent identity becomes more concrete when agents move from helping people make decisions to actually carrying them out. Consider an agent applying for government benefits on someone's behalf. The agency may need to know that the applicant authorized the agent, that it can submit particular information or attestations, and perhaps that the person meets specific eligibility requirements. It should not need a complete record of everywhere else that agent has been or what else its owner has asked it to do.
The same pattern appears in enterprise workflows. An agent could submit an invoice, participate in procurement, make a compliance filing, or handle a customer support action. In each case, the important question is not simply whether the agent can access the system. It is whether the agent has been granted the appropriate authority by the organization it claims to represent, and whether the scope of that authority is narrow enough to match the task. Today’s permission systems were not built for this. OAuth, for example, grants access at the application level: a user authorizes an app to read their Google Drive, and the app’s scope covers the entire resource. There is no standard protocol-level mechanism for an agent to demonstrate that it has been authorized to access one specific document for one specific purpose, with that access logged and revocable independently. Agent wallets carrying capability credentials could fill that gap, giving enterprises a way to grant, audit, and revoke granular permissions that travel with the agent rather than living inside each application’s own access-control layer.
Consumer transactions introduce their own variations. An agent booking travel might need permission to make a purchase and access certain traveler information. An agent completing an age-restricted purchase may only need to prove that the person behind it satisfies an age requirement. An agent making a payment may need to demonstrate that it can spend up to a certain amount, with a particular merchant or for a particular purpose.
These examples require different credentials, issuers, and levels of assurance. What they share is a need to establish a trustworthy chain from principal to agent to action, with permissions scoped tightly enough that the agent carries only the authority it actually needs.
An agent wallet offers a possible technical model for preserving accountability without creating a universal identity and activity ledger. But establishing that the architecture is possible is different from deciding how it should work in practice.
Who should be trusted to issue the credentials that bind an agent to a person or organization? Depending on the context, that role could fall to governments, financial institutions, employers, or other trusted intermediaries. More likely, agents will need to combine credentials from multiple issuers, just as people rely on different institutions to establish different facts about themselves today.
The question of who issues these credentials intersects directly with the surveillance concern. If a government agency both issues agent credentials and operates the infrastructure that processes them, it has visibility into every transaction those agents conduct. One way to limit that concentration is through identity trusts: regulated intermediaries such as banks, fiduciaries, or independent organizations that issue and manage agent credentials on behalf of individuals and companies, while remaining subject to legal process if an agent’s principal needs to be identified. The intermediary holds the binding between agent and person, but only discloses it under defined conditions, much as a bank today holds customer identity information and produces it in response to lawful requests rather than broadcasting it to every counterparty in a transaction. This kind of structural separation — between the entity that issues credentials and the entities that rely on them — is what keeps accountability from collapsing into surveillance.
There are harder questions about when identity should be required at all. An agent buying a regulated financial product may need a strong, auditable connection to its principal. An agent researching a topic or interacting with a public website may have no reason to reveal who sent it. Preserving room for pseudonymous and anonymous activity matters just as much as creating accountability where it is warranted.
Authorization raises another set of questions. How narrowly should an agent's capabilities be scoped? How should they expire or be revoked? What happens when an agent delegates a task to another agent? Emerging requirements for human oversight and mechanisms to stop autonomous systems will also need to intersect with whatever identity and authorization infrastructure develops.
And the institutional framework remains unsettled. Agents may eventually require new legal concepts for responsibility and delegation, or existing structures may prove sufficient. Standards will need to determine how credentials and capabilities move across models, tools, wallets, and counterparties without recreating the platform lock-in this architecture is intended to avoid.
Most importantly, the industry still needs to determine where this level of trust is actually necessary. Not every agent interaction needs identity. The strongest demand is likely to emerge where agents cross organizational boundaries, exercise meaningful authority, or take actions with financial, legal, or regulatory consequences.
These are open questions, and that is precisely why the identity layer for agents is worth working on now. If you are working on agent identity, authorization, agentic payments, or AI governance, we'd like to compare notes.
About SpruceID: SpruceID builds digital trust infrastructure for government. We help states and cities modernize identity, security, and service delivery — from digital wallets and SSO to fraud prevention and workflow optimization. Our standards-based technology and public-sector expertise ensure every project advances a more secure, interoperable, and citizen-centric digital future.
