Agent Authority Transition Receipts for Agentic Systems

Introduction Agentic software can discover services, invoke tools, delegate work, and act asynchronously on behalf of people and organizations. The Internet security stack already provides strong mechanisms for authentication, authorization, delegation, workload identity, and remote attestation. However, a recurring operational gap remains: after a policy engine consumes one or more pieces of evidence and decides whether an operation is authorized, there is no broadly interoperable receipt format that binds the decision to the exact policy, evidence, action, and authority state evaluated at that time. This document addresses that gap with the Agent Authority Transition Receipt (AATR). AATR is not a new identity system, not a replacement for OAuth access tokens, not an attestation format, and not a delegation protocol. It is a decision receipt. The design follows a non-collapse rule: evidence is not authorization, authorization is not execution, and successful execution is not proof that authorization was valid. Each promotion between those layers requires an explicit decision and a verifiable artifact.

Conventions and Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

Principal: The human or organizational authority on whose behalf an agent operation is proposed.
Agent: A software workload capable of proposing or performing operations, directly or through delegated tools.
Operation: A bounded action request identified by a stable request identifier and a digest over its security-relevant parameters.
Evidence: Machine-verifiable input used by a policy decision, such as an attestation result, delegation object, workload identity assertion, risk signal, or provenance statement.
Policy Decision Point (PDP): The component that evaluates an operation, policy, and required evidence to produce an authority decision.
Authority State: One of PROPOSED, EVALUATED, AUTHORIZED, DENIED, REVOKED, or EXPIRED.
AATR: A signed, non-bearer receipt that records one authority-state transition for one operation.
Required Evidence: Evidence that the applicable policy declares necessary before a transition to AUTHORIZED can occur.

Authority-State Model AATR models authorization as a state transition rather than as a property inferred from successful execution. The normal decision sequence is: EVALUATED -> AUTHORIZED \-> DENIED AUTHORIZED -> REVOKED AUTHORIZED -> EXPIRED ]]> An implementation MUST NOT issue an AUTHORIZED transition if any required evidence is missing, invalid, failed, or indeterminate. Indeterminate evidence is not permission. AATR does not define execution-state transitions. An authorized operation can still fail to execute, and an executed operation can still be shown later to have relied on invalid or stale authority. Execution receipts can be layered separately.

AATR Claims Set The AATR Claims Set is a JSON object. The security-relevant claims defined by this document are shown below. Additional claims MAY be present, but a verifier MUST NOT treat an unknown extension as satisfying a required evidence predicate. AATR Claims

Claim	Requirement	Description
ver	REQUIRED	AATR version. This document defines "1".
rid	REQUIRED	Receipt identifier derived from the canonical core claims.
iss	REQUIRED	Identifier of the issuing PDP or authority service.
aud	REQUIRED	Intended relying party or resource audience.
principal	REQUIRED	Identifier of the represented principal.
agent	REQUIRED	Identifier of the acting agent or workload.
request_id	REQUIRED	Stable identifier for the proposed operation.
action_digest	REQUIRED	Digest over the security-relevant operation parameters.
from	REQUIRED	Previous authority state.
to	REQUIRED	New authority state.
policy	REQUIRED	Policy identifier, version, and digest.
evidence	REQUIRED	Array of evidence references and evaluation states.
iat	REQUIRED	Issuance time.
exp	REQUIRED for AUTHORIZED	Authority expiration time.
nonce	RECOMMENDED	Freshness value bound to the operation.
prev	OPTIONAL	Predecessor AATR identifier for chained transitions.
reason	RECOMMENDED	Stable machine-readable decision reason code.

Evidence Entries Each evidence entry MUST identify the evidence type, digest, status, and the policy predicate it is intended to satisfy. The status vocabulary defined by this document is SATISFIED, FAILED, UNKNOWN, and MISSING. An AUTHORIZED AATR MUST contain only SATISFIED status for every evidence predicate marked required by the referenced policy. A relying party MUST reject an AUTHORIZED AATR if it cannot determine that all required predicates were satisfied. Raw evidence SHOULD NOT be embedded when a digest and an access- controlled reference are sufficient. This reduces correlation and disclosure risk.

Receipt Identifier and Canonicalization The receipt identifier is computed over a canonical JSON representation of the core claims using the JSON Canonicalization Scheme . The rid claim itself and signature container are excluded from this calculation. SHA-256 is used as specified by . Implementations that introduce other digest algorithms require an explicit algorithm identifier and downgrade protections.

Signing and Verification An AATR MUST be integrity protected by a signature mechanism that identifies the issuing authority. This document profiles JSON Web Signature (JWS) for the initial representation. The JWS payload is the UTF-8 encoding of the AATR Claims Set including rid. A verifier MUST validate the signature, issuer, audience, time bounds, receipt identifier, predecessor linkage when present, action digest, policy digest, and evidence predicates before accepting the receipt. The alg value "none" MUST NOT be accepted. Algorithm agility follows the JOSE registries. Deployments SHOULD use algorithms that meet their current security policy and key-management requirements.

Normative Verification Algorithm

Parse the JWS and reject malformed input.
Verify the signature using a key trusted for the declared issuer.
Verify that aud identifies the current relying party.
Recompute rid from the RFC 8785 canonical core and compare it in constant time where practical.
Verify iat, exp, and local freshness policy.
Verify that request_id and action_digest match the operation under consideration.
Resolve the referenced policy and verify its identifier, version, and digest.
Determine the set of required evidence predicates from that policy.
Verify each evidence reference according to its evidence type.
If any required predicate is FAILED, UNKNOWN, MISSING, unverifiable, or stale, reject an AUTHORIZED transition.
Verify that the from to to transition is permitted by local transition policy and predecessor state.
Apply revocation checks required by the issuer, policy, or local deployment.

Composition with Existing Protocols AATR is designed as a narrow composition layer.

OAuth 2.0 Token Exchange can represent delegated security tokens. Rich Authorization Requests can carry fine-grained authorization details. AATR records the subsequent authority-state decision and the evidence/policy inputs used to make it.
Demonstrating Proof of Possession at the Application Layer (DPoP) binds OAuth tokens to a key. AATR does not replace proof of possession.
RATS defines roles and artifacts for remote attestation. An Attestation Result can be referenced as one AATR evidence input.
WIMSE work defines workload identity mechanisms for multi-system environments. AATR can identify the agent using a WIMSE-compatible workload identifier without defining a new workload identity scheme.
Agent delegation and operation-authorization proposals can supply delegation or operation evidence. AATR's distinct purpose is to record the policy transition from evaluated evidence to an authority state.

Non-Bearer Semantics An AATR is evidence of an authority decision, not a bearer credential. Possession of a valid AATR alone MUST NOT cause a resource server to grant access unless a separate protocol explicitly profiles AATR as part of its authorization exchange. This distinction prevents receipt laundering, where an audit artifact is replayed as though it were an access token.

Revocation and Staleness An issuer can revoke authority by issuing a later AATR that transitions the same operation or authority lineage to REVOKED. Relying parties that accept chained AATRs MUST define how they discover later receipts or revocation status. Evidence that was fresh when an earlier decision was issued can later become stale. Therefore a relying party MUST NOT assume that an old AUTHORIZED AATR remains usable beyond its expiration or local freshness policy.

Privacy Considerations AATR can correlate principals, agents, actions, policies, and evidence. Implementations SHOULD minimize receipt contents, avoid embedding natural-language prompts or raw private evidence, use audience restriction, and apply retention controls. Digests can still leak information when the underlying value comes from a low-entropy space. Implementations MUST NOT assume that a digest automatically anonymizes the referenced data. Cross-domain deployments should consider pairwise or scoped identifiers when a globally stable identifier is unnecessary.

Security Considerations AATR is security-sensitive because relying parties can use it to decide whether a prior authorization decision is trustworthy. Implementations must address at least the following threats.

Replay: Bind receipts to audience, operation digest, freshness values, and short validity windows.
Confused deputy: Verify both represented principal and acting agent; do not infer one identity from the other.
Policy substitution: Verify the exact policy digest and version, not only a human-readable policy name.
Evidence substitution: Verify type, digest, freshness, and required predicate for each evidence entry.
Receipt laundering: Do not treat AATR as a bearer token.
Key compromise: Support issuer key rotation, revocation, and bounded receipt lifetimes.
Indeterminate evidence: Unknown, missing, stale, or unverifiable required evidence must not be promoted into authorization.
Log compromise: Optional transparency logging can improve detection, but log inclusion alone does not establish policy correctness.

Deployment and Incremental Adoption AATR can be introduced without replacing an existing authorization stack. A deployment can begin by issuing receipts in audit-only mode, compare them against existing policy decisions, and later require verified receipts at selected high-consequence enforcement points. This incremental profile is particularly useful for agentic workflows spanning multiple trust domains, where identity, delegation, attestation, and authorization are already produced by different systems.

Relationship to Current Agent Authorization Work Multiple active Internet-Drafts address agent identity, delegation, authorization, and Internet architecture. The Delegation Receipt Protocol records user-to-operator delegation. Agent Operation Authorization defines an operation-specific authorization framework. WIMSE work addresses workload identity. Other proposals define agent identity and delegation tokens. AATR is deliberately narrower: it standardizes the verifiable record of a policy-mediated authority state transition and the evidence that the policy consumed. This separation is intended to make the mechanism composable rather than competitive. If existing authorization protocols later define equivalent receipt semantics, AATR can be profiled as a common claims model or folded into that work.

Open Issues for Discussion

Whether the initial representation should remain JWS-only or also define a COSE/CBOR profile.
Whether a standard transition-state registry is useful or local policy should define additional states.
How revocation discovery should compose with short-lived credentials and transparency services.
Whether receipt chaining should remain optional or become mandatory for multi-hop agent workflows.
Which IETF venue should own the work if the community finds the problem worth standardizing.

Conclusion Agentic systems increasingly combine identity, delegation, attestation, policy, and automated execution. AATR adds a narrow missing object: a verifiable receipt that says which authority state changed, for which operation, under which policy, using which evidence. By keeping evidence, authorization, and execution distinct, deployments can make high-consequence agent actions easier to audit, revoke, compare across domains, and reason about without requiring a new identity system or a new authorization token format.