Network Working Group J. Malnick Internet-Draft J. Meller Intended status: Informational R. Menke Expires: 1 November 2026 1Password April 2026 Local Delegated Agent Identity Architecture draft-1password-agent-identity-local-delegated-00 Abstract This document specifies a reference architecture for the Agent Identity Management System (AIMS) conceptual model, as introduced in the NIST concept paper [NIST-AIMS] and elaborated in [AI-AUTH], applied to the local delegated agent profile. It defines the identity architecture for delegated AI agents that execute on end- user devices (laptops, desktops) or in browser-based sandboxes, acting on behalf of a technical user. The architecture composes existing and emerging IETF, W3C, FIDO Alliance, and OpenID specifications, supplemented by the OS-level peer-process verification protocol of the companion document [OS-Workload-Attestation], to realize each of the seven AIMS functions: Identifier, Credentials, Attestation, Provisioning, Authentication, Authorization, and Monitoring. Section 4.4 maps each AIMS function to the section of this document that realizes it. This document is a reference architecture, not a protocol specification. It does not define new wire protocols; it defines how to compose existing ones for this profile. Vendor-specific extensions encountered during reference-implementation work, most notably a custom delegation-relationship identifier and proof-of- possession mechanisms for the delegated access token, have been deliberately excluded from this revision and deferred to separate work, so that the architecture is grounded only in capabilities that exist in shipping or actively-drafted specifications today. Security gaps inherent to the local trust boundary are enumerated alongside candidate mitigations. This document is the first in a six-part series specifying a reference architecture for AI agent identity across three authority models, each with a local and a remote variant. The three authority models are: human-delegated agents, which act on behalf of a present human Subject under that Subject's explicit consent; machine- or application-bounded agents, which act under the authority of a system or workflow rather than a specific human and are constrained to a pre-declared scope; and fully autonomous agents, which pursue a goal Malnick, et al. Expires 1 November 2026 [Page 1] Internet-Draft Local Delegated Agent Identity April 2026 over time with minimal direct human oversight. Each model has a local variant (executing on an end-user device or in a browser sandbox) and a remote variant (executing in managed cloud compute), yielding the six combinations covered by the series. This document covers the local human-delegated profile. Companion documents, most notably [OS-Workload-Attestation] for OS- level peer verification and the Remote Delegated companion for the cloud-managed compute profile, share the AIMS framing and refer to this document for the local-delegated-specific composition. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 October 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 4 1.1. Profile and Audience . . . . . . . . . . . . . . . . . . 4 1.2. Relationship to AIMS . . . . . . . . . . . . . . . . . . 5 1.3. Conformance . . . . . . . . . . . . . . . . . . . . . . . 6 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 3. Protocol Reference Stack . . . . . . . . . . . . . . . . . . 8 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 11 Malnick, et al. Expires 1 November 2026 [Page 2] Internet-Draft Local Delegated Agent Identity April 2026 4.1. Component Inventory . . . . . . . . . . . . . . . . . . . 11 4.2. Trust Domains . . . . . . . . . . . . . . . . . . . . . . 13 4.3. Authorization Server Endpoint Surface . . . . . . . . . . 14 4.3.1. /authorize: OAuth Authorization Endpoint (Normative) . . . . . . . . . . . . . . . . . . . . . 14 4.3.2. /token: OAuth Token Endpoint (Normative) . . . . . . 14 4.3.3. /txn-token: Transaction Token Endpoint (Emerging) . . 14 4.3.4. Endpoint Co-location . . . . . . . . . . . . . . . . 15 4.4. AIMS Function-to-Section Mapping . . . . . . . . . . . . 15 4.5. Policy Decision Point (PDP) . . . . . . . . . . . . . . . 17 5. Identification . . . . . . . . . . . . . . . . . . . . . . . 19 5.1. Human Subject Identifier . . . . . . . . . . . . . . . . 19 5.2. Workload Identity Broker (WIB) . . . . . . . . . . . . . 19 5.2.1. Role and Trust Model . . . . . . . . . . . . . . . . 19 5.2.2. WIB Enrollment with the AS . . . . . . . . . . . . . 21 5.2.3. WIB-to-Agent Workload API (Provisioning) . . . . . . 22 5.2.4. Local Process Verification (Attestation) . . . . . . 23 5.3. Agent Workload Identifier: AIMS Identifier . . . . . . . 24 5.3.1. SPIFFE ID Format . . . . . . . . . . . . . . . . . . 24 5.3.2. WIB-Issued SVID Claims: AIMS Credentials . . . . . . 25 5.4. Delegation Correlation . . . . . . . . . . . . . . . . . 26 6. Authentication (AuthN) . . . . . . . . . . . . . . . . . . . 27 6.1. Human-to-IdP Authentication . . . . . . . . . . . . . . . 27 6.2. Agent-to-AS Authentication . . . . . . . . . . . . . . . 28 6.3. Agent Credential Lifecycle . . . . . . . . . . . . . . . 29 7. Authorization (AuthZ) . . . . . . . . . . . . . . . . . . . . 30 7.1. Delegation Grant Flow . . . . . . . . . . . . . . . . . . 30 7.2. Resource Access Flow . . . . . . . . . . . . . . . . . . 32 7.3. Transaction Token Propagation . . . . . . . . . . . . . . 33 7.4. Intent Binding . . . . . . . . . . . . . . . . . . . . . 34 7.5. Optional Gateway Pattern for Txn-Token Mediation . . . . 35 7.5.1. Security Property Required of Both Patterns . . . . . 36 7.5.2. Wire Differences When the Gateway is Used . . . . . . 36 7.5.3. Gateway Threat Considerations . . . . . . . . . . . . 37 7.5.4. Implementation Guidance (Informative) . . . . . . . . 38 8. Monitoring, Audit, and Revocation . . . . . . . . . . . . . . 38 8.1. Audit Emission Requirements . . . . . . . . . . . . . . . 39 8.2. Correlation: at_jti, txn, and the Identity Chain . . . . 41 8.3. Revocation and Real-Time Signaling . . . . . . . . . . . 41 8.4. Session Invalidation Signals . . . . . . . . . . . . . . 43 8.5. Operator and Subject-Visible Surfaces . . . . . . . . . . 43 9. Complete End-to-End Sequence . . . . . . . . . . . . . . . . 44 10. Security Considerations and Gaps . . . . . . . . . . . . . . 45 10.1. Authentication Security Properties . . . . . . . . . . . 45 10.1.1. Phishing Resistance . . . . . . . . . . . . . . . . 46 10.1.2. Agent-Identity Anchoring . . . . . . . . . . . . . . 46 10.2. Authorization Security Properties . . . . . . . . . . . 46 10.2.1. Scope Attenuation . . . . . . . . . . . . . . . . . 46 Malnick, et al. Expires 1 November 2026 [Page 3] Internet-Draft Local Delegated Agent Identity April 2026 10.2.2. Temporal Bounding . . . . . . . . . . . . . . . . . 46 10.2.3. Per-Call Replay Window . . . . . . . . . . . . . . . 47 10.2.4. Delegation Revocation . . . . . . . . . . . . . . . 47 10.3. Prompt Injection Mitigation . . . . . . . . . . . . . . 47 10.4. Local Trust Boundary Specific Risks . . . . . . . . . . 48 10.4.1. Memory Scraping and Token Exfiltration . . . . . . . 48 10.4.2. Browser-Sandbox Specific Risks . . . . . . . . . . . 50 11. Comparison: Local vs. Remote Delegated Agent . . . . . . . . 50 12. Out of Scope and Future Work . . . . . . . . . . . . . . . . 51 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 13.1. Normative References . . . . . . . . . . . . . . . . . . 52 13.2. Informative References . . . . . . . . . . . . . . . . . 54 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57 About This Document . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 1. Introduction and Scope 1.1. Profile and Audience AI agents operating in the delegated authority model act on behalf of a human Subject, inheriting that Subject’s permissions and executing tasks within the scope of an explicit delegation. This document addresses the specific variant in which such an agent runs locally: either as a native process on a user’s machine (laptop, desktop, or technical workstation) or within a browser-origin sandbox (web application, browser extension, or WebAssembly module). These environments share a defining characteristic: the agent executable and any keys it manages reside in a space controlled by the end user, not by a managed infrastructure provider. This creates a fundamentally different threat model compared to a remote agent running inside a cloud-controlled compute environment: * The execution environment is not hardware-attested by default. No trusted execution environment (TEE) or TPM binding to a managed compute node is available. * The user is physically present and typically initiates the agent interactively, which enables human-in-the-loop consent flows unavailable in headless cloud deployments. * Secret material (tokens, keys) is at elevated risk from local credential theft, process injection, and memory scraping by other processes running under the same OS user account. Malnick, et al. Expires 1 November 2026 [Page 4] Internet-Draft Local Delegated Agent Identity April 2026 * Browser-based agents additionally face origin-bound credential scoping, malicious extensions, cross-origin leakage, and prompt injection via DOM manipulation. Despite these constraints, the local delegated agent is among the most prevalent agent patterns today: AI coding agents (e.g., terminal-based agentic tools that query upstream APIs and execute commands on behalf of a user), local LLM orchestrators, and IDE- integrated assistants all fit this profile. | *Scope Note* | | This document covers: (a) native local process agents, and (b) | browser-sandbox agents. It does not cover mobile apps | (addressed in a future appendix), server-side agents operating | inside managed cloud environments (see Remote Delegated, doc 2 | of 6), or sub-agents spawned by another agent (see Bounded/ | Autonomous, docs 3 to 6). 1.2. Relationship to AIMS The Agent Identity Management System (AIMS) conceptual model originates in the NIST concept paper [NIST-AIMS] and is elaborated as a normative seven-function framework in [AI-AUTH]. AIMS describes the set of functions required to establish, maintain, and evaluate the identity and permissions of an agent workload: Identifier, Credentials, Attestation, Provisioning, Authentication, Authorization, and Monitoring. AIMS itself is a model, not a wire protocol; it does not prescribe the specific transports, token formats, or platform primitives used to realize each function. This document is a reference architecture for AIMS in the local- delegated profile. Each AIMS function is bound to a concrete specification or specification cluster: SPIFFE workload identifiers [SPIFFE], JWT-SVID credentials [WIMSE-CREDS], OS-mediated peer attestation per [OS-Workload-Attestation], JIT credential provisioning via the Workload API of [OS-Workload-Attestation] Section 3, OAuth Token Exchange [RFC8693] for authentication, scope- attenuated delegated access tokens with per-call Txn-Token [OAUTH-TXN-TOKENS] propagation for authorization, and the audit and revocation surface of Section 8 for monitoring. Where two or more profiles in the 1Password agent identity series share an AIMS function realization, the realization is specified once in the appropriate companion document and referenced from each profile that uses it; where a function differs by profile, this document specifies the local-delegated composition explicitly. Malnick, et al. Expires 1 November 2026 [Page 5] Internet-Draft Local Delegated Agent Identity April 2026 Section 4.4 provides the AIMS function-to-section mapping. Sections 5 through 8 correspond, in order, to the AIMS functional groups of identity establishment, authentication, authorization, and monitoring. Section 12 enumerates work deliberately deferred from this revision. 1.3. Conformance An implementation conforms to this reference architecture if it realizes each AIMS function as specified in the corresponding section, satisfies the normative requirements of the [OS-Workload-Attestation] companion (which this document references as the realization of the Attestation and Provisioning functions), and does not relax the security properties enumerated in Section 10. An implementation that omits a function, for example by omitting Monitoring or relaxing the per-issuance peer verification of [OS-Workload-Attestation] Section 4, does not conform to this profile. Implementations MAY add capabilities beyond those specified here (for example, the deferred work enumerated in Section 12), provided the additions do not weaken the security properties of any AIMS function realized in this document. 2. Conventions and Terminology The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, and MAY in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174]. Agent: A workload capable of LLM-guided reasoning and tool execution. AIMS: Agent Identity Management System. The conceptual seven- function model originating in [NIST-AIMS] and elaborated in [AI-AUTH]. Functions: Identifier, Credentials, Attestation, Provisioning, Authentication, Authorization, Monitoring. Subject: The technical user on whose behalf the agent acts. Delegation: The explicit, scoped transfer of authority from Subject to Agent. Local Agent: An agent process running on the Subject’s device or in a browser origin controlled by the Subject’s session. Browser-Sandbox Agent: An agent executing within a browser’s JavaScript / WASM origin. Treated as equivalent to local agent for purposes of this document. Malnick, et al. Expires 1 November 2026 [Page 6] Internet-Draft Local Delegated Agent Identity April 2026 IdP: Identity Provider. Issues identity tokens (ID tokens) about the Subject. AS: Authorization Server. Issues access tokens and manages authorization grants. WIB: Workload Identity Broker. The architectural component that brokers verifiable workload identity for local agents. Specified in [OS-Workload-Attestation] and applied in Section 5.2 of this document. TTS: Transaction Token Service [OAUTH-TXN-TOKENS]. Issues Txn-Tokens scoped to a single transaction call-chain. Txn-Token: A short-lived, signed JWT that propagates immutable identity and intent context through a call chain. WIMSE ID: A URI-format workload identifier as defined in [WIMSE-IDENTIFIER]. SPIFFE ID: The SPIFFE realization of a workload identifier per [SPIFFE]. In this document, the workload identifier scheme used to realize the AIMS Identifier function. JWT-SVID: A SPIFFE Verifiable Identity Document encoded as a signed JSON Web Token. The credential format used to realize the AIMS Credentials function. PDP: Policy Decision Point. Evaluates authorization policy against runtime signals. PEP: Policy Enforcement Point. Enforces decisions from the PDP. PKCE: Proof Key for Code Exchange [RFC7636]. Prevents authorization code interception attacks in public clients. act claim: JWT ‘actor’ claim carrying the agent’s identifier, distinguishing it from the delegating Subject. Intent Binding: The cryptographic association of a Txn-Token with the specific user-declared goal that initiated the agent task. Prompt Injection: An attack in which adversarial content in agent tool outputs manipulates the LLM’s subsequent actions beyond the user’s intended delegation scope. Malnick, et al. Expires 1 November 2026 [Page 7] Internet-Draft Local Delegated Agent Identity April 2026 3. Protocol Reference Stack The following table lists all normative and informative specifications referenced in this document. Status reflects standing as of April 2026. The AIMS source documents [NIST-AIMS] and [AI-AUTH] are listed first as the conceptual model this document realizes; the remaining entries are organized by AIMS function area where applicable. +=========================+==============+=============+===============+ |Tag |Title |Status |AIMS Function | +=========================+==============+=============+===============+ |[NIST-AIMS] |NIST AIMS |NIST Concept |Model (all) | | |Concept Paper |Paper | | +-------------------------+--------------+-------------+---------------+ |[AI-AUTH] |AI Agent |I-D |Model (all) | | |Authentication|(Emerging) | | | |and | | | | |Authorization | | | +-------------------------+--------------+-------------+---------------+ |[OS-Workload-Attestation]|OS-Level |Companion |Attestation, | | |Workload |(this series)|Provisioning | | |Attestation | | | +-------------------------+--------------+-------------+---------------+ |[SPIFFE] |SPIFFE: Secure|Standard |Identifier, | | |Production |(Informative)|Credentials | | |Identity | | | | |Framework for | | | | |Everyone | | | +-------------------------+--------------+-------------+---------------+ |[WIMSE-IDENTIFIER] |WIMSE Workload|I-D |Identifier | | |Identifier |(Emerging) | | +-------------------------+--------------+-------------+---------------+ |[WIMSE-CREDS] |WIMSE Workload|I-D |Credentials | | |Credentials |(Emerging) | | +-------------------------+--------------+-------------+---------------+ |[WIMSE-ARCH] |WIMSE |I-D |Identifier, | | |Architecture |(Emerging) |Credentials | +-------------------------+--------------+-------------+---------------+ |[WIMSE-S2S] |WIMSE |I-D |Authentication | | |Workload-to- |(Emerging) | | | |Workload | | | | |Authentication| | | +-------------------------+--------------+-------------+---------------+ |[WIMSE-HTTP-SIG] |WIMSE |I-D |Authentication | | |Workload-to- |(Emerging) | | | |Workload Auth | | | | |with HTTP | | | Malnick, et al. Expires 1 November 2026 [Page 8] Internet-Draft Local Delegated Agent Identity April 2026 | |Signatures | | | +-------------------------+--------------+-------------+---------------+ |[RFC6749] |OAuth 2.0 |RFC |Authentication,| | |Authorization |(Normative) |Authorization | | |Framework | | | +-------------------------+--------------+-------------+---------------+ |[RFC7636] |PKCE for OAuth|RFC |Authentication | | |Public Clients|(Normative) | | +-------------------------+--------------+-------------+---------------+ |[RFC8693] |OAuth 2.0 |RFC |Authentication | | |Token Exchange|(Normative) | | +-------------------------+--------------+-------------+---------------+ |[RFC9700] |OAuth 2.0 |RFC/BCP |Authentication | | |Security BCP |(Normative) | | +-------------------------+--------------+-------------+---------------+ |[RFC9068] |JWT Profile |RFC |Credentials | | |for OAuth 2.0 |(Normative) | | | |Access Tokens | | | +-------------------------+--------------+-------------+---------------+ |[RFC7519] |JSON Web Token|RFC |Credentials | | |(JWT) |(Normative) | | +-------------------------+--------------+-------------+---------------+ |[RFC7591] |OAuth 2.0 |RFC |Provisioning | | |Dynamic Client|(Normative) | | | |Registration | | | +-------------------------+--------------+-------------+---------------+ |[RFC9421] |HTTP Message |RFC |Authentication | | |Signatures |(Normative) | | +-------------------------+--------------+-------------+---------------+ |[OAUTH-v2.1] |The OAuth 2.1 |I-D |Authentication | | |Authorization |(Informative)| | | |Framework | | | +-------------------------+--------------+-------------+---------------+ |[OAUTH-TXN-TOKENS] |Transaction |I-D |Authorization | | |Tokens (Txn- |(Emerging) | | | |Tokens) | | | +-------------------------+--------------+-------------+---------------+ |[OAUTH-TXN-AGENTS] |Transaction |I-D |Authorization | | |Tokens For |(Emerging) | | | |Agents | | | +-------------------------+--------------+-------------+---------------+ |[OAUTH-CHAIN] |OAuth Identity|I-D |Authorization | | |and |(Emerging) | | | |Authorization | | | | |Chaining | | | | |Across Domains| | | +-------------------------+--------------+-------------+---------------+ |[OAUTH-ID-JAG] |Identity |I-D |Authentication | Malnick, et al. Expires 1 November 2026 [Page 9] Internet-Draft Local Delegated Agent Identity April 2026 | |Assertion JWT |(Emerging) | | | |Authorization | | | | |Grant | | | +-------------------------+--------------+-------------+---------------+ |[OAUTH-ATTEST] |OAuth 2.0 |I-D |Attestation | | |Attestation- |(Emerging) | | | |Based Client | | | | |Authentication| | | +-------------------------+--------------+-------------+---------------+ |[OIDC-Core] |OpenID Connect|Final |Authentication | | |Core 1.0 |(Normative) | | | |(errata 2) | | | +-------------------------+--------------+-------------+---------------+ |[WebAuthn-L3] |Web |W3C Working |Authentication | | |Authentication|Draft | | | |Level 3 | | | +-------------------------+--------------+-------------+---------------+ |[FIDO2-CTAP] |FIDO2 Client- |FIDO Proposed|Authentication | | |to- |Standard | | | |Authenticator | | | | |Protocol | | | | |(CTAP2) | | | +-------------------------+--------------+-------------+---------------+ |[CAEP] |OpenID |OpenID Final |Monitoring, | | |Continuous | |Authorization | | |Access | | | | |Evaluation | | | | |Profile 1.0 | | | +-------------------------+--------------+-------------+---------------+ |[NIST-63-4] |NIST SP |NIST Final |Authentication | | |800-63-4 |(July 2025) | | | |Digital | | | | |Identity | | | | |Guidelines | | | +-------------------------+--------------+-------------+---------------+ |[NIST-207] |NIST SP |NIST Final |Model (all) | | |800-207 Zero | | | | |Trust | | | | |Architecture | | | +-------------------------+--------------+-------------+---------------+ |[RATS-ARCH] |Remote |RFC 9334 |Attestation | | |Attestation | | | | |Procedures | | | | |(RATS) | | | | |Architecture | | | +-------------------------+--------------+-------------+---------------+ |[MCP] |Model Context |Informational|(reference) | | |Protocol | | | Malnick, et al. Expires 1 November 2026 [Page 10] Internet-Draft Local Delegated Agent Identity April 2026 | |Specification | | | +-------------------------+--------------+-------------+---------------+ Table 1 4. Architecture Overview The local delegated agent architecture consists of the following components operating within or adjacent to the local trust boundary. Each component participates in one or more AIMS functions; Section 4.4 enumerates the function-to-section mapping for the AIMS reader. 4.1. Component Inventory * Human Subject : The technical user who initiates the agent task, provides consent, and retains ultimate authority over the agent’s delegated scope. Source of the AIMS Authentication input at consent time and of the user-presence assertions consumed by the Authorization function. * Local Agent Process / Browser-Sandbox Agent The local agent workload. Runs as a native OS process (e.g., a CLI tool, a desktop application, an Electron app) or as JavaScript / WASM inside a browser origin. Holds ephemeral credentials scoped to the delegated resource and a WIMSE-compatible identifier. The bearer of the AIMS Identifier and the consumer of AIMS Credentials issuance. * Identity Provider (IdP) : Authenticates the human Subject and issues ID tokens (OIDC). Acts as the root of trust for the delegation chain. Realizes the human-side AIMS Authentication function. Typically a remote OIDC-compliant enterprise IdP accessed over TLS. * Authorization Server (AS) : Issues access tokens scoped to specific resources and delegations. Operates as a federated relying party to the IdP for human authentication, and as the OAuth Authorization Server for downstream Resource Servers. Processes the Token Exchange (Section 7.1) that elevates the Subject’s federated access token into an agent-scoped delegated access token carrying the act claim. Validates WIB-issued JWT- SVIDs (Section 5.2) presented as actor_token against its enrolled- WIB trust bundle. Realizes the agent-side AIMS Authentication and Authorization functions. The AS’s endpoint surface is detailed in Section 4.3. * Workload Identity Broker (WIB) A code-signed local daemon that Malnick, et al. Expires 1 November 2026 [Page 11] Internet-Draft Local Delegated Agent Identity April 2026 mediates identity issuance to agent workloads on the Subject’s device. Holds a device-bound key pair enrolled with the AS (Section 5.2.2), exposes a SPIFFE-style Workload API to local agents per [OS-Workload-Attestation] Section 3, and issues short-lived JWT-SVIDs after performing OS-level peer-process verification per [OS-Workload-Attestation] Section 4. The WIB is the architectural component that realizes the AIMS Attestation function on unattested local hardware and the AIMS Provisioning function (JIT issuance per task). Specified in detail in Section 5.2. * Transaction Token Service (TTS) Issues short-lived Txn-Tokens per [OAUTH-TXN-TOKENS] and [OAUTH-TXN-AGENTS]. Binds the transaction’s immutable context (subject identity, agent identity, user intent). Logically distinct from the AS, but typically realized as an additional endpoint on the AS within the same trust authority (Section 4.3.4). Realizes the per- call leg of the AIMS Authorization function. The endpoint name and grant_type semantics defined in [OAUTH-TXN-TOKENS] are an emerging Internet-Draft and SHOULD be expected to change. Each logical trust domain MUST have exactly one TTS. * Policy Decision Point (PDP) An architectural role per [NIST-207] and [AI-AUTH] Section 4. In this architecture, the PDP role is realized as policy evaluation embedded within the AS’s /token and /txn-token endpoints. Section 4.5 specifies the PDP’s position, inputs, and decision surfaces in detail. * Policy Enforcement Point (PEP) An architectural role per [NIST-207]. Realized by each Resource Server’s request- validation layer, which validates the access token’s signature and audience, the Txn-Token’s identity context and intent hash, and the requested action against the granted scope. Realizes the enforcement leg of the AIMS Authorization function and the per-call audit emission consumed by AIMS Monitoring (Section 8). The PEP is not a separately-deployed service in this architecture. * Resource Server(s) : The upstream services the agent interacts with (APIs, databases, SaaS apps, MCP servers). Validate access tokens and / or Txn-Tokens, and enforce resource-level access policy. * Credential Store : A secure local secret store backed by the platform OS (macOS Keychain with Secure Enclave, Windows DPAPI / CNG with TPM, Linux Secret Service / TPM where available, or in- browser Web Crypto non-extractable keys). Used by the WIB to hold its enrolled device-bound key. The agent process itself does not Malnick, et al. Expires 1 November 2026 [Page 12] Internet-Draft Local Delegated Agent Identity April 2026 hold long-lived asymmetric key material in this profile (the agent’s identity is established by presenting the WIB-issued SVID rather than by holding its own key); the Credential Store’s role here is to protect the WIB’s device key and any short-lived material the agent obtains from the AS. The substrate that protects AIMS Credentials at rest in the local trust domain. 4.2. Trust Domains This architecture spans two trust domains: * Local Trust Domain : The agent process, the credential store, the WIB, and any locally-bound tool processes. Bounded by the OS user account / browser origin. Inherently lower assurance than a managed server environment. * Remote Trust Domain : The IdP, AS, TTS, PDP, and Resource Servers. Operates in managed infrastructure. Connected to the Local Trust Domain over mutually authenticated TLS channels. Tokens MUST NOT flow between trust domains without validation at the boundary. The agent’s access token, minted by the remote AS with the Subject’s delegation, crosses from Remote to Local when delivered to the agent. The Txn-Token, once minted for a call chain, crosses from Local to Remote with each API call. | *Architectural Constraint* | | Because local agents cannot provide hardware-backed TEE | attestation, the remote AS and TTS MUST treat the local trust | domain as a lower-assurance environment. This is the AIMS | Attestation function operating in its reduced-assurance mode | for the local-delegated profile. Compensating controls are: | (1) human-in-the-loop consent at delegation time (FIDO2 / | WebAuthn phishing-resistant authn), (2) short-lifetime | delegated access tokens (≤ 15 minutes) and even shorter Txn- | Tokens (≤ 60 seconds) bounding the per-call exploitation | window, (3) per-issuance peer verification at the WIB binding | the agent identity to a code-signed binary, and (4) continuous | PDP evaluation on every Txn-Token issuance. The AS reflects | the achieved attestation depth in policy via the SVID’s | attest_methods claim (Section 5.3.2). Malnick, et al. Expires 1 November 2026 [Page 13] Internet-Draft Local Delegated Agent Identity April 2026 4.3. Authorization Server Endpoint Surface The Authorization Server in this architecture exposes three endpoints. Two are normative OAuth endpoints; one is defined by an emerging Internet-Draft. This section describes the endpoint surface and its standards posture; the detailed flows realized at each endpoint are specified in Sections 5.2.2, 6.1, 7.1, and 7.3. 4.3.1. /authorize: OAuth Authorization Endpoint (Normative) Defined normatively by RFC 6749 Section 3.1. In this architecture, the /authorize endpoint is used for the standing-delegation consent ceremony, in which the Subject authorizes a specific agent to act on their behalf for a defined scope. Authentication of the Subject is performed at the IdP (Section 6.1) and federated to the AS via OIDC; the /authorize endpoint itself records the authorization decision, not the authentication. The granted authorization is persisted as standing delegation policy that the AS consults at the /token endpoint when minting delegated access tokens for the agent. PKCE [RFC7636] applies per [OAUTH-v2.1] and [RFC9700]. Phishing-resistant authentication via WebAuthn [WebAuthn-L3] is REQUIRED. 4.3.2. /token: OAuth Token Endpoint (Normative) Defined normatively by RFC 6749 Section 3.2 and RFC 8693 (Token Exchange). The delegation grant flow detailed in Section 7.1 is realized at this endpoint, with grant_type=urn:ietf:params:oauth:grant-type:token-exchange. The AS validates the Subject’s federated access token (issued by the IdP), the WIB-issued JWT-SVID provided as the actor_token (Section 5.2.3), and the requested scope against the standing delegation policy from /authorize. On success, it issues a delegated access token with sub set to the Subject’s identifier and act set to the agent’s SPIFFE identifier. This endpoint is invoked at the start of each agent task that requires fresh delegated authority. 4.3.3. /txn-token: Transaction Token Endpoint (Emerging) Defined by [OAUTH-TXN-TOKENS] (draft-ietf-oauth-transaction-tokens- 08) and extended for AI agent contexts by [OAUTH-TXN-AGENTS] (draft- oauth-transaction-tokens-for-agents-00). Both are Internet-Drafts in active development as of April 2026. The endpoint name, grant_type identifier, and request / response envelope are subject to change. The Txn-Token issuance flow detailed in Section 7.3 is realized at this endpoint. Implementations SHOULD track the current draft revisions and treat this endpoint as unstable. Malnick, et al. Expires 1 November 2026 [Page 14] Internet-Draft Local Delegated Agent Identity April 2026 4.3.4. Endpoint Co-location This document treats the AS, TTS, and embedded PDP role as a single trust authority. Implementations MAY deploy them as separate services or as a single service exposing the three endpoint paths above. The trust bundle of enrolled WIB device keys (Section 5.2.2) MUST be consistent across all three endpoints. Where a separately- deployed TTS is used, it MUST share the AS’s trust bundle and standing delegation policy store. 4.4. AIMS Function-to-Section Mapping The seven AIMS functions, as defined in [NIST-AIMS] and [AI-AUTH], are realized in this document as follows. The right-hand column lists the protocol or specification that supplies the wire-level mechanics; this document supplies the local-delegated-specific composition and the normative requirements that bind the parts together. +================+======================+===========================+ | AIMS Function | Realization in this | Underlying mechanism | | | document | | +================+======================+===========================+ | Identifier | Section 5.3: SPIFFE | [SPIFFE], | | | ID assigned per | [WIMSE-IDENTIFIER] | | | agent instance, | | | | encoded as the sub | | | | claim of the WIB- | | | | issued JWT-SVID and | | | | propagated as the | | | | act.sub of the | | | | delegated access | | | | token. | | +----------------+----------------------+---------------------------+ | Credentials | Section 5.3.2: JWT- | [WIMSE-CREDS], [RFC9068], | | | SVID minted by the | [OAUTH-TXN-TOKENS] | | | WIB, signed with | | | | the WIB's enrolled | | | | device key. | | | | Lifetime ≤ 10 | | | | minutes. | | | | Section 7.1 | | | | delegated AT minted | | | | by AS, lifetime ≤ | | | | 15 minutes. | | | | Section 7.3 Txn- | | | | Token, lifetime ≤ | | | | 60 seconds. | | Malnick, et al. Expires 1 November 2026 [Page 15] Internet-Draft Local Delegated Agent Identity April 2026 +----------------+----------------------+---------------------------+ | Attestation | Section 5.2.4: OS- | [OS-Workload-Attestation] | | | level peer-process | §4 | | | verification | | | | performed by the | | | | WIB on every | | | | issuance, six-step | | | | flow with platform- | | | | specific | | | | realization. | | | | Outcome reflected | | | | in the | | | | attest_methods SVID | | | | claim. | | +----------------+----------------------+---------------------------+ | Provisioning | Section 5.2.3: | [OS-Workload-Attestation] | | | Workload API | §3 | | | (FetchJWTSVID) over | | | | a host-only IPC | | | | channel, single- | | | | shot or long-lived- | | | | with-revalidation | | | | connection model. | | | | JIT issuance per | | | | agent task; no pre- | | | | minting. | | +----------------+----------------------+---------------------------+ | Authentication | Section 6.1: human | [WebAuthn-L3], | | | Subject | [FIDO2-CTAP], [RFC8693], | | | authenticates to | [NIST-63-4] | | | the IdP via | | | | WebAuthn / FIDO2 | | | | (AAL2 minimum, AAL3 | | | | with hardware- | | | | attested device- | | | | bound passkey). | | | | Section 6.2: agent | | | | authenticates to | | | | the AS via OAuth | | | | 2.0 Token Exchange | | | | presenting the WIB- | | | | issued SVID as | | | | actor_token; the | | | | SVID itself is the | | | | proof of agent | | | | identity. | | +----------------+----------------------+---------------------------+ | Authorization | Section 7.1: | [RFC8693], | Malnick, et al. Expires 1 November 2026 [Page 16] Internet-Draft Local Delegated Agent Identity April 2026 | | delegated access | [OAUTH-TXN-TOKENS], | | | token with | [OAUTH-TXN-AGENTS] | | | mandatory scope | | | | attenuation and sub | | | | / act split. | | | | Section 7.3: per- | | | | call Txn-Token | | | | carrying immutable | | | | identity and intent | | | | context. | | | | Section 7.4: intent | | | | binding via SHA-256 | | | | of user-declared | | | | task. PDP | | | | evaluation per | | | | Section 4.5. | | +----------------+----------------------+---------------------------+ | Monitoring | Section 8: audit | [CAEP], this document §8 | | | emissions at each | | | | PEP keyed on | | | | standard JWT | | | | identifiers (the | | | | AT's jti and the | | | | Txn-Token's txn), | | | | revocation | | | | propagation, and | | | | CAEP-based real- | | | | time signaling. | | +----------------+----------------------+---------------------------+ Table 2 The mapping above is the contract this reference architecture keeps with the AIMS model. An implementation that omits any row MUST NOT claim conformance to this profile, regardless of the strength of the remaining rows; the AIMS model treats the seven functions as jointly necessary. 4.5. Policy Decision Point (PDP) The Policy Decision Point is an architectural role per [NIST-207] and a first-class component of the AIMS Authorization function per [AI-AUTH] Section 4. This section makes the PDP’s presence and operation explicit, separately from the architecture’s component inventory, because the document treats authorization as the function under which the most policy decisions are made and the function for which the cleanest existing-spec mapping exists. Malnick, et al. Expires 1 November 2026 [Page 17] Internet-Draft Local Delegated Agent Identity April 2026 In this reference architecture, the PDP is realized as policy evaluation embedded within the AS’s /token and /txn-token endpoints rather than as a separately-deployed service. There are two PDP evaluation points, each with distinct inputs and a distinct decision class: * Per-task PDP evaluation at /token. Inputs: the Subject’s federated access token (sub, scopes, audience), the WIB-issued JWT-SVID and its attest_methods claim (the AIMS Attestation evidence; see Section 5.3.2), the standing delegation policy recorded at /authorize for this (Subject, agent) pair, and the requested scope. Decision: whether to mint a delegated access token, and at what scope (always a strict subset of the Subject’s scope per Section 7.1’s mandatory attenuation requirement). The per-task PDP MAY apply graduated trust based on attest_methods. For example, it MAY refuse high-sensitivity scopes for SVIDs whose attest_methods array does not include hardware-attested binary identity. * Per-call PDP evaluation at /txn-token. Inputs: the previously- minted delegated access token (sub, act, scope), the agent- supplied intent_hash (Section 7.4), the agent-supplied tool_call descriptor, and runtime context signals available at the trust authority (recent revocation events, anomaly signals, time-of-day risk factors per deployment policy). Decision: whether to mint a Txn-Token for this specific upstream invocation, and which intent context to bind into its tctx claim. The PDP is the surface at which deployment-specific policy lives. This document does not specify policy content; it specifies the PDP’s position in the architecture, its inputs, and the standard claim surfaces it consults. Implementers SHOULD consult [NIST-207] for the underlying Zero Trust framing, [AI-AUTH] for the agent-specific PDP role definition, [CAEP] for the input channel that delivers real-time revocation events to the per-call PDP, and [OAUTH-TXN-TOKENS] / [OAUTH-TXN-AGENTS] for the wire format the per-call PDP’s decision is rendered into. The PDP is NOT a separately-deployed service in this architecture, but the role MAY be externalized if a deployment chooses to do so. An externalized PDP would be consulted synchronously by the AS during /token and /txn-token request handling. The wire format for that consultation is out of scope for this document; implementations doing this SHOULD use a recognized policy-evaluation transport such as those discussed in [NIST-207]. Malnick, et al. Expires 1 November 2026 [Page 18] Internet-Draft Local Delegated Agent Identity April 2026 5. Identification This section specifies the identifiers and identity-issuance mechanisms used in the local delegated agent architecture. It is the realization of four AIMS functions for the local-delegated profile: Identifier (Section 5.3), Credentials (Section 5.3.2), Attestation (Section 5.2.4, by reference to [OS-Workload-Attestation] Section 4), and Provisioning (Section 5.2.3, by reference to [OS-Workload-Attestation] Section 3). Three classes of identifier are defined: the Human Subject Identifier (Section 5.1), the Agent Workload Identifier (Section 5.3), and the Delegation Relationship Identifier (Section 5.4). Section 5.2 specifies the Workload Identity Broker (WIB), the architectural component that solves the central challenge of issuing verifiable identities to agent workloads running on unattested end-user hardware. 5.1. Human Subject Identifier The Human Subject Identifier is the IdP-issued sub claim that names the human user. Its format is determined by the IdP and is outside the scope of this document; typical values include opaque user UUIDs, email addresses, or directory-service identifiers. The Subject Identifier appears as the sub claim of the IdP-issued ID token (Section 6.1), as the sub claim of the delegated access token issued by the AS at /token (Section 7.1), and as the principal claim of the Txn-Token issued at /txn-token (Section 7.3). 5.2. Workload Identity Broker (WIB) 5.2.1. Role and Trust Model The Workload Identity Broker (WIB) is the locally-resident trust anchor that brokers agent workload identity on unattested end-user devices. In AIMS terms, the WIB is the component that realizes the Attestation function (by performing OS-level peer-process verification on every issuance) and the Provisioning function (by issuing JIT credentials only after Attestation has succeeded for the requesting peer). Without the WIB, the local-delegated profile has no AIMS-compliant Attestation surface; with it, the chain of trust is anchored in OS code-signing rather than hardware-rooted attestation. The WIB pattern addresses the binary attestation gap (see Gap G-7, Section 10.4) not by providing hardware-rooted attestation, which is unavailable on consumer hardware, but by consolidating local trust in a single hardened, code-signed daemon that issues short-lived workload identities only to authenticated callers. Malnick, et al. Expires 1 November 2026 [Page 19] Internet-Draft Local Delegated Agent Identity April 2026 The Workload Identity Broker is an architectural role that may be realized differently across deployment models. In this document (local delegated), the WIB is realized as a code-signed application running on the Subject’s device, and the verification primitive is OS-level code signing checked against an allowlist (Section 5.2.4). In the companion remote delegated document, the WIB role is fulfilled by the AS itself via workload identity federation with the agent’s cloud-platform identity issuer; the verification primitive is cryptographic validation of platform-issued workload tokens rather than local code-signing. Across both deployments the WIB is the AIMS Attestation realization; the platform-specific verification mechanism differs. In practice, the WIB is realized as an existing user-trusted application on the device (typically a credential management product) extended to broker workload identities. The specification is vendor- neutral; conforming implementations may be provided by any vendor whose application meets the requirements of this section. The WIB MUST satisfy the following requirements: * Be a code-signed application, distributed and signed by a recognized vendor, and notarized by the host platform where applicable. * Hold a device-bound asymmetric key pair generated in the platform secure key store (Apple Secure Enclave, Windows TPM, or equivalent). The private key MUST NOT leave the secure store. * Be enrolled with the AS at install time (Section 5.2.2). The AS MUST hold the WIB’s device public key in its trust bundle. * Expose a Workload API (Section 5.2.3) on a host-only IPC channel. * Verify the code-signing identity and bundle / product identity of every connecting agent process per [OS-Workload-Attestation] Section 4 before issuing any credential. * Issue short-lived JWT-SVIDs ([SPIFFE], [WIMSE-CREDS]) to verified agent callers, signed with its enrolled device key. Malnick, et al. Expires 1 November 2026 [Page 20] Internet-Draft Local Delegated Agent Identity April 2026 The trust model is: the AS trusts the WIB (via enrollment); the WIB trusts the OS code-signing subsystem to verify the calling process’s binary identity; the agent inherits a verifiable identity by presenting a WIB-issued SVID. To impersonate a verified agent, an attacker MUST either compromise the OS code-signing subsystem, subvert the WIB’s allowlist population channel, or compromise the WIB itself, each of which is substantially harder than executing a process under the same OS user account. The residual gap is enumerated in Gap G-7. 5.2.2. WIB Enrollment with the AS The WIB MUST enroll its device-bound public key with the AS prior to issuing any agent SVID. Enrollment establishes the WIB as a recognized credential authority within the trust domain. Two enrollment tiers are defined; a conforming implementation MUST realize at least one. The enrollment ceremony is performed at the AS’s /authorize endpoint (Section 4.3.1), with the AS recording the result as an enrolled-WIB entry in its trust bundle. Tier 1: Managed-Device Enrollment. REQUIRED for enterprise deployments. The WIB generates a key pair in the platform secure key store with platform attestation (Apple Managed Device Attestation, Microsoft TPM Attestation, or equivalent). The platform attestation is conveyed to the AS as RATS evidence per [RATS-ARCH]. Enrollment is performed via the enterprise IdP / MDM channel, which authorizes the device. Dynamic Client Registration [RFC7591] is the wire format. The AS records the WIB’s public key, device identifier, and binding to the enterprise tenant. Tier 2: User-Anchored Enrollment. REQUIRED for consumer / unmanaged- device deployments. The WIB generates a key pair in the platform secure key store. Enrollment is anchored by a user WebAuthn ceremony [WebAuthn-L3]: the user authenticates to the AS at /authorize with a phishing-resistant credential, and within that ceremony the WIB’s public key and any available device-binding evidence are conveyed and signed under the user’s authorization. The AS records the WIB’s public key bound to the authenticating user’s identity. Tier 2 carries lower assurance than Tier 1 because platform attestation may be unavailable or self-asserted; the AS MUST apply additional policy controls (e.g., shorter SVID lifetimes, stricter scope ceilings, more frequent re-attestation) to Tier 2 enrollments. After enrollment, the AS publishes the WIB’s public key in its trust bundle, addressable by a WIB identifier of the form: wib:///device/ Malnick, et al. Expires 1 November 2026 [Page 21] Internet-Draft Local Delegated Agent Identity April 2026 The trust bundle is consulted at /token and /txn-token whenever an SVID is presented as actor_token. 5.2.3. WIB-to-Agent Workload API (Provisioning) The Workload API is the realization of the AIMS Provisioning function for this profile: dynamic, just-in-time credential issuance keyed on the runtime identity of the requesting workload. The WIB exposes a Workload API to local agents that follows the patterns of [SPIFFE] and [WIMSE-CREDS] over a host-only IPC channel. The protocol is specified in full in [OS-Workload-Attestation] Section 3, which defines: * Supported request types (FetchJWTSVID required; FetchJWTBundles optional; FetchX509SVID not supported in this architecture). * Per-platform IPC transport bindings: macOS XPC services and Unix domain sockets, Windows named pipes with same-session DACL pinning, Linux abstract-namespace sockets with kernel-atomic name claiming, and browser-sandbox native messaging. * A user-gesture extension for high-sensitivity SPIFFE IDs, with cadence rules differentiated by agent_class (every-issuance gesture for ai_agent; bounded re-prompt window for developer_tool). * A closed-namespace error model and two-tier rate limiting (per- source pre-verification limit; per-verified-peer post-verification limit). * The complete issuance flow including allowlist-miss handling and a separate first-run onboarding path (RegisterPeer). The wire schema for the FetchJWTSVID request and response, and for all error codes, is provided in [OS-Workload-Attestation] Appendix A. The provisioning surface is intentionally narrow: there is no offline mode, no batch issuance, and no pre-mint pathway. Every credential the agent obtains is the result of a fresh request that has cleared the Attestation function (Section 5.2.4) for the specific agent process making the request. This is the AIMS Provisioning property that distinguishes agent identity from traditional pre-provisioned machine identity. Malnick, et al. Expires 1 November 2026 [Page 22] Internet-Draft Local Delegated Agent Identity April 2026 5.2.4. Local Process Verification (Attestation) Local Process Verification is the realization of the AIMS Attestation function for the local-delegated profile. It is the OS-level peer- credential authentication protocol that the WIB performs on every Workload API connection before issuing any JWT-SVID. It addresses the residual binary-attestation gap on consumer hardware (Gap G-7) by anchoring the chain of trust in OS code-signing rather than hardware- rooted attestation. The protocol is specified in full in [OS-Workload-Attestation] Section 4, which defines: * The threat model (T-1 through T-8) covering same-user-account adversaries, code-signing-subsystem subversions, allowlist-channel poisoning, and remote-filesystem TOCTOU. * The six-step verification flow performed in order on every issuance request: (1) capture peer identity, (2) verify code signature against a pinned designated requirement, (3) verify runtime flags and entitlements, (4) verify post-launch instrumentation (RECOMMENDED), (5) verify launch context, and (6) verify peer ownership and freshness. * Platform-specific normative realizations for macOS (audit_token + pidversion + Code Signing API), Windows (named-pipe + CompareObjectHandles + WinVerifyTrust), Linux (abstract sockets + pidfd or ucred + IMA where available), and browser-sandbox agents (native messaging host with two-layer trust binding). * The allowlist schema, including the agent_class property that distinguishes developer_tool from ai_agent and the policy consequences of that distinction. * Verification-cadence rules for single-shot and long-lived-with- revalidation connection models, including the conditions under which Steps 2 to 5 may be elided on the steady-state path. The Attestation function’s outcome (which methods succeeded, which mechanisms were used) is reflected in the SVID’s attest_methods claim per Section 5.3.2 of this document, so the AS can apply graduated trust based on the achieved verification depth. This reflection is what makes the AIMS Attestation function useful to the downstream Authorization function: the AS does not need to trust the WIB’s self- rating of assurance; it sees the per-issuance evidence and applies policy accordingly. @@IMG:assets/images/local-delegated/image2.png@@ Figure 1: Figure 2 Malnick, et al. Expires 1 November 2026 [Page 23] Internet-Draft Local Delegated Agent Identity April 2026 Sequence 5.1: WIB-mediated agent identity issuance plus Token Exchange. The six-step verification of [OS-Workload-Attestation] §4 (AIMS Attestation) precedes JWT-SVID minting (AIMS Credentials, AIMS Provisioning); the SVID is then presented as actor_token in the AS Token Exchange (AIMS Authentication, agent leg). 5.3. Agent Workload Identifier: AIMS Identifier Section 5.3 realizes the AIMS Identifier function. The identifier scheme is SPIFFE [SPIFFE], chosen because it is URI-formatted, hierarchically structured, and already integrated with the WIMSE family of workload-identity specifications referenced throughout this document. 5.3.1. SPIFFE ID Format Each agent workload instance MUST be assigned a SPIFFE ID per [WIMSE-IDENTIFIER] and [SPIFFE]. The identifier takes URI form: spiffe:///agent/// Example (native local process): spiffe://acme.com/agent/example-vendor/example-agent/8f3a2b1c-9d4e-11ec-b909-0242ac120002 Example (browser-sandbox, origin-scoped): spiffe://acme.com/agent//browser-ext// The segment MUST identify the agent’s publisher and is bound to the code-signing identity verified by the WIB (Section 5.2.4). The segment identifies the product. The MUST be a UUIDv4 generated fresh at agent instantiation; it MUST NOT be reused across sessions. For browser-sandbox agents, the trust domain MUST reflect the registered origin of the web application, preventing cross-origin impersonation. The SPIFFE ID is the sub claim of the WIB-issued SVID and is propagated as the act.sub claim in the delegated access token issued by the AS at /token (Section 7.1). Malnick, et al. Expires 1 November 2026 [Page 24] Internet-Draft Local Delegated Agent Identity April 2026 5.3.2. WIB-Issued SVID Claims: AIMS Credentials Section 5.3.2 realizes the AIMS Credentials function for the agent- identity leg of the trust chain. The credential format is JWT-SVID per [WIMSE-CREDS]; the AS-issued delegated access token (Section 7.1) and the TTS-issued Txn-Token (Section 7.3) are the further AIMS credentials produced downstream of this one. The SVID minted by the WIB is a JWT signed with the WIB’s enrolled device key. Example claim body: { "iss": "wib:///device/", "sub": "spiffe:///agent///", "aud": "https://as.acme.com", "iat": 1745000000, "exp": 1745000600, "jti": "9f8e7d6c-...", "bound_subject": "user:7f3a2b1c@acme.com", "attest_methods": ["macos_codesign", "secure_enclave_devid", "user_gesture"], "binary_id": { "publisher": "", "product_id": "", "cdhash": "sha256:..." } } Claim semantics: * iss: identifies the issuing WIB by the identifier registered at enrollment (Section 5.2.2). * sub: the agent’s SPIFFE ID per Section 5.3.1. * aud: the AS endpoint URL. * jti: a unique identifier for this SVID, used by the AS for replay detection over the SVID’s lifetime and as one of the audit correlation handles consumed by AIMS Monitoring (Section 8). * bound_subject: the OS-level user identifier the agent is bound to. The AS MUST verify that bound_subject matches the sub of the Subject’s federated access token in the /token exchange. Malnick, et al. Expires 1 November 2026 [Page 25] Internet-Draft Local Delegated Agent Identity April 2026 * attest_methods: an array enumerating the verification methods that succeeded for this SVID issuance. This is the wire-level reflection of the AIMS Attestation outcome per Section 5.2.4. The AS MAY apply graduated trust based on this array (e.g., requiring secure_enclave_devid for production-resource scopes, or rejecting SVIDs that contain only user_gesture for high-sensitivity audiences). * binary_id: structured representation of the verified binary identity. Used for audit logging (AIMS Monitoring, Section 8) and policy evaluation at the AS. SVID lifetime MUST NOT exceed 10 minutes and MUST NOT exceed the lifetime of any access token derived from it. Short lifetime is not optional: it is the AIMS Credentials property that bounds the blast radius of credential theft to the residual TTL plus the time required for revocation propagation per Section 8.3. 5.4. Delegation Correlation Audit logs and revocation operations need to associate an observed agent action with the specific delegation event that authorized it. This document achieves correlation using only standard JWT claims, specifically the access token’s jti and the Txn-Token’s txn, rather than introducing a vendor-specific delegation identifier. The pair (AT.jti, txn) uniquely identifies a single agent action within a single delegated task across all PEPs that observe it. The AS MUST set a fresh jti on every delegated access token issued at /token (Section 7.1). The TTS MUST set a fresh txn on every Txn- Token issued at /txn-token (Section 7.3) and MUST include the originating AT’s jti as an additional correlation claim in the Txn- Token (the Txn-Token specification calls out this propagation pattern in [OAUTH-TXN-TOKENS] and [OAUTH-TXN-AGENTS]). PEPs that admit a request MUST log both identifiers per Section 8.1. Earlier drafts of this document defined a custom dlg_id claim to anchor delegations explicitly. That mechanism is deferred to separate work (Section 12) where it can be defined as a complete specification rather than a paragraph in a profile document. Until then, the standard jti / txn pairing is sufficient for the correlation needs of this profile. Malnick, et al. Expires 1 November 2026 [Page 26] Internet-Draft Local Delegated Agent Identity April 2026 6. Authentication (AuthN) This section realizes the AIMS Authentication function. AIMS Authentication has two legs in the local-delegated profile: (a) the human Subject’s authentication to the IdP at delegation time (Section 6.1), and (b) the agent workload’s authentication to the AS at task time (Section 6.2). Both legs feed evidence into the downstream Authorization function (Section 7); neither alone is sufficient. The agent leg additionally consumes the AIMS Attestation output (Section 5.2.4) as the actor_token presented in Token Exchange. 6.1. Human-to-IdP Authentication The Subject MUST authenticate to the IdP using a phishing-resistant method prior to any delegation. Per [NIST-63-4] (finalized July 2025), the MINIMUM assurance level for delegating authority is AAL2. Synced passkeys satisfy AAL2; device-bound passkeys with hardware attestation satisfy AAL3. The RECOMMENDED flow for local agent environments is: * Subject navigates to the agent’s authorization endpoint (or the agent triggers the OS browser to open the IdP authorization URL). * IdP presents a WebAuthn [WebAuthn-L3] challenge. The Subject authenticates using a device-bound passkey (TPM-backed on Windows / macOS via Windows Hello / Secure Enclave) or a FIDO2 hardware security key ([FIDO2-CTAP]). * WebAuthn assertion is verified by the IdP. On success, the IdP issues an authorization code. * The agent’s OAuth client (a public client, per [RFC6749] Section 2.1) exchanges the code for an ID token and access token, using PKCE [RFC7636] to prevent code interception. The Subject AT obtained at the conclusion of the OAuth Authorization Code flow is held by the OAuth client component that completed the flow. For the agent to present this AT as subject_token in the Token Exchange of §7.1, it MUST be delivered from the OAuth client component to the agent’s credential-handling layer (§7.5.1) over a channel that does not expose it to other same-user processes beyond what the OS already permits, and that does not expose it to the LLM context. The specific delivery mechanism depends on the agent’s deployment shape: native CLI agents typically use a loopback redirect URI [RFC8252], with the OAuth client’s redirect_uri pointing at a localhost port the agent is bound to; native desktop agents typically Malnick, et al. Expires 1 November 2026 [Page 27] Internet-Draft Local Delegated Agent Identity April 2026 use a custom URL scheme or platform-specific deep-link mechanism; browser-extension agents already operate in the same origin context as the OAuth client and complete the flow without a cross-process handoff; and IDE-integrated agents use the IDE’s secure-storage API or extension messaging surface. In all cases, the AT is consumed once by the agent (presented as subject_token to the AS at /token, after which the agent holds only the delegated AT, not the Subject AT) and SHOULD be discarded from the OAuth client component after handoff. The AT is short-lived per the IdP’s policy; this specification does not constrain its lifetime, only the delivery property. PKCE is REQUIRED for all local agent OAuth flows per [OAUTH-v2.1] and [RFC9700] Section 2.1.1. @@IMG:assets/images/local-delegated/image4.png@@ Figure 2: Figure 4 Sequence 6.1: Human authentication to IdP via FIDO2 + OAuth PKCE auth code flow. This realizes the human leg of AIMS Authentication. The Subject AT issued at the end of this flow becomes the subject_token for the agent Token Exchange in Section 7.1. 6.2. Agent-to-AS Authentication After the human Subject authenticates, the agent obtains its own short-lived credential through a Token Exchange [RFC8693], detailed in Section 7.1. This is the agent leg of AIMS Authentication. The agent’s actor_token in this exchange is a JWT-SVID issued by the Workload Identity Broker (Section 5.2.3), not a self-asserted JWT; the AS validates the SVID’s signature against its enrolled-WIB trust bundle (Section 5.2.2) before processing the exchange. The SVID itself is the proof of agent identity. It was minted only after the WIB performed the six-step verification of [OS-Workload-Attestation] Section 4 against the connecting agent process and signed the result with the WIB’s device-bound key from the platform secure key store. From the AS’s perspective, accepting a WIB-issued SVID is equivalent to accepting an attestation that the WIB has verified the agent’s binary identity, runtime integrity, launch context, and ownership. Malnick, et al. Expires 1 November 2026 [Page 28] Internet-Draft Local Delegated Agent Identity April 2026 Token Exchange itself is a public-client OAuth flow per [RFC6749] Section 2.1 and uses the subject_token + actor_token grant of [RFC8693]. The agent does not hold a long-lived asymmetric key for client authentication and is not required to demonstrate proof-of- possession on the Token Exchange request itself; the actor_token (the WIB-issued SVID) carries the agent identity, and the SVID’s short lifetime, audience binding, bound_subject claim, and per-issuance attestation evidence collectively bound the trust placed in it. Note on proof-of-possession on the issued AT. The delegated access token issued at /token is a bearer token in this revision. Per-call proof-of-possession is provided by the Txn-Token (Section 7.3), which is short-lived (≤ 60 seconds), carries an immutable identity and intent context, and is independently issued by the TTS for each upstream invocation. Proof-of-possession on the AT itself, by DPoP, mTLS, or another mechanism, is deferred to separate work; see Section 12. 6.3. Agent Credential Lifecycle Agent credentials MUST be ephemeral. The following REQUIRED constraints apply, all of which derive from the AIMS Credentials property that an agent identity is bounded in time and scope to a single delegated task: * WIB-issued SVIDs MUST have a maximum lifetime of 10 minutes. * Agent delegated access tokens MUST have a maximum lifetime of 15 minutes. * Txn-Tokens (Section 7.3) MUST have a maximum lifetime of 60 seconds per [OAUTH-TXN-TOKENS]. * Refresh tokens MUST NOT be issued to local agent clients for agent-scoped access tokens. If the access token expires mid-task, the agent MUST request a fresh delegation through the WIB’s Workload API (which will trigger fresh peer verification per [OS-Workload-Attestation] §4) and a fresh /token exchange. The absence of refresh tokens is itself an AIMS property: continuity of authority across time is a Subject decision, not an agent capability. * The agent process does not hold long-lived asymmetric key material in this profile. The WIB holds a device-bound key in the platform secure key store; the agent presents WIB-issued SVIDs (which the WIB has signed for it) and AS-issued bearer tokens, neither of which the agent itself signs. Malnick, et al. Expires 1 November 2026 [Page 29] Internet-Draft Local Delegated Agent Identity April 2026 7. Authorization (AuthZ) This section realizes the AIMS Authorization function. AIMS Authorization in this profile operates at two granularities: (a) per- task, at the AS’s /token endpoint (Section 7.1), where a delegated access token is minted with a scope-attenuated authorization derived from the Subject’s standing delegation policy and the Attestation outcome carried in the SVID; and (b) per-call, at the AS’s /txn-token endpoint (Section 7.3), where a Txn-Token is minted carrying immutable identity and intent context for a specific upstream invocation. Both granularities are required: the per-task layer bounds what the agent could do; the per-call layer bounds what the agent does do, and is the surface that the AIMS Monitoring function (Section 8) observes. The Policy Decision Point (Section 4.5) evaluates inputs at both granularities. 7.1. Delegation Grant Flow The core of the delegated authority model is the Token Exchange [RFC8693] that converts the Subject’s access token into an agent- scoped delegated access token carrying both the Subject’s identity (sub claim) and the agent’s identity (act claim). This is the AIMS Authorization function operating at per-task granularity. Token Exchange Request parameters: POST /token Content-Type: application/x-www-form-urlencoded grant_type=urn:ietf:params:oauth:grant-type:token-exchange &subject_token= &subject_token_type=urn:ietf:params:oauth:token-type:access_token &requested_token_type=urn:ietf:params:oauth:token-type:access_token &audience=https://api.example.com &scope=resource:dataset-id:read # MUST be subset of subject's scopes &actor_token= &actor_token_type=urn:ietf:params:oauth:token-type:jwt The AS MUST: * Validate the subject_token (signature, expiry, audience). * Validate the actor_token: verify that the WIB-issued JWT-SVID (Section 5.2.3) is signed by a key in the AS’s enrolled-WIB trust bundle (Section 5.2.2), and that the SVID’s bound_subject claim matches the subject_token’s sub. Inspect the SVID’s attest_methods claim (the AIMS Attestation reflection) and apply graduated-trust policy per Section 5.3.2 and Section 4.5. Malnick, et al. Expires 1 November 2026 [Page 30] Internet-Draft Local Delegated Agent Identity April 2026 * Verify that the requested scope is a strict subset of the subject_token’s scopes (mandatory scope attenuation). * Set sub to the Subject’s identifier and act to the agent’s WIMSE identifier. * Set a fresh jti on the issued token for replay detection and audit correlation (Section 5.4). * Set exp no more than 15 minutes from issuance. Example delegated access token claims (JWT body): { "iss": "https://as.acme.com", "sub": "user:7f3a2b1c@acme.com", "act": { "sub": "spiffe://acme.com/agent/example-vendor/example-agent/8f3a2b1c..." }, "aud": "https://api.example.com", "scope": "resource:dataset-id:read", "jti": "a4f8c1b2-0c4e-11ed-b939-0242ac120002", "exp": 1745000000, "iat": 1744999100 } | *SECURITY GAP* | | Gap G-2: Scope Attenuation in RFC 8693. RFC 8693 does not | mandate scope attenuation: it allows the resulting token to | have the same or broader scopes than the subject_token. In | typical delegation scenarios, the Subject may hold broad access | across many resources, but the agent MUST be issued a token | scoped only to the specific resource and operation it requires | (e.g., a single dataset with read-only access). | Implementations MUST explicitly enforce that the delegated | token’s scope is a strict subset of the subject token’s scope. | This is the AIMS Authorization principle of least privilege; | without scope attenuation enforcement, this profile does not | satisfy AIMS Authorization. The emerging draft-sweeney-oauth- | agent-delegation-00 (anticipated IETF 125) profiles RFC 8693 to | mandate this, along with chain verification and revocation | propagation. Until standardized, AS implementations MUST | enforce attenuation in local policy. Malnick, et al. Expires 1 November 2026 [Page 31] Internet-Draft Local Delegated Agent Identity April 2026 7.2. Resource Access Flow Once the agent holds a delegated access token, it presents this token to Resource Servers along with a per-call Txn-Token (Section 7.3). Each request MUST include: * An Authorization header bearing the delegated access token (Bearer scheme). * A Txn-Token header (see Section 7.3) carrying the per-call transaction context, including the intent_hash and tool_call descriptor. The Resource Server’s validation of these two artifacts is the PEP leg of the AIMS Authorization function. The RS MUST validate (a) the access token’s signature against the AS’s published JWKS, (b) the access token’s audience matches the RS, (c) the access token has not expired, (d) the Txn-Token’s signature against the TTS’s published JWKS, (e) the Txn-Token’s short lifetime has not been exceeded, and (f) the Txn-Token’s sub and actor.sub match the access token’s sub and act.sub. The RS MUST then enforce the requested action against the granted scope and emit a structured audit record per Section 8.1 on every authorization decision (admit or deny), with the access token’s jti, the Txn-Token’s txn, the act.sub, and the action as the primary correlation keys. Per-call sender-constraining of the access token (DPoP, mTLS, or other proof-of-possession) is not specified in this revision. The Txn-Token’s short 60-second lifetime, combined with the immutable identity context it carries and the requirement that a fresh Txn- Token be obtained from the TTS for each upstream invocation, bounds the per-call replay window. The TTS’s refusal to mint a Txn-Token under a revoked or expired access token (Section 8.3) provides the equivalent of CAEP-mediated revocation propagation for the per-call layer. See Section 10 for the residual risk analysis and Section 12 for the deferred AT-binding work. @@IMG:assets/images/local-delegated/image3.png@@ Figure 3: Figure 3 Sequence 7.2: Agent resource access. The agent obtains a fresh Txn- Token from the TTS for each upstream invocation, then presents the delegated AT and Txn-Token to the Resource Server. The PEP validates both, enforces scope, and emits AIMS Monitoring audit records keyed on at_jti and txn. Malnick, et al. Expires 1 November 2026 [Page 32] Internet-Draft Local Delegated Agent Identity April 2026 7.3. Transaction Token Propagation Section 7.3 realizes the per-call leg of the AIMS Authorization function. Txn-Tokens per [OAUTH-TXN-TOKENS] provide immutable identity and context propagation through the agent’s call chain. The [OAUTH-TXN-AGENTS] extension adds actor (agent) and principal (human) context fields specifically for AI agent workloads. Txn-Token Request from the local agent to the TTS: POST /txn-token Content-Type: application/x-www-form-urlencoded Authorization: Bearer grant_type=urn:ietf:params:oauth:grant-type:token-exchange &requested_token_type=urn:ietf:params:oauth:token-type:txn_token &subject_token= &subject_token_type=urn:ietf:params:oauth:token-type:access_token &audience= &request_details= &request_context= The TTS MUST extract from the delegated AT: * sub → becomes the Txn-Token’s sub (human subject) * act.sub → becomes the Txn-Token’s actor context (agent WIMSE ID) * jti → preserved in the Txn-Token as the at_jti claim for audit correlation (consumed by AIMS Monitoring, Section 8). The Txn- Token itself receives a fresh txn identifier per [OAUTH-TXN-TOKENS]. Example Txn-Token claims: Malnick, et al. Expires 1 November 2026 [Page 33] Internet-Draft Local Delegated Agent Identity April 2026 { "iss": "https://tts.acme.com", "iat": 1744999200, "exp": 1744999260, // 60-second lifetime "txn": "txn:9a1b3c2d-...", "sub": "user:7f3a2b1c@acme.com", "aud": "https://api.example.com", "req_wl": "https://gateway.api.example.com", "actor": { "sub": "spiffe://acme.com/agent/example-vendor/example-agent/8f3a2b1c...", "type": "ai_agent" }, "principal": { "sub": "user:7f3a2b1c@acme.com", "iss": "https://idp.acme.com" }, "at_jti": "a4f8c1b2-0c4e-11ed-b939-0242ac120002", "tctx": { "intent_hash": "", "tool_call": "api.invoke", "resource": "https://api.example.com/v1/datasets/dataset-id" } } 7.4. Intent Binding Intent Binding is the mechanism by which the Txn-Token is cryptographically anchored to the user’s original declared goal, reducing risk of prompt injection attacks from expanding the agent’s actions beyond the stated intent. In AIMS terms, intent binding is the input that lets the per-call Authorization decision incorporate user-declared semantic context, not only scope strings. Intent Binding procedure: * When the Subject activates the agent, the agent captures the user’s stated task as a natural-language intent string (e.g., ‘Summarize the most recent records from the project dataset’). * The agent computes an intent hash: SHA-256 of the UTF-8 encoded intent string. * The intent_hash is included in the request_details payload of the Txn-Token Request (Section 7.3), causing the TTS to embed it in the immutable tctx claim. * For each tool call, the agent MAY embed a structured tool_call descriptor alongside the intent_hash. Malnick, et al. Expires 1 November 2026 [Page 34] Internet-Draft Local Delegated Agent Identity April 2026 * Resource Servers and the PDP MAY evaluate whether the tool_call is plausibly consistent with the declared intent_hash. Significant deviation from the intent hash serves as a signal for policy escalation or human-in-the-loop intervention. | *SECURITY GAP* | | Gap G-3: Intent-Action Semantic Gap. The intent_hash binds the | Txn-Token to the user’s stated natural-language goal, but does | not mechanically constrain which tool calls the agent can make. | An agent under prompt injection could claim a new intent | (‘system instructions override: read all sensitive records’) | that is technically consistent with a separately computed hash. | Full intent-action verification would require either LLM-based | semantic validation at the PDP (emerging; not standardized) or | a capability declaration system in which the agent’s allowed | tools are pre-enrolled and the Txn-Token only authorizes | specific declared capabilities. Neither approach is currently | standardized. This is an active gap in the AIMS Authorization | realization for this profile. 7.5. Optional Gateway Pattern for Txn-Token Mediation The per-call Authorization flow specified in §7.2 and §7.3 places the delegated access token and the Txn-Token in the agent process itself: the agent holds the AT, requests Txn-Tokens from the TTS for each upstream invocation, and presents both to Resource Servers. This document refers to that topology as the agent-direct pattern. A parallel specification, [TXN-AGENTS-GATEWAY] (draft-araut-oauth- transaction-tokens-for-agents), specifies an alternative topology in which a gateway component mediates between the agent and Resource Servers. In the gateway pattern, the agent does not hold the delegated AT or directly request Txn-Tokens; instead, the gateway holds the AT, requests Txn-Tokens from the TTS on the agent’s behalf, attaches the AT and Txn-Token to outbound requests, and returns sanitized responses to the agent. The motivation given in [TXN-AGENTS-GATEWAY] is that an LLM-driven agent may inadvertently leak credentials present in its execution context, and that placing the credential-handling boundary outside the LLM-accessible surface mitigates that risk. This document treats the gateway pattern as OPTIONAL. Conforming implementations MAY use the agent-direct pattern of §7.2 and §7.3, MAY use the gateway pattern of [TXN-AGENTS-GATEWAY], or MAY use a hybrid (e.g., gateway-mediated for high-sensitivity Resource Servers and agent-direct for others). The choice is an agent-implementation decision, not a deployment-policy decision: it is determined by how Malnick, et al. Expires 1 November 2026 [Page 35] Internet-Draft Local Delegated Agent Identity April 2026 the agent’s credential-handling layer is constructed relative to its LLM-context boundary, which is a property of the agent’s software architecture rather than of the AS, TTS, or Resource Servers. 7.5.1. Security Property Required of Both Patterns Regardless of which pattern is chosen, conforming implementations MUST satisfy the following property: Credential isolation from LLM context. The delegated access token, Txn-Tokens, the Subject AT (during the brief interval it is held by the agent host before Token Exchange), and the WIB-issued JWT-SVID MUST NOT be placed in any input, output, system prompt, tool result, retrieved document, or other content visible to the LLM that drives the agent’s reasoning. Implementations MUST treat these credentials as belonging to the agent’s credential-handling layer, not to its reasoning layer. This property is what the gateway pattern enforces structurally (by removing the credentials from the agent process entirely) and what the agent-direct pattern requires the agent’s software architecture to enforce (by partitioning the agent process into a credential- handling layer that holds tokens and a reasoning layer that does not). Either approach is conformant; neither is conformant if the property is violated. The choice between patterns has trade-offs: * Agent-direct. Lower latency (no extra hop), simpler deployment topology, fewer components to operate. Requires the agent author to architect the agent process such that the credential-handling code path is structurally separate from the LLM-context construction code path. Appropriate when the agent author controls the full agent codebase and can guarantee the partition. * Gateway-mediated. Higher latency (extra hop on every Resource Server invocation), additional component to deploy and secure, but the credential-isolation property is enforced by process boundary rather than by software discipline. Appropriate when the agent is built on top of a third-party LLM framework whose context- construction behavior the agent author cannot fully audit, or when defense-in-depth against agent-internal credential leakage is required by deployment policy. 7.5.2. Wire Differences When the Gateway is Used When the gateway pattern is used, the wire-level interactions differ from §7.2 and §7.3 as follows: Malnick, et al. Expires 1 November 2026 [Page 36] Internet-Draft Local Delegated Agent Identity April 2026 * The agent → gateway call carries the agent’s intent and tool descriptor (the same intent_string and tool_call envelope that §7.4 specifies the agent constructs) but does not carry the delegated AT or any Txn-Token. The transport from agent to gateway is implementation-defined and MUST be local to the agent’s host (typically a localhost-bound HTTP listener, a Unix domain socket, or an in-process function call); cross-host gateway topologies are out of scope for this revision because they cross a trust boundary that this document does not analyze. * The gateway → TTS call is the /txn-token request specified in §7.3, with the gateway acting as the OAuth client. The gateway holds the delegated AT and presents it as subject_token. The intent_hash and tool_call values are computed by the agent and conveyed to the gateway over the agent → gateway interface above. * The gateway → Resource Server call is the resource invocation specified in §7.2, with the gateway attaching the delegated AT in the Authorization header and the Txn-Token in the Txn- Token header. The Resource Server’s PEP validation is unchanged from §7.2. * The gateway → agent response carries only the sanitized Resource Server response. The gateway MUST NOT echo the AT, the Txn-Token, or any error detail that contains credential material back to the agent. The Resource Server is unaware of which pattern is in use. From the PEP’s perspective, the wire format and audit emission are identical (§8.1). The act.sub in the AT and the actor.sub in the Txn-Token continue to identify the agent (not the gateway); the gateway is a credential-handling component, not a delegation participant. 7.5.3. Gateway Threat Considerations A gateway introduces a component that holds delegated access tokens for one or more agents. Implementations using the gateway pattern MUST: * Bind the gateway’s accepting interface to the agent’s process identity (on the same host) using the same OS-level peer-process verification that the WIB performs per [OS-Workload-Attestation] §4. A localhost-bound gateway that accepts requests from any same-user process is not conformant; an attacker process running as the same user could otherwise drive the gateway to issue Txn- Tokens against an arbitrary delegated AT the gateway holds. Malnick, et al. Expires 1 November 2026 [Page 37] Internet-Draft Local Delegated Agent Identity April 2026 * Apply the same credential-storage requirements to the gateway’s AT cache that §10.4.1 applies to in-agent token storage (short-lived, OS-protected where available, zeroized on process termination). * Emit audit records per §8.1 from the gateway, with the gateway’s identity recorded alongside the agent’s identity. The Subject- visible activity log of §8.5 MUST attribute actions to the agent, not to the gateway, because the gateway is not the delegation participant; the gateway’s involvement is a deployment-topology fact, not an authority fact. 7.5.4. Implementation Guidance (Informative) Agent authors choosing between the two patterns should consider where credential-handling code sits relative to the LLM context construction in their architecture. If the agent process is structured as a thin LLM-orchestration layer plus a separately- bounded credential-handling subprocess (e.g., the credential-handling code runs in a worker process or in a memory-isolated sandbox), the agent-direct pattern is straightforwardly conformant. If the agent process is built on a framework that constructs LLM context from broad reflection of the agent’s state, the gateway pattern provides a stronger structural guarantee. Hybrid topologies are explicitly permitted: a deployment may route invocations of a high-sensitivity Resource Server through a gateway while invoking lower-sensitivity Resource Servers agent-direct, choosing the trade-off per-resource. The Subject-visible activity log MUST present a unified view across both topologies (§8.5). 8. Monitoring, Audit, and Revocation This section realizes the AIMS Monitoring function. AIMS Monitoring is the seventh and final function of the [NIST-AIMS] / [AI-AUTH] model and the function that makes the other six accountable. Without a per-action, correlatable, tamper-evident audit surface and a real- time signal channel for policy events, the upstream Identifier, Credentials, Attestation, Provisioning, Authentication, and Authorization functions cannot be operated as a Zero Trust system: there is no observation of whether they are doing what they are supposed to do, and no mechanism to react when they are not. Earlier drafts of this document folded monitoring concerns into other sections (a brief mention in Section 5.4, the audit hint in Section 7.2, the revocation discussion in Section 8.3); this revision consolidates them into a single AIMS-aligned section. Correlation in this revision uses standard JWT claims (the access token’s jti and the Txn-Token’s txn) rather than a vendor-specific delegation identifier. Malnick, et al. Expires 1 November 2026 [Page 38] Internet-Draft Local Delegated Agent Identity April 2026 8.1. Audit Emission Requirements Every Policy Enforcement Point in the architecture (every Resource Server, the AS, and the TTS) MUST emit a structured audit record on every authorization-relevant event. The set of events is closed; conforming implementations MUST emit at minimum the following classes of record: Malnick, et al. Expires 1 November 2026 [Page 39] Internet-Draft Local Delegated Agent Identity April 2026 +==============+===============+================================+ | Event class | Emitted by | Required correlation fields | +==============+===============+================================+ | Delegation | AS at /token | AT jti, sub, act.sub, scope, | | issued | | attest_methods, audience, exp | +--------------+---------------+--------------------------------+ | Delegation | AS at /token | sub, attempted act.sub, | | refused | | refusal reason class | +--------------+---------------+--------------------------------+ | Txn-Token | TTS at /txn- | txn, at_jti, sub, act.sub, | | issued | token | intent_hash, tool_call, | | | | resource | +--------------+---------------+--------------------------------+ | Txn-Token | TTS at /txn- | at_jti (from presented AT), | | refused | token | attempted action, refusal | | | | reason class | +--------------+---------------+--------------------------------+ | Resource | Resource | txn, at_jti, sub, act.sub, | | access | Server PEP | resource, action | | admitted | | | +--------------+---------------+--------------------------------+ | Resource | Resource | txn, at_jti, sub, act.sub, | | access | Server PEP | resource, action, deny reason | | denied | | class | +--------------+---------------+--------------------------------+ | WIB SVID | WIB | SVID jti, sub (SPIFFE), | | issued | | bound_subject, attest_methods, | | | | binary_id.cdhash, exp | +--------------+---------------+--------------------------------+ | WIB SVID | WIB | attempted sub, refusal reason | | refused | | class (per Appendix A.3 of | | | | [OS-Workload-Attestation]) | +--------------+---------------+--------------------------------+ | User-gesture | WIB | sub (SPIFFE), gesture | | surfaced | | mechanism, accepted / declined | | | | / unavailable | +--------------+---------------+--------------------------------+ | Token | AS or | AT jti (or SVID jti for WIB- | | revoked | upstream | issued credentials), sub, | | | signal source | act.sub, revocation reason | | | | class, propagation channel | +--------------+---------------+--------------------------------+ Table 3 The refusal reason classes MUST be drawn from a closed namespace, identical at each emission site, so that operators querying audit data can compare across deployments. This document defines the Malnick, et al. Expires 1 November 2026 [Page 40] Internet-Draft Local Delegated Agent Identity April 2026 closed namespaces in Appendix B (forthcoming in -01); until then, deployments MAY define their own provided the namespace is consistent within the deployment and version-stamped on every record. Audit records MUST NOT include verification-step diagnostic detail beyond the closed-namespace reason class on emissions visible to the requesting peer. Detailed step-level failure information MAY be recorded in a separate, operator-only audit channel; this is the same separation defined in [OS-Workload-Attestation] Section 3.4 for WIB error responses, applied to the broader audit surface here. 8.2. Correlation: at_jti, txn, and the Identity Chain The AIMS Monitoring function depends on being able to reconstruct, from audit records alone, the full identity chain of any observed action: which Subject, acting through which Agent, under which delegated access token, in which Transaction, against which Resource. The wire-level mechanism that makes this possible is the propagation of two standard JWT identifiers through every layer of the architecture: * at_jti: the access token’s jti claim, set by the AS at /token (Section 7.1) and copied into the Txn-Token by the TTS at /txn- token (Section 7.3) for cross-layer correlation. The at_jti is the audit anchor for the per-task layer of AIMS Authorization. * txn: the per-transaction identifier minted at /txn-token (Section 7.3). The txn is the audit anchor for the per-call layer. The pair (at_jti, txn) uniquely identifies a single agent action within a single delegated task, across all PEPs that observe it. PEPs MUST log both. Audit-store schemas SHOULD index on at_jti to support the operational query “show me everything done under access token Y,” which is the canonical retrospective-investigation query for a delegated agent system. Both identifiers are standard JWT claims; no custom correlation field is required. 8.3. Revocation and Real-Time Signaling AIMS Monitoring is not only a backward-looking audit function; it is also the input channel for forward-looking policy reaction. When the Subject (or an automated risk system) determines that an active delegation has been compromised or should be terminated, the Monitoring surface is responsible for propagating that determination to every component that holds outstanding authority. Because this revision uses standard JWT claims rather than a custom delegation identifier, revocation is keyed on the access token’s jti (and, where Malnick, et al. Expires 1 November 2026 [Page 41] Internet-Draft Local Delegated Agent Identity April 2026 the entire (Subject, agent) relationship is being revoked, on the standing delegation policy at the AS itself). The architecture has three time bands: * Immediate (AS, TTS). On a revocation event for a given access token jti or a given (Subject, agent) standing delegation, the AS MUST mark the affected token as revoked in its token-introspection store, refuse all subsequent /token Token Exchanges that would re- issue against the same standing delegation policy until the policy is reauthorized, and refuse any /introspect lookup that returns active for the revoked jti. The TTS MUST refuse all subsequent /txn-token requests whose subject_token has the revoked jti or has been issued against a revoked standing delegation. Both responses MUST emit “refused” audit records per Section 8.1. * Near-real-time (Resource Servers). Resource Servers that have already accepted access tokens or Txn-Tokens under the affected jti are not reachable through the AS’s introspection store alone. The AS MUST emit a Continuous Access Evaluation Profile [CAEP] event addressed to all Resource Servers in the audience set of the revoked token, containing the revoked at_jti and an event_type of “session_revoked.” Resource Servers MUST consume CAEP events on a stream they configure with the AS at relying-party registration time and MUST honor revocation events within an implementation- defined latency budget. Deployments SHOULD set the budget at single-digit seconds. * Eventual (token expiry). Even without CAEP, the short-lifetime properties of Sections 5.3.2, 6.3, and 7.3 bound the worst-case exploitation window of a revoked-but-still-cached token: 10 minutes for the SVID, 15 minutes for the delegated AT, 60 seconds for the Txn-Token. CAEP narrows this to seconds; lifetime alone bounds it to minutes. CAEP is RECOMMENDED rather than REQUIRED because not all Resource Servers in the relevant ecosystem support CAEP receivers as of the publication of this draft. | *SECURITY GAP* | | Gap G-5: Revocation Propagation. If a user revokes a | delegation (e.g., via a ‘stop agent’ action in the UI), the | revocation signal must reach: (a) the AS (immediate, addressed | by this section), (b) the TTS (immediate, addressed by this | section), and (c) all Resource Servers that have accepted | tokens against the affected access token. (c) is not achievable | with bearer-token architectures alone: it requires either very | short token lifetimes (addressed) or a real-time token | revocation mechanism. CAEP [CAEP] (OpenID Continuous Access | Evaluation Profile) provides a framework for pushing revocation Malnick, et al. Expires 1 November 2026 [Page 42] Internet-Draft Local Delegated Agent Identity April 2026 | events to Resource Servers in real-time and is the recommended | approach above; until CAEP is universally deployed across the | agent’s likely Resource Servers, the residual gap is the time | between revocation and natural token expiry. This is the AIMS | Monitoring residual gap for this profile. 8.4. Session Invalidation Signals The user-gesture session model defined in [OS-Workload-Attestation] Section 3.3 is invalidated by a defined set of signals: explicit user dismissal, agent process termination, OS-level user-absence (screen- lock, session-switch, idle timeout), CAEP receipt, and elapse of the deployment-defined session ceiling. AIMS Monitoring is the function that observes these signals and emits the corresponding audit records (Section 8.1). On any session-invalidation signal, the WIB MUST emit a “session_invalidated” record, the AS MUST refuse subsequent /token requests whose actor_token references the invalidated session until a fresh user gesture has been collected, and the TTS MUST refuse subsequent /txn-token requests in the same manner. Session invalidation is the local-trust-domain analog of CAEP: the same event surface, scoped to the local components, propagated through the local audit channel rather than over a network. 8.5. Operator and Subject-Visible Surfaces AIMS Monitoring serves two distinct audiences: operators (administrators of the deployment, who consume the audit channel) and Subjects (the human users whose delegations are being observed). Both audiences MUST be served, but the surfaces are distinct: * Operator surface. Structured audit records per Section 8.1, in a format suitable for ingestion by SIEM / log-aggregation systems. The operator surface is authoritative; audit records MUST NOT be elided or summarized in the operator channel. * Subject surface. A Subject-visible activity log accessible from the WIB UI (or an analogous credential-management product surface) that displays, in human-comprehensible form, the delegations the Subject has issued, the agents currently operating under them, and the resources those agents have accessed. The Subject surface MAY summarize and SHOULD redact internal correlation fields that are not meaningful to the Subject. The Subject surface MUST surface revocation as an explicit, gesture-confirmed action; revocation issued from this surface MUST propagate per Section 8.3. Malnick, et al. Expires 1 November 2026 [Page 43] Internet-Draft Local Delegated Agent Identity April 2026 The Subject surface is what makes AIMS Monitoring meaningful to the user whose authority is being delegated. A Monitoring function visible only to operators delegates the Subject’s oversight to the deployment; this profile requires that the Subject can directly observe and revoke their own delegations. 9. Complete End-to-End Sequence The following sequence covers the complete lifecycle of a single local delegated agent task, from human authentication through resource access, with each phase annotated to the AIMS function it realizes. The phase enumeration immediately below is the normative reference. Sequence 9.1, which appears after the phases, is the illustrative diagram. Where the prose and the diagram disagree (which they should not), the prose governs. Phase 1: AIMS Authentication (human leg). Subject authenticates to the IdP via WebAuthn / FIDO2 per Section 6.1. PKCE-protected OAuth Authorization Code flow yields a Subject access token bound to the Subject’s identity. The Subject AT is then delivered from the OAuth client component to the agent’s credential-handling layer per §6.1, ready for use as subject_token in Phase 3. Phase 2: AIMS Attestation + AIMS Provisioning. Local Agent connects to the WIB Workload API per [OS-Workload-Attestation] Section 3 and submits a FetchJWTSVID request naming the requested SPIFFE ID and audience. The WIB performs the six-step verification of [OS-Workload-Attestation] Section 4 against the connecting peer, surfaces a user gesture if the SPIFFE ID is high-sensitivity per Section 3.3 of the same document, and on success mints a JWT-SVID per Section 5.3.2 of this document. Phase 3: AIMS Authentication (agent leg) + AIMS Authorization (per- task). Local Agent presents the WIB-issued SVID as actor_token to the AS’s /token endpoint, with the Subject’s access token as subject_token and a requested scope. The AS validates the SVID against its enrolled- WIB trust bundle, confirms bound_subject matches the subject_token’s sub, applies graduated trust based on attest_methods (Section 4.5 PDP evaluation), enforces scope attenuation, and mints a delegated access token with sub, act.sub, and a fresh jti per Section 7.1. Phase 4: Intent capture + per-call AIMS Authorization. Malnick, et al. Expires 1 November 2026 [Page 44] Internet-Draft Local Delegated Agent Identity April 2026 Subject states the task as a natural-language string. Local Agent computes intent_hash per Section 7.4 and POSTs the delegated AT plus intent_hash to the TTS’s /txn-token endpoint. The TTS validates the AT, runs PDP evaluation against runtime context (Section 4.5), and mints a Txn-Token per Section 7.3 carrying sub, actor.sub, at_jti, intent_hash, and tool_call. Phase 5: Tool execution + AIMS Monitoring. Local Agent invokes the Resource Server with the delegated AT in the Authorization header and the Txn-Token in the Txn-Token header. The Resource Server PEP validates both artifacts, enforces the requested action against the granted scope, and emits a structured audit record per Section 8.1 carrying at_jti, txn, sub, act.sub, resource, and action. The cycle of Phase 4 + Phase 5 repeats for each tool call within the agent’s task; a fresh Txn-Token is minted per call. Phase 5’s audit emissions are the input to the AIMS Monitoring function for the entire task. @@IMG:assets/images/local-delegated/image1.png@@ Figure 4: Figure 1 Sequence 9.1: Complete local delegated agent flow. Phase 1: human authentication. Phase 2: WIB attestation and JWT-SVID provisioning. Phase 3: per-task delegated AT issuance at the AS. Phase 4: per-call Txn-Token issuance with intent binding at the TTS. Phase 5: resource invocation, scope enforcement, and audit emission. Phases 4 and 5 repeat for each tool call within the agent’s task; a fresh Txn-Token is minted per call. 10. Security Considerations and Gaps This section enumerates the security properties of the local delegated agent architecture and identifies specific gaps that are not fully addressed by currently available standards. Each gap is tagged for cross-reference. Gaps are organized by the AIMS function whose realization they affect, so an implementer or reviewer can scope their analysis to a specific function. 10.1. Authentication Security Properties Malnick, et al. Expires 1 November 2026 [Page 45] Internet-Draft Local Delegated Agent Identity April 2026 10.1.1. Phishing Resistance WebAuthn [WebAuthn-L3] with origin binding ensures that the human Subject’s credential cannot be replayed to a fraudulent IdP. The FIDO2 authenticator signs the challenge bound to the relying party’s registered origin; a phishing site at a different origin cannot obtain a valid assertion. This property holds for both native local agents (which open the OS browser for authentication) and browser- sandbox agents (where the WebAuthn ceremony is origin-bound to the application). This is the AIMS Authentication property that makes delegation trustworthy at the human leg. 10.1.2. Agent-Identity Anchoring The agent’s authentication to the AS does not rely on a long-lived agent-held key. Instead, agent identity is anchored in the WIB- issued JWT-SVID, which the AS validates against its enrolled-WIB trust bundle. The SVID itself is the proof of agent identity. It could only have been minted by a WIB that holds a key in its platform secure key store (Apple Secure Enclave, Windows TPM, or equivalent) AND only after the WIB performed the per-issuance peer verification of [OS-Workload-Attestation] Section 4. The security property substituted for client-held proof-of-possession is per-issuance binary attestation by the WIB, anchored in OS code-signing. 10.2. Authorization Security Properties 10.2.1. Scope Attenuation The Token Exchange MUST enforce that the delegated access token’s scope is a strict subset of the Subject’s access token scope. In typical delegation scenarios, the Subject may hold broad privileges across many resources, but the agent is issued a token scoped exclusively to the specific operation and resource it requires. This ensures the agent cannot acquire more authority than the user explicitly delegated. See Gap G-2. 10.2.2. Temporal Bounding All agent credentials are short-lived (15-minute AT, 60-second Txn- Tokens, 10-minute SVID). This limits the window of exploitation in the event of credential theft. REQUIREMENT: Implementations MUST NOT issue refresh tokens for agent-scoped access tokens. Temporal bounding is an AIMS Credentials property, but its enforcement responsibility sits at the AIMS Authorization layer (which mints the tokens) and the AIMS Monitoring layer (which observes their use). Malnick, et al. Expires 1 November 2026 [Page 46] Internet-Draft Local Delegated Agent Identity April 2026 10.2.3. Per-Call Replay Window Without sender-constraining (DPoP, mTLS, or another proof-of- possession mechanism) on the delegated access token, a captured AT could in principle be replayed by an attacker for the remainder of the AT’s lifetime. This profile relies on three layered properties to bound that window: * The AT alone is not sufficient to invoke a Resource Server; a fresh Txn-Token from the TTS is also required (Section 7.2). An attacker holding a stolen AT must also obtain a Txn-Token under it, which requires presenting the AT to the TTS (which validates against the AS’s revocation state, Section 8.3). * The Txn-Token has a 60-second lifetime and carries an immutable identity context, so even a successful TTS request yields only a 60-second per-call window. * CAEP-mediated revocation propagation (Section 8.3) shrinks the worst-case AT exploitation window from the AT’s natural 15-minute lifetime to single-digit seconds in deployments where Resource Servers consume CAEP. The residual risk is the time between AT theft and either (a) revocation propagation reaching the TTS or (b) AT natural expiry, whichever is shorter. Future revisions of this document, or companion specifications, may add proof-of-possession on the AT layer; see Section 12. 10.2.4. Delegation Revocation See Section 8.3 for the revocation propagation mechanism and Gap G-5 for the residual gap. 10.3. Prompt Injection Mitigation Prompt injection is a first-order threat for local delegated agents. An attacker who can influence the content returned by a tool call (e.g., a malicious SQL result payload, query response, or injected schema comment) may embed instructions that cause the LLM to take actions outside the user’s declared intent. Current mitigations available in this architecture, organized by the AIMS function each leverages: Malnick, et al. Expires 1 November 2026 [Page 47] Internet-Draft Local Delegated Agent Identity April 2026 * Intent Binding (AIMS Authorization, Section 7.4) ties the Txn- Token to a specific hash of the user’s intent. Actions that meaningfully deviate from the intent hash can be flagged by PDP policy. * Txn-Token scope binding (AIMS Authorization): the tctx claim’s tool_call field SHOULD enumerate authorized tool types. The PDP SHOULD refuse to issue Txn-Tokens for tool calls not consistent with the declared tool_call envelope. * Short Txn-Token lifetimes (AIMS Credentials): a compromised Txn- Token has a maximum 60-second exploitation window. * Human-in-the-loop re-authorization (AIMS Authentication): for high-sensitivity actions (e.g., write operations to production systems), the agent SHOULD surface a confirmation prompt requiring the Subject to actively approve, triggering a new WebAuthn ceremony. * Real-time CAEP signaling (AIMS Monitoring, Section 8.3): when prompt-injection-attributable behavior is detected by an upstream observer, CAEP propagates the revocation to all Resource Servers within the latency budget of Section 8.3. | *SECURITY GAP* | | Gap G-6: No Standardized Prompt Injection Detection Protocol. | There is no IETF or W3C standard for a ‘prompt injection | detection’ signal that an agent runtime can include in a Txn- | Token request to attest that tool outputs have been scanned. | The draft NIST AIMS concept paper [NIST-AIMS] identifies this | as an open area. Until standardized, implementations MUST | apply defense-in-depth: (1) tool output content filtering, (2) | strict scope constraints, (3) minimal toolset enrollment per | delegation, and (4) anomaly detection at the PDP layer. See | also [AI-AUTH] Section 10 for the AI-Auth draft’s treatment of | prompt injection. 10.4. Local Trust Boundary Specific Risks 10.4.1. Memory Scraping and Token Exfiltration Other processes running as the same OS user can read the agent’s process memory, potentially extracting in-memory access tokens or Txn-Tokens. This is a threat to the AIMS Credentials function in the local trust domain. Mitigations: Malnick, et al. Expires 1 November 2026 [Page 48] Internet-Draft Local Delegated Agent Identity April 2026 * Bound the exposure window via the short token lifetimes of Section 10.2.2 (15-minute AT, 60-second Txn-Token, 10-minute SVID). * Apply OS-level process isolation and ASLR; enforce code signing on the agent binary so the WIB’s peer verification (Section 5.2.4) refuses to issue SVIDs to tampered or replaced agent processes. * Minimize the lifetime of tokens in agent memory: the agent SHOULD discard tokens immediately after the request that uses them rather than caching them across the AT’s natural lifetime. * The WIB’s own device-bound key is protected by the platform secure key store (Apple Secure Enclave, Windows TPM, or equivalent) and is not loaded into application-accessible memory; see [OS-Workload-Attestation] for the WIB’s self-protection requirements. | *SECURITY GAP* | | Gap G-7: Residual Binary Attestation Gap on Consumer Devices. | The Workload Identity Broker pattern (Section 5.2) | substantially narrows the binary-attestation gap by anchoring | agent identity in code-signing verification performed by a | hardened, AS-enrolled local daemon, rather than allowing any | process running as the user to self-assert an agent identity. | To impersonate a verified agent, an attacker must subvert one | of: (a) the OS code-signing subsystem, (b) the WIB’s allowlist | population channel (vendor manifest, MDM policy, or user opt- | in), or (c) the WIB itself; each of these is substantially | harder than the baseline of executing a process under the same | OS user account. However, on consumer (non-MDM) devices, the | WIB’s own enrollment cannot leverage hardware-rooted device | attestation (Tier 1, Section 5.2.2) and falls back to user- | anchored enrollment (Tier 2). The AS SHOULD apply graduated | trust based on the SVID’s attest_methods claim (Section 5.3.2). | For example, the AS may reduce scope ceilings or require more | frequent re-attestation for SVIDs whose attest_methods array | does not include hardware attestation. This is the AIMS | Attestation residual gap for this profile. RESOLUTION PATH: | TPM 2.0 Measured Boot + Remote Attestation ([RATS-ARCH] RFC | 9334) on managed devices closes this gap for the enterprise | tier; the consumer tier remains a residual gap. Malnick, et al. Expires 1 November 2026 [Page 49] Internet-Draft Local Delegated Agent Identity April 2026 10.4.2. Browser-Sandbox Specific Risks * Cross-origin information leakage: Agent WIMSE IDs embedded in HTTP headers must not be leaked to cross-origin iframes or third-party scripts. REQUIREMENT: Authorization and Txn-Token headers MUST NOT be included in cross-origin requests. * Service worker interception: A malicious service worker can intercept fetch requests and exfiltrate tokens. REQUIREMENT: The browser-sandbox agent MUST NOT operate in origins that permit untrusted service worker registration. * DOM-based prompt injection: Rendered web content (e.g., AI- summarized emails) can inject instructions into agent prompts if not sanitized. REQUIREMENT: All agent inputs derived from rendered DOM MUST be treated as untrusted and passed through a content sanitization layer before LLM context inclusion. 11. Comparison: Local vs. Remote Delegated Agent The following table summarizes the key differences between the local delegated architecture (this document) and the remote delegated architecture (doc 2 of 6). Both are AIMS reference architectures and use the same AIMS Authorization wire format (Token Exchange with act claim); they differ primarily in which mechanism realizes AIMS Attestation, where AIMS Credentials are stored, and the trust- boundary characteristics that shape the AIMS Monitoring function. +=====================+============================+================+ | AIMS function or | Local Delegated |Remote | | property | |Delegated | +=====================+============================+================+ | Execution | End-user device / browser |Cloud-managed | | environment | |container / VM | +---------------------+----------------------------+----------------+ | AIMS Attestation | OS code-signing via WIB |Workload | | realization | ([OS-Workload-Attestation] |Identity | | | §4); not hardware-rooted |Federation with | | | by default (Gap G-7) |cloud-platform | | | |identity | | | |issuer; SPIFFE | | | |/ SPIRE + TEE | | | |available | +---------------------+----------------------------+----------------+ | Agent credential | WIB device key in OS |HSM or cloud | | storage | secure key store / Secure |KMS; mTLS | | | Enclave / TPM; agent |client cert per | | | itself holds no long-lived |workload | Malnick, et al. Expires 1 November 2026 [Page 50] Internet-Draft Local Delegated Agent Identity April 2026 | | key in this revision | | +---------------------+----------------------------+----------------+ | AT proof-of- | None in this revision; |mTLS client | | possession | per-call binding via Txn- |certificate | | | Token |bound to AT | | | |(when | | | |[WIMSE-S2S] is | | | |used) | +---------------------+----------------------------+----------------+ | TTS location | Remote (cross-trust- |Within remote | | | domain) |trust domain | +---------------------+----------------------------+----------------+ | Human in loop | Present; FIDO2 consent |Absent; | | | feasible per task |delegation pre- | | | |authorized via | | | |ID-JAG | +---------------------+----------------------------+----------------+ | Txn-Token issuance | Cross-boundary (higher |Same-domain | | | latency) |(lower latency) | +---------------------+----------------------------+----------------+ | Prompt injection | Higher (local tool |Moderate | | risk | outputs) |(controlled | | | |tool outputs) | +---------------------+----------------------------+----------------+ | Refresh tokens | MUST NOT issue |SHOULD NOT; | | | |short-lived AT | | | |+ rotation | +---------------------+----------------------------+----------------+ Table 4 12. Out of Scope and Future Work This revision is deliberately scoped to capabilities that exist in shipping or actively-drafted specifications today. The following items were considered during development and excluded; they are listed here so that an implementer or reviewer can locate work that has been deferred rather than abandoned, and so that the boundary between this reference architecture and the work that follows it is explicit. * Vendor-specific delegation identifier (dlg_id). Earlier drafts of this document defined a custom dlg_id JWT claim to anchor each delegation event distinctly from the access token’s jti. Karl McGuinness’s review (see Acknowledgments) observed that this is a custom mechanism deserving its own specification rather than a paragraph in a profile document. This revision uses the standard JWT jti and the Txn-Token’s txn for correlation (Section 5.4 and Malnick, et al. Expires 1 November 2026 [Page 51] Internet-Draft Local Delegated Agent Identity April 2026 Section 8.2). A future companion specification may define richer delegation semantics and how to convey them across token types; that work is not part of this document. * Proof-of-possession on the delegated access token. Earlier drafts bound the delegated AT to an agent-held DPoP key per [RFC9449]. This revision does not, on the principle that the architecture should be grounded only in capabilities that exist in shipping specifications without requiring the agent to manage long-lived asymmetric key material in the local trust domain. The per-call binding properties that DPoP provided are now provided by the Txn- Token layer (Section 7.3, Section 10.2.3). Adding sender- constraining to the AT, via DPoP, mTLS, or another mechanism, is appropriate future work for deployments that need to defend against AT theft within the AT’s lifetime more aggressively than CAEP-mediated revocation provides. Such an addition would be additive to this profile and would not invalidate conformance. * Attenuating tokens for sub-agent delegation. Sub-agent flows (where one agent invokes another) are addressed in companion documents 3 through 6 of this series (the bounded and autonomous profiles). Recent IETF work on attenuating authorization tokens (draft-niyikiza-oauth-attenuating-agent-tokens-00) is relevant prior art and will be evaluated in those documents. * Capability-declaration system for intent binding. Section 7.4’s intent_hash binds the Txn-Token to a user-declared natural- language goal but does not mechanically constrain agent tool calls (Gap G-3). A capability declaration system in which the agent’s allowed tools are pre-enrolled and the Txn-Token only authorizes specific declared capabilities would close that gap. Such a system is not yet standardized; it is anticipated future work in the [AI-AUTH] track. * Externalized PDP wire protocol. Section 4.5 specifies the PDP’s position and inputs but does not define a wire protocol for an externalized PDP. Deployments that externalize the PDP today use deployment-specific transports. A standardized PDP-consultation protocol is potential future work. 13. References 13.1. Normative References [NIST-63-4] NIST, "NIST SP 800-63-4 Digital Identity Guidelines", July 2025, . Malnick, et al. Expires 1 November 2026 [Page 52] Internet-Draft Local Delegated Agent Identity April 2026 [NIST-207] NIST, "NIST SP 800-207 Zero Trust Architecture", August 2020, . [OIDC-Core] Sakimura, N., Bradley, J., Jones, M., Medeiros, B. D., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 2", November 2014, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, . [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . Malnick, et al. Expires 1 November 2026 [Page 53] Internet-Draft Local Delegated Agent Identity April 2026 [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . [RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, . 13.2. Informative References [AI-AUTH] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., and N. Steele, "AI Agent Authentication and Authorization", Work in Progress, Internet-Draft, draft- klrc-aiagent-auth-01, March 2026, . [CAEP] OpenID Foundation, "OpenID Continuous Access Evaluation Profile 1.0 - Final", 2023, . [FIDO2-CTAP] FIDO Alliance, "Client to Authenticator Protocol (CTAP) 2.1 Proposed Standard", June 2021, . [MCP] Anthropic, "Model Context Protocol Specification", 2024, . [NIST-AIMS] NIST NCCoE, "Accelerating the Adoption of Software and AI Agent Identity and Authorization - Concept Paper", February 2026, . [OAUTH-ATTEST] Looker, T., "OAuth 2.0 Attestation-Based Client Authentication", Work in Progress, Internet-Draft, draft- ietf-oauth-attestation-based-client-auth, 2026, . Malnick, et al. Expires 1 November 2026 [Page 54] Internet-Draft Local Delegated Agent Identity April 2026 [OAUTH-CHAIN] Schwenkschuster, A., "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet- Draft, draft-ietf-oauth-identity-chaining-08, February 2026, . [OAUTH-ID-JAG] Parecki, A., "Identity Assertion JWT Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth- identity-assertion-authz-grant-02, March 2026, . [OAUTH-TXN-AGENTS] RAUT, "Transaction Tokens For Agents", Work in Progress, Internet-Draft, draft-oauth-transaction-tokens-for-agents- 00, November 2025, . [OAUTH-TXN-TOKENS] Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-08, March 2026, . [OAUTH-v2.1] Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1 Authorization Framework", Work in Progress, Internet- Draft, draft-ietf-oauth-v2-1-15, March 2026, . [OS-Workload-Attestation] Meller, J. and J. Malnick, "OS-Level Workload Attestation", Work in Progress, Internet-Draft, draft- 1password-os-level-workload-attestation-00, April 2026, . [RATS-ARCH] Birkholz, H., "Remote Attestation Procedures (RATS) Architecture", RFC 9334, January 2023, . [RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, . Malnick, et al. Expires 1 November 2026 [Page 55] Internet-Draft Local Delegated Agent Identity April 2026 [SPIFFE] CNCF, "Secure Production Identity Framework for Everyone (SPIFFE)", 2023, . [TXN-AGENTS-GATEWAY] Araut, A., "Transaction Tokens For Agents (Gateway Profile)", Work in Progress, Internet-Draft, draft-araut- oauth-transaction-tokens-for-agents, n.d., . [WebAuthn-L3] W3C, "Web Authentication: An API for accessing Public Key Credentials - Level 3", 2025, . [WIMSE-ARCH] Salowey, J., "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft-ietf-wimse-arch-07, March 2026, . [WIMSE-CREDS] Campbell, B., "WIMSE Workload Credentials", Work in Progress, Internet-Draft, draft-ietf-wimse-workload-creds- 00, November 2025, . [WIMSE-HTTP-SIG] Salowey, J. and Y. Sheffer, "WIMSE Workload-to-Workload Authentication with HTTP Signatures", Work in Progress, Internet-Draft, draft-ietf-wimse-http-signature-03, April 2026, . [WIMSE-IDENTIFIER] Rosomakho, Y. and J. Salowey, "Workload Identifier", Work in Progress, Internet-Draft, draft-ietf-wimse-identifier- 01, December 2025, . [WIMSE-S2S] Campbell, B., "WIMSE Workload-to-Workload Authentication", Work in Progress, Internet-Draft, draft-ietf-wimse-s2s- protocol-07, October 2025, . Malnick, et al. Expires 1 November 2026 [Page 56] Internet-Draft Local Delegated Agent Identity April 2026 Acknowledgments The authors thank the following individuals for review, feedback, and prior art that materially shaped this document: Karl McGuinness for the architectural review that prompted the scope tightening reflected in this revision: specifically, the recommendation to separate the interoperable AIMS reference architecture from vendor-specific extensions, to ground the document in shipping or actively-drafted specifications, and to make the Policy Decision Point's role explicit (Section 4.5). Nick Steele (OpenAI; co-author of [AI-AUTH]) for substantive discussion of the AIMS model and its application to local-execution agent profiles. The authors of [AI-AUTH] / draft-klrc-aiagent-auth: Pieter Kasselman (Defakto Security), Jean-François Lombardo (AWS), Yaroslav Rosomakho (Zscaler), Brian Campbell (Ping Identity), and Nick Steele (OpenAI), whose elaboration of the AIMS conceptual model is the immediate parent of the function definitions used throughout this document. The mapping in Section 4.4 follows their seven-function decomposition; any errors of application are the responsibility of the authors of this document. The authors of [NIST-AIMS] at the NIST National Cybersecurity Center of Excellence, whose concept paper introduced the AIMS framing that this document realizes for the local-delegated profile. Acknowledgment does not imply endorsement; the named individuals reviewed material, contributed prior art, or co-authored upstream specifications that this document depends on. Responsibility for the contents of this document rests with the listed authors. About This Document 1Password Research & Development https://1password.com/security (https://1password.com/security) Document series: draft-1password-agent-identity-local-delegated-00, Part 1 of 6 Companion: draft-1password-os-level-workload-attestation-00 (AIMS Attestation + Provisioning realization) Next document: draft-1password-agent-identity-remote-delegated-00 (AIMS reference architecture for the remote-delegated profile) Malnick, et al. Expires 1 November 2026 [Page 57] Internet-Draft Local Delegated Agent Identity April 2026 Authors' Addresses J. Malnick 1Password J. Meller 1Password R. Menke 1Password Malnick, et al. Expires 1 November 2026 [Page 58]