Government services have long been designed around a working assumption: the person navigating the web portal, submitting the form, or answering the eligibility questions is the person taking the action. That assumption is getting harder to hold. As AI agents become capable of navigating complex multi-step tasks, some residents will use them for exactly the interactions that government agencies are least prepared for: applying for benefits, renewing a professional license, requesting records, or submitting a permit application.
The question agencies are beginning to confront is not whether this will happen. It is whether their identity infrastructure is ready for it when it does.
When a person interacts with a government portal, agencies typically establish two things: that the person is who they claim to be, and that the information submitted is what the person authorized. Both of these become more complicated when the party interacting is software acting on someone's behalf.
Consider a resident who authorizes an AI agent to apply for a state benefits program. The agent may navigate eligibility questions, upload supporting documentation, and submit the application, all without the resident touching a keyboard. From the agency's perspective, the application arrives through the portal. What the agency cannot easily determine from the portal interaction alone is whether a real person authorized that specific action, what scope of authority the agent was actually granted, whether the identity verification that happened at account creation was adequate for this transaction, and whether the authorization is still current or has since been revoked.
These are not abstract policy concerns. They map directly onto fraud controls, audit requirements, and the legal validity of submissions. A benefits determination made on the basis of a fraudulently submitted application is a problem regardless of whether the fraud was committed by a person or by an agent the person never actually authorized.
Most government digital identity systems today are designed to answer one question well: is this the account holder? They do this through authentication, typically a passkey, a one-time code, or a government-issued credential. What they are generally not designed to answer is a second, distinct question: is this account holder actually present, and did they specifically authorize this action?
Authentication and identity proofing serve different functions in a digital identity system. Identity proofing establishes who someone is, usually at account enrollment. Authentication confirms that the person who enrolled is the one accessing the account at a given moment. Neither of these mechanisms, by themselves, addresses delegation: the act of a verified principal explicitly granting a software agent specific authority to act on their behalf.
The gap matters because an agent can satisfy an authentication check without the resident having authorized that specific agent for that specific transaction. If the agent holds the resident's session token, or if the resident's credentials are loaded into the agent's runtime, the system may see a valid session where the resident has effectively been removed from the loop. That is not a technical edge case; it is a predictable pattern as agents become more capable.
The brief's intended workflow is worth spelling out because it clarifies what agencies would need to verify, and where the current gaps are. A resident first goes through identity proofing, establishing who they are to the required assurance level. They then explicitly authorize a specific agent to perform a specific task within defined limits. The agent receives a credential or capability token that carries the scope of that authorization. When the agent interacts with the agency, the agency can verify both the principal's identity and the scope of the delegation. The agent performs the authorized action, which is logged. The authorization has an expiration, and the resident can revoke it.
Each step in that chain requires something government digital services are not yet consistently equipped to handle. Verifying the principal's identity at a level sufficient for a sensitive benefits transaction requires verifiable digital credentials or equivalent proofing, not just a username and password. Carrying the scope of an authorization in a form the agency can actually verify requires a credential format that expresses delegation, not just authentication. Logging agent actions in a way that supports audit requires the action to be attributed to both the agent and the principal at the time it occurs.
None of these is impossible. But they require agencies to think about authorization as a distinct layer from authentication, and to build or procure systems that treat delegation as a first-class concept rather than something to be inferred from session state.
One reason this is not a purely theoretical problem is that the credential infrastructure governments use for other purposes is already designed to carry exactly this kind of trusted information. States that have deployed mobile driver's licenses or other verifiable digital credentials have already worked through the issuer-holder-verifier model: a trusted authority issues a credential to a person, the person holds it in a wallet, and a relying party verifies it at the point of interaction.
That same architecture, applied to agent authorization, would let a resident's identity credential anchor their agent's authority. The agent would carry a delegation credential issued by the resident (or by a trusted intermediary acting on the resident's behalf), expressing what the agent is authorized to do. The agency would verify the credential at the moment of the interaction. If the resident revokes the authorization, the credential becomes invalid.
The key technical question is not whether this is architecturally possible. It is whether the delegation layer can be expressed in a credential format that agencies are already positioned to verify, and whether the governance model for issuing and managing those credentials is well-defined. As digital identity matures from pilots into policy infrastructure, these questions are moving from research to procurement decisions.
SpruceID has submitted comments to NIST on exactly these design questions. In our comments on AI agent identity and authorization, we focused on the structural requirements for a delegation layer that preserves privacy, supports auditability, and avoids creating new surveillance infrastructure. That work draws directly on our experience deploying digital identity infrastructure for state governments, where we have seen how the gap between technical capability and operational readiness shapes what actually gets implemented.
There is a naive solution to the agent authorization problem that agencies and policy teams should understand before adopting it: require agents to broadcast their principal's identity with every request. This creates an audit trail, eliminates the attribution gap, and gives the agency something to verify.
The problem is that this approach turns every agency interaction into a surveillance event, building a detailed activity record that links an individual's identity to every AI-mediated transaction across government services. Even if no single interaction seems sensitive, the aggregate picture is. An AI agent interacting with benefits, licensing, and records systems across a resident's lifetime creates a profile that is qualitatively different from the same resident manually completing forms.
The better model, which SpruceID outlined in our flagship post on the missing identity layer for AI agents, involves selective disclosure: the agent presents only what the receiving system needs to verify the relevant fact, without revealing the principal's full identity at every hop. A benefits agency needs to verify that the agent is authorized to submit on behalf of an identity-proofed resident. It does not need the resident's full identity record, agent history, or a connection to other government interactions. Selective disclosure, which is already a design principle in standards-based digital credentials, is also the right design principle for agent authorization. The SD-JWT VC format, for example, operates at the claim level within any verifiable credential, meaning its selective disclosure mechanism applies equally to delegation credentials expressing scoped authority as it does to identity credentials carrying personal attributes.
Agencies building or modernizing digital services have a practical planning question: do the identity and authorization systems being designed today accommodate agents, or will they need to be retrofitted later?
The honest answer is that no government is currently deploying production agent-authorization infrastructure at scale. NIST's NCCoE published a concept paper in February 2026 identifying agent identity and authorization as a focus area, but the work remains at the standards and architecture stage. The design choices being made now, however, will determine whether future accommodation is a configuration change or a full systems redesign.
At minimum, agencies working on digital identity modernization should be thinking about whether their identity proofing approach creates a durable, reusable credential that can anchor delegated authority later; whether their session and authorization model treats delegation as a distinct state from authentication; whether their audit logging captures enough information to attribute an action to both the agent and the principal; and whether their revocation infrastructure can handle credentials being invalidated mid-process, not just at expiration.
These are not speculative requirements. They follow directly from the agent authorization workflow described above, and they overlap significantly with the requirements that well-designed zero-trust and zero-knowledge credential systems already address.
The standard model for how digital identity trust works involves three parties: an issuer who attests to a fact, a holder who carries the credential, and a verifier who checks it. When an agent acts on a resident's behalf, the model gains a fourth actor: the principal, who authorizes the agent but may not be present at the moment of verification. The trust the agency is actually relying on at that moment is the principal's prior authorization, not their current presence.
That shift has real governance implications. It means the quality of the agency's trust depends not only on the strength of the initial identity proofing, but on the integrity of the delegation chain between the proofing event and the agent interaction: whether the delegation is specific, whether it has been revoked, and whether the credential expressing it was issued by something the agency can actually trust.
SpruceID is actively exploring how the same credential infrastructure used to power digital IDs at population scale can extend to this delegation layer. The architecture exists; the design questions are about governance, standards convergence, and where the trust anchors should sit. If your agency is building digital service infrastructure and wants to think through how agent authorization fits into your roadmap, we are interested in those conversations.
Building digital services that scale take the right foundation.
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.
