Local Delegated Agent Identity Architecture

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.¶

• 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.¶

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.¶

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.¶

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 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 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.¶

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.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.¶

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.¶

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].¶

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.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.¶

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.¶

spiffe://<trust-domain>/agent/<vendor>/<agent-type>/<instance-id>

spiffe://acme.com/agent/example-vendor/example-agent/8f3a2b1c-9d4e-11ec-b909-0242ac120002

spiffe://acme.com/agent/<vendor>/browser-ext/<origin-hash>/<session-id>

{
  "iss":
  "wib://<vendor>/device/<device-uuid>",
  "sub":
  "spiffe://<trust-domain>/agent/<vendor>/<agent-type>/<instance-id>",
  "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":
    "<team-id-or-publisher>",
    "product_id":
    "<bundle-or-product-id>",
    "cdhash": "sha256:..."
  }
}

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.¶

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 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.¶

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.¶

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.¶

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-access-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=<wib-issued-jwt-svid>
&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.¶

• 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
}

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.¶

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.¶

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 <delegated-AT>
grant_type=urn:ietf:params:oauth:grant-type:token-exchange

&requested_token_type=urn:ietf:params:oauth:token-type:txn_token
&subject_token=<delegated-AT>
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&audience=<trust-domain-name>
&request_details=<base64url(intent-context-json)>
&request_context=<base64url(runtime-context-json)>

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:¶

  {
      "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": "<sha256-of-user-declared-intent>",
        "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.¶

• 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.¶

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 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.¶

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:¶

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 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 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.¶

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.¶

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.¶

10.1. Authentication Security Properties

10.2. Authorization Security Properties

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:¶

• 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.¶

10.4. Local Trust Boundary Specific Risks