Most early thinking about AI agent security focuses on identity: how do you know who sent the agent, and whether it is what it claims to be? That question matters, but it is only half of the problem. Enterprises also need to know exactly what an agent is authorized to do once it arrives. For many organizations, those are currently two separate problems, and only the first one is getting serious architectural attention.
The distinction deserves to be sharpened. Identity is the question of provenance. Authorization is the question of permission. An agent can carry a verified credential establishing that it was sent by a specific audit firm on behalf of a specific principal, and still arrive with no machine-readable specification of what it is actually allowed to do. At that point, the receiving system has to make a judgment call, fall back to default rules, or grant far more access than the interaction requires. None of those options is acceptable in a well-governed enterprise.
Enterprise access control has evolved over decades to handle a human workforce, supplemented eventually by service accounts and APIs. Zero trust architectures extended that model to remove implicit network-level trust, requiring verification on every request rather than trusting anyone inside a perimeter. That was the right direction. The problem is that the access primitives those architectures rely on were not designed with agents in mind.
OAuth 2.0 grants access at the scope and API level. A token proves that a user authorized an application to act on their behalf, and it defines a broad category of permitted actions. What it does not support is saying: this agent may access exactly these three files, for exactly this purpose, for the next 72 hours, and only on behalf of this named principal. That level of granularity exists inside applications, built as application logic rather than as portable, machine-readable authority. A shared folder link in Google Drive is an application-level workaround, not a durable representation of delegated authority.
Service accounts compound the problem. They are credential-holding entities with no persistent binding to a human principal. They are created, configured, and often forgotten. Their permissions accrete over time as teams add scopes without removing old ones. The result is that the average enterprise service account has far broader access than any single workflow requires. When an AI agent inherits a service account or uses an API key to operate, it inherits both the access and the lack of attribution.
Signing keys and credential-based architectures can establish that an entity is who it claims to be, but verification of identity is a precondition for authorization, not a substitute for it. An enterprise that can confirm the cryptographic provenance of an agent's identity credential has answered the "who" question. It still needs to answer "what," "for how long," and "revocable by whom."
Consider what actually happens when an enterprise grants an external audit firm access to its financial systems. The current model typically involves creating a shared folder, issuing credentials to named individuals, and asking those individuals to work within those boundaries. When the firm deploys agents, the controls often do not follow. The agent may use the auditor's credentials, inherit the auditor's access, or receive a service account that the IT team creates under time pressure without carefully scoping what it can reach.
A better model looks quite different. The audit firm's agent arrives carrying a credential that specifies which organization sent it, which individual principal authorized its actions, and what scope of access was granted for this engagement. The enterprise system reads that credential, verifies its integrity, checks that the scope matches what was negotiated for this audit, and grants access only to the designated files. Every action is logged against the agent's identity and the original delegation. If the engagement concludes early, or if the firm's authorization is revoked for any reason, the credential is invalidated and the access ends without requiring a manual ticket to IT.
This is not a hypothetical capability. The underlying components, verifiable credentials, selective disclosure, cryptographic revocation, and portable delegation, already exist and are deployed at scale for human identity. What does not yet exist, in any standardized form, is the infrastructure for composing those components into a machine-readable authorization layer that agents can carry and counterparties can verify.
In a recent post, we outlined the missing identity layer for AI agents and argued that every agent ultimately acts on behalf of a person. That framing holds, and it matters. But knowing who sent an agent is the starting point for an authorization decision, not the authorization decision itself.
Think about how this works for humans. A notary who arrives to witness a document signing has gone through identity verification. That tells you who they are. But you also check whether they are licensed in your jurisdiction, whether their commission is current, and whether the scope of their authority covers this transaction. Identity and authorization are separate questions, answered by separate mechanisms, even when they involve the same person.
For agents, the separation is even more important because the scope of potential actions is so much broader and more dynamic. An agent that books travel, files documents, queries databases, executes payments, and interacts with third-party services is not performing a single bounded function. Its authorization needs to track what it is doing and for whom, across a variety of systems that may have no direct communication with each other. A single identity token established at the session's start does not answer those questions across every downstream interaction.
This is where the concept of scoped capabilities becomes important. Rather than granting access through a single broad credential, an authorization model for agents should support carrying machine-readable permissions that specify what is allowed, against which resources, for which purpose, and for how long. These permissions should be portable across the systems the agent touches, verifiable without requiring each system to query a central directory in real time, and revocable at the source when the delegation changes or expires.
Revocation is probably the most underestimated component of any agent authorization system, because it is the mechanism that makes everything else recoverable.
A human employee who leaves an organization can have their accounts suspended in a matter of hours. That window can still create exposure, but the processes and tooling exist. An AI agent that operates using an OAuth token or a long-lived API key may have no revocation mechanism at all that the deploying enterprise can exercise unilaterally. If the token lives in the agent's runtime environment and the agent is running on infrastructure the enterprise does not fully control, the question of how to stop it quickly becomes complicated.
Verifiable digital credentials support revocation architectures that allow the issuing party to invalidate a credential without relying on the holder to cooperate. The credential carries a reference to a revocation registry; verifying parties check the registry as part of credential verification. This means an enterprise or an identity trust can revoke an agent's authorization, and any system that encounters that agent will see the revocation the next time it verifies the credential. The revocation does not require contacting every system that previously granted access. It propagates through the verification process itself.
That architecture does not currently exist for the access tokens that most agents use today. Building it requires treating agent authorization as a credential problem, with the same attention to issuance, scope, lifecycle management, and revocation that well-designed human identity programs apply to their credentials.
The industry is not starting from nothing. An IETF Internet-Draft on AI agent authentication and authorization (draft-klrc-aiagent-auth) from contributors at OpenAI, Okta, Ping Identity, AWS, and Zscaler proposes composing existing standards, including WIMSE (Workload Identity in Multi System Environments), SPIFFE, OAuth 2.0, and mTLS, rather than building a new protocol stack. The draft defines a seven-layer Agent Identity Management System (AIMS) stack and rejects static API keys as structurally unsuitable for agent authentication. That is a significant signal from organizations with large production deployments.
The AAuth protocol, designed by Dick Hardt, takes a related but distinct approach. AAuth introduces the concept of a "person server" that participates in the authorization flow to enable human-in-the-loop approval when needed. The protocol is an active IETF Internet-Draft (draft-hardt-oauth-aauth-protocol, currently on its tenth revision as of August 2026), and live protocol demonstrations were presented at AAuth Night in San Francisco in July 2026. The W3C Agent Identity Registry Protocol Community Group, proposed in April 2026, is developing open specifications from a different direction, extending the verifiable credential and decentralized identifier stack into agent identity contexts.
None of these efforts has reached the status of a ratified standard that enterprises can implement against a stable specification. What they do demonstrate is that the field agrees on the shape of the problem, even if the specific architectures are still competing. Enterprises building agent infrastructure today should be making design decisions with these emerging standards in mind, rather than assuming that API key patterns will be adequate at scale.
Organizations that are deploying AI agents in workflows that touch sensitive systems, handle regulated data, or interact with external parties are making implicit authorization decisions today, whether or not they have an explicit framework for those decisions. An agent that uses a service account to read files is operating with whatever access that service account has, which in most enterprise environments is more than the current task requires.
The practical question for an enterprise AI or security team is not whether this problem exists. It is whether the authorization model they have in place is granular enough to express what agents are actually allowed to do, portable enough to carry across the systems those agents touch, and revocable quickly enough to respond when something changes. Most enterprises, evaluated honestly, will find that their current model fails at least one of those criteria, often all three.
SpruceID's work in comments to NIST on AI agent identity and authorization addresses how verifiable credential infrastructure, the same infrastructure already deployed at population scale for state digital IDs in California and Utah, could extend naturally to serve as the trust layer for agent authorization. The specific mechanism for how enterprise authorization proxies and agent wallets should work together is an open design question that we are actively exploring with potential partners. It is not a shipping product. But the building blocks exist, and the architecture is coherent enough to test.
If you are deploying agents that need access to sensitive enterprise systems and are working through how to approach delegation and authorization, we would find that conversation useful. The questions are not simple, and the answers being developed in standards bodies, in policy discussions around the AI Kill Switch Act (introduced by Representatives Lieu and Moran in July 2026 and currently before the House Committee on Homeland Security), and in enterprise security teams confronting this directly are worth comparing notes on.
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.
