In one week of March 2026, vendors shipped four new security models for AI agents, among them intent-based access and hardware-attested human authorization[1].
Identity, Access and Evidence
Authentication establishes confidence that a claimant controls an authenticator bound to an identity[7]. Authorization decides what that entity may do; OAuth 2.0 is an authorization framework[8]. Neither term, by itself, specifies the evidence a later reviewer can inspect. That depends on the identifiers, tokens and records the deployment preserves.
Surveys report practical traceability difficulties, not a universal absence of identity technology. A March 2026 survey found that 68% of respondents' organizations could not clearly distinguish between human and AI agent activity[2], and a February 2026 survey reported that only 28% could reliably trace agent actions to a human or system across all environments[3].
One possible design assigns each agent an Ed25519 key pair and preserves signed records linked to that key. A public key can be a stable identifier, but it does not establish who operates the agent, which software held the key or what authority it had. Those bindings need their own trusted evidence and key-custody controls. A directory or credential issuer can supply them; it is not inherently incompatible with portable records.
If three agents share a service-account token and the system records no additional actor information, those records cannot distinguish the agents. This is a deployment limitation, not an inherent limit of OAuth. RFC 8693 defines token exchange with delegation semantics and an actor claim, including a way to represent prior actors[9].
With authenticated actor bindings and signed receipts, a record could identify the key, delegation, scope, expiry and claimed action time for later review. That would still be evidence from the recording system, not independent proof of execution or time. AGA does not ship that per-agent record today. Its published receipts use the gateway's key and carry no agent or delegation identity; attribution depends on a trusted binding to that gateway key.
How Current Systems Handle Agent Identity
The March launches discussed intent-based access and hardware-attested human approval[1]. Existing delegation standards also address actors acting on behalf of others. The relevant evaluation question is which identities, constraints and records a particular deployment actually carries across each boundary. A March IETF draft proposes composing agent authentication from WIMSE and OAuth 2.0[4]. That draft is a proposal, not an adopted standard or evidence that AGA implements it.
Four Design Questions
The following are design choices for a per-agent evidence system, not a universal definition of identity. Each exposes a boundary between the proposed architecture and the published AGA packages.
Distinct keys and trustworthy bindings
A separate key can distinguish records from different key holders. Binding that key to an agent and its operator remains an enrollment and custody problem. A pseudonymous key does not guarantee privacy: associated records can expose or correlate activity. AGA does not issue per-agent keys; one gateway key signs the receipts it produces.
Explicit delegation and scope
A constrained delegation design can require a child's scope to remain within its parent's authority. A signature authenticates the statement; the enforcement point must still validate the chain and apply its constraints. aga-mcp-server includes a delegation tool that derives narrower scopes; the delegation is not carried in the exported receipts.
Expiry and renewal authority
Authority should expire on a schedule the agent cannot extend. In aga-mcp-server 3.6.0 through 3.6.2, a TTL in the artifact terminates the session only when the client next calls measure_integrity after it has expired (nothing checks it on a schedule), and the governed client can re-attest through attest_subject and start a new window, so the agent is not yet prevented from renewing itself.
Revocation with explicit freshness rules
Revocation must change the authorization decision at the relevant enforcement points. Previously created signatures can remain mathematically valid after authority is withdrawn. A verifier needs trustworthy revocation information and a freshness policy to decide whether a delegation is acceptable; an offline verifier cannot discover a new revocation from old records alone. The published packages do not implement key-based cascading revocation.
The Delegation Chain Failure
Consider a hypothetical deployment. Agent A orchestrates research, delegates retrieval to Agent B, and B delegates formatting and delivery to Agent C. Assume they share credentials and the services neither retain distinct actor records nor propagate revocation to the downstream agents.
At 3:47 PM, the security team revokes Agent A's authorization.
Revoking A at one service would not, under these assumptions, withdraw the credentials already held by B and C. This example illustrates a coordination failure. It is not a report of an observed incident or a claim that all identity systems behave this way.
In that deployment: B and C could continue using credentials that downstream services still accept. Shared-account records alone would not establish which agent acted after the revocation. Additional telemetry or separately bound credentials could change that conclusion.
With distinct identities and coordinated revocation: records could distinguish actors, and enforcement points could reject withdrawn authority within an agreed freshness bound. AGA's gateway supplies a narrower piece: policy decisions and signed records for covered calls. Separate trusted gateway keys can distinguish gateways, not prove individual agent identity. Policy-denied calls produce DENIED receipts, but some refusal paths produce no receipt. Cascading delegation revocation is not shipped.
Identity, Evidence, and Zero Trust
Earlier articles discuss independently checkable governance records. Identity binding determines how those records can be attributed. Existing signed logs, credentials and identity systems can contribute to that evidence; the useful question is what the reviewer can establish from the actual exported record.
A valid signature ties signed bytes to a key. Attributing them to a particular agent requires trustworthy key binding and custody. Establishing authorization requires the relevant policy or delegation evidence; establishing that the described action really occurred may require a separate observation. The same signature algorithm can support very different levels of attribution depending on those surrounding controls.
Identity and action evidence are complementary. A credential can identify an actor without documenting a particular action. A gateway receipt can document its policy decision without identifying the individual agent behind the request. Neither should be sold as the other.
NIST's NCCoE has proposed work on applying existing identity standards and best practices to software and AI agents[5]. The design discussed here is one possible approach to explicit authorization, not a NIST requirement or certification. AGA contributes per-call policy records within its documented boundary, with the gateway key outside the governed agent's possession. A January 2026 CISO survey reported that 47% had observed unintended or unauthorized agent behavior and 5% felt confident they could contain a compromised agent[6]. Those responses motivate evaluation; they do not validate this architecture.
Tradeoffs
This architecture is not free. Every agent needs its own key pair, every delegation a signed artifact, and every governed action produces a receipt that must be stored and made available for verification. For simple deployments the overhead may be unnecessary.
Directory-based identity or hardware-attested approval may be suitable parts of a single-organization deployment. Whether they are sufficient depends on the actions, threat model and review requirements, not simply the number of agents.
Across organizations or during offline review, portable signed credentials and records can reduce dependence on a live directory. Federation and existing identity standards can also support this. Offline signature verification still depends on trusted keys, preserved identity bindings and a stated position on expiry and revocation freshness. Portability does not eliminate those dependencies.
The practical gap to assess is between the identities and permissions a deployment uses at runtime and the evidence a later reviewer actually receives. Can that reviewer attribute the recorded action, inspect its authority and scope, and understand the limits of the time and revocation evidence?
Of what this article describes, the per-call decision, the signed receipt and offline verification ship today. Per-agent keys, delegation carried in the receipt, and cascading revocation do not.
Explore the technical architecture, review the published research, explore the evaluation framework, or read our NIST NCCoE public comment on AI agent identity.
References
- “4 New AI Agent Security Models That Shipped This Week.” Luiz Neto, March 2026.
- “The Identity and Access Gaps in the Age of Autonomous AI.” Cloud Security Alliance and Aembit, March 2026.
- “The Visibility Gap in Autonomous AI Agents.” Cloud Security Alliance blog, February 24, 2026, reporting CSA's Securing Autonomous AI Agents survey (commissioned by Strata).
- “AI Agent Authentication and Authorization.” IETF draft-klrc-aiagent-auth-00, March 2026.
- “Accelerating the Adoption of Software and AI Agent Identity and Authorization.” NIST NCCoE concept paper, draft, February 2026.
- “2026 CISO AI Risk Report.” Cybersecurity Insiders and Saviynt, January 2026.
- NIST SP 800-63B-4: Authentication and Authenticator Management, introduction. Cited for the authentication distinction, not agent-specific certification.
- RFC 6749: The OAuth 2.0 Authorization Framework, section 1.
- RFC 8693: OAuth 2.0 Token Exchange, sections 1.1 and 4.1.
See the working implementation on npm.
AGA is a reference implementation of a published format for verifiable decision records: hash-bound policies, signed Decision Receipts, and Evidence Bundles that verify offline. The implementation is on npm. The evaluation path walks through it in working code.