When an AI agent books a flight, submits a government form, or initiates a payment, the system on the other end faces a set of questions that today's infrastructure is not well equipped to answer: Who sent this agent? What is it allowed to do? And is that authorization still valid?
These are not speculative concerns. As agents move from generating information to executing transactions, every receiving system becomes a trust decision point. The system must determine whether the agent is acting on behalf of a real, verified principal, whether the principal actually granted this specific authority, and whether that authority has not since been revoked. Without a reliable way to answer those questions, the receiving system has no basis for accepting the action.
The trust problem for AI agents reduces to three verification questions, each of which maps to a distinct layer of infrastructure.
Who sent this agent? The receiving system needs to trace the agent back to a verified person or organization. Today, most agent interactions terminate at an API key or OAuth token tied to a developer account or service, not to the individual who actually authorized the action. That is sufficient when the agent is operating within a single platform. It breaks down the moment the agent crosses an organizational boundary or takes a consequential action on someone's behalf.
What is this agent allowed to do? Knowing who sent the agent is necessary but not sufficient. The receiving system also needs to know the scope of the agent's authority. An agent authorized to check flight availability is different from one authorized to purchase a ticket. An agent permitted to look up a benefits balance is different from one authorized to submit an application. Current access control systems, built around broad application-level OAuth scopes, were not designed to express this kind of granular, purpose-specific delegation.
Is that authorization still valid? Authority changes. A person may revoke an agent's access, an organization may terminate an employee's delegation rights, or a time-limited authorization may expire. The receiving system needs a way to confirm that the authority the agent claims has not been withdrawn since it was granted. Without a revocation check, the system is relying on stale trust.
In the physical world, delegation is familiar. A person signs a power of attorney, and the designated party can act within the scope of that document. The receiving institution checks the document, confirms the authority, and may verify that it has not been revoked. The chain runs from the principal, through the delegated authority, to the action.
Agent authorization works on the same principle. Every agent ultimately acts on behalf of a person or organization. That principal grants the agent specific authority to perform specific tasks, within defined limits, for a defined period. The agent carries proof of that authority and presents it to the receiving system. The receiving system verifies the proof and checks whether it is still current.
Verifiable digital credentials provide a technical mechanism for expressing these chains. A principal's identity can be established through a credential issued by a trusted authority, such as a government-issued digital ID or an organizational credential. The delegation itself can be expressed as a separate credential, scoped to specific actions, bound to a specific agent, and carrying an expiration. The receiving system verifies both credentials at the point of interaction.
This is not a theoretical exercise. The NIST NCCoE concept paper on AI agent identity and authorization, published in February 2026, identifies exactly this pattern as a focus area: how existing identity and authorization frameworks can be adapted to agents that act autonomously on behalf of users. The IETF draft on AI agent authentication and authorization (draft-klrc-aiagent-auth), with contributors from OpenAI, Okta, Ping Identity, AWS, and Zscaler, proposes composing existing standards rather than inventing new protocols.
One of the critical design requirements for agent authorization is that authority should be specific and temporary rather than broad and persistent.
A well-designed delegation credential defines what the agent can do (submit a benefits application, not access medical records), which systems it can interact with (a specific agency portal, not any government service), a time window during which the authority is valid, and spending or transaction limits where relevant.
This is where existing access control models fall short. OAuth tokens typically grant access at the application scope level. They do not natively express constraints like "this agent may submit one form to this specific agency, on behalf of this specific person, before Friday." That level of granularity requires a credential format designed for delegation, not just authentication.
The W3C Verifiable Credentials Data Model and related specifications provide a foundation for expressing these constraints in a machine-readable, cryptographically verifiable format. The credential binds the delegation to the principal, scopes it to specific actions, and carries metadata that the receiving system can evaluate before accepting the request.
Granting authority is only half the problem. The other half is taking it away. If a principal cannot revoke an agent's authorization and have that revocation take effect immediately at every receiving system, then the delegation model has a fundamental gap.
Revocation is what makes delegation safe. It is the mechanism that lets a person say "this agent no longer acts for me" and have that statement enforced across every system the agent might interact with. Without it, a compromised agent, a terminated employee's delegation, or a simply outdated authorization continues to carry weight.
In a credential-based model, revocation is handled at the issuer level. The entity that issued the delegation credential can invalidate it. Receiving systems check revocation status as part of the verification process, the same way a relying party checks whether a digital certificate has been revoked before accepting it. The principal retains control over their own delegations rather than depending on a centralized platform to make that determination.
Any system that will accept agent-submitted requests needs to answer the three verification questions before processing the action. That requires verifying the principal's identity through a trusted credential, evaluating the scope and validity of the delegation, and checking whether the authorization has been revoked.
Systems designed today without these capabilities will need to be retrofitted when agent interactions become common. SpruceID's comments to NIST on AI agent identity and authorization outline how capability-based authorization, expressed through verifiable digital credentials, can provide this infrastructure without creating a centralized surveillance layer. The delegation chain model is not new. What is new is applying it to software agents that act at machine speed across organizational boundaries.
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.
