Binding Per-Action Authorization and Memory Provenance into Agent Action Capsules

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 6 January 2027.¶

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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Three questions must be answered to hold an autonomous agent accountable for a consequential action:¶

• Why did the agent believe it should act? (the "why-believed")¶
• Was the action permitted? (the "may")¶
• What did the agent actually do, including the case where it was stopped? (the "did")¶

The Agent Action Capsule profile [I-D.mih-scitt-agent-action-capsule] answers the third with rigor. It binds effect state to verdict so that a "confirmed" effect MUST carry a digest over the observed response, and it emits a Capsule on every verdict -- including refusals, blocks, and timeouts -- rather than a survivorship-biased success-only log. By design, AAC does not answer the first two questions: its disposition.authority field is an opaque reference, and authorization is delegated to a separate profile (Section 10 of [I-D.mih-scitt-agent-action-capsule]).¶

This is the correct separation of concerns, and it leaves a precise seam. The per-action authorization profile [I-D.rampalli-aiagent-authz-hmac] answers "may": it binds an authorization token to the specific action so that the resolved action cannot diverge from the authorized one. The memory-provenance profile [I-D.rampalli-aiagent-memory-provenance] answers "why-believed": it tags every memory write with a source class, quarantines content from non-user-intent sources, and exposes the trust state of any belief the agent acted upon.¶

Either of those, standing alone, is incomplete, and so is AAC standing alone: a Capsule can faithfully record that an agent executed a payment without recording that the belief which triggered the payment came from a quarantined tool response, or that the action diverged from what was authorized. This document binds the three together. It does so additively, using only the extension points AAC already defines, so that an AAC Class 1 verifier that has never heard of this profile continues to verify the Capsule unchanged, and a verifier that implements this profile can additionally confirm the authorization and provenance behind the recorded act.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.¶

Capsule, verdict_class, disposition, assurance, effect, chain, ledger_mode, attestation_mode

As defined in [I-D.mih-scitt-agent-action-capsule].¶

Authorization proof

The artifact produced by [I-D.rampalli-aiagent-authz-hmac] that binds an authorization to a specific action.¶

Memory chain root

The chain_root value defined in Section 9 of [I-D.rampalli-aiagent-memory-provenance]: a base64url SHA-256 digest committing to a memory domain's state up to a sequence number.¶

Divergence class

A classification of how an action's actual capability flow diverged from its authorized flow (e.g., scope creep, injected delegation, unauthorized actor, expired delegation), as produced by the capability-flow detector that the per-action profile assumes.¶

3. The Three-Axis Evidentiary Model

The three profiles occupy three orthogonal axes of one record:¶

     why-believed              may                   did
  (memory provenance)   (per-action authz)   (agent action capsule)
+--------------------+ +------------------+ +--------------------+
| source_class       | | action-bound     | | verdict_class      |
| quarantine state   |-| authorization    |-| effect status +    |
| chain_root         | | proof            | | response_digest    |
| provenance read API| |                  | | assurance tiers    |
+--------------------+ +------------------+ +--------------------+
         L6                    L3                    AAC
          \                    |                    /
           \-------- one accountable record -------/

The axes are independent: a Capsule can record a clean execution (did) of a permitted action (may) whose triggering belief was quarantined (why-believed not satisfied). Surfacing that combination is the purpose of the binding. This document does not re-specify any axis; it specifies the references that join them.¶

Position relative to AAC's non-goals. Section 10 of [I-D.mih-scitt-agent-action-capsule] lists authorization as out of scope and points to a Permits profile. This document is compatible with that division: where a Permits statement is present it MAY be referenced by the same authority field; where a per-action authorization proof [I-D.rampalli-aiagent-authz-hmac] is the authority, this document says how to reference it. The two are not mutually exclusive.¶

4. Design Constraints Inherited from AAC

This profile is constrained by AAC's own rules and MUST NOT violate them:¶

C1. Closed header.

The capsule_* protected-header claim set is CLOSED; extensions are payload-only (Section 9 of [I-D.mih-scitt-agent-action-capsule]). Therefore the binding defined here lives ENTIRELY in the Capsule payload and in the OPTIONAL disposition.authority reference. This document defines NO new COSE header claims.¶

C2. Namespaced extension values.

New payload vocabulary MUST be namespaced by a URI or reverse-DNS prefix (Section 9.1 of [I-D.mih-scitt-agent-action-capsule]); bare names are reserved for the base profile. This document uses the prefix org.glyphzero.suradar.¶

C3. Unknown values are informational.

A base AAC verifier MUST treat unregistered values as informational and MUST NOT reject a Capsule for carrying one (Section 4 of [I-D.mih-scitt-agent-action-capsule]). The extension defined here is, to a base verifier, exactly such an informational value.¶

C4. Determinism.

AAC Class 1 verification MUST NOT consult a model, a clock-dependent heuristic, or network state (Section 6 of [I-D.mih-scitt-agent-action-capsule]). The checks added by this document that require fetching an external provenance record are therefore defined as a Class 2 extension (Section 9), never as Class 1.¶

C5. No may/did conflation.

Nothing in this binding may weaken AAC's confirmed-effect invariant or never-dispatch invariant. The binding adds context to a verdict; it never changes one.¶

5. The Provenance-Binding Extension

A Capsule MAY carry a single payload member named org.glyphzero.suradar.provenance (an object). Its presence is OPTIONAL; when present it MUST contain:¶

authz_ref (string, REQUIRED)

An opaque reference (URI or digest) to the per-action authorization proof [I-D.rampalli-aiagent-authz-hmac] for the Capsule's action_id. The reference MUST resolve to a proof bound to the SAME action; a verifier that resolves it checks that binding (PB-1).¶

memory_chain_root (string, OPTIONAL)

The base64url SHA-256 memory chain root (Section 9 of [I-D.rampalli-aiagent-memory-provenance]) that the authorization decision relied upon. Permits a verifier to fetch the provenance read API and confirm the source class and quarantine state of the triggering belief.¶

quarantine_attested (boolean, OPTIONAL)

Producer's claim that the high-privilege decision underlying this action was made only over memory entries that were NOT in the quarantine state, per the enforcement contract in Section 8 of [I-D.rampalli-aiagent-memory-provenance]. A verifier with access to the provenance read API rederives this (PB-3); a verifier without it treats the value as informational.¶

org.glyphzero.suradar.divergence_class (string, OPTIONAL)

See Section 7.¶

The member is part of the Capsule payload and is therefore covered by capsule_id (the JSON-DIGEST content address) and by the COSE_Sign1 signature, exactly like any other payload field. No separate signature is introduced.¶

The extension MUST NOT inline the internal structure of an authorization proof or a memory envelope. Consistent with AAC's treatment of "authority" as "reference only, never internal structure" (Section 5.4 of [I-D.mih-scitt-agent-action-capsule]), only references and digests appear here.¶

6. Populating disposition.authority

AAC defines disposition.authority as an OPTIONAL opaque reference. When a producer emits the extension of Section 5, it SHOULD also set disposition.authority to the same authz_ref value, so that a verifier that does not implement this profile still has a single, canonical pointer to the authority and a verifier that does implement it finds the two consistent. When the two are both present they MUST be equal; a verifier that implements this profile reports inequality as a finding (PB-2).¶

This document does not change the semantics of disposition.authority: it remains opaque to the base profile. It merely specifies one thing it MAY point to.¶

7. Divergence Class for Non-Executing Verdicts

AAC records that an action did not execute via verdict_class values such as "blocked", "denied", "errored", and "engine_failure" (Section 5.4.1 of [I-D.mih-scitt-agent-action-capsule]), but it does not record WHY a blocking constraint fired -- that is left to the private reason object behind reason_digest. When the reason is a capability-flow divergence detected by the per-action layer, a producer MAY surface the class in the clear via org.glyphzero.suradar.divergence_class, turning "it was stopped" into "it was stopped because of injected delegation."¶

The value, when present with an executing verdict_class, is a contradiction and a verifier reports it as a finding (PB-4). The following NON-NORMATIVE mapping aligns the SURADAR divergence taxonomy with AAC verdict classes; per C3 a base verifier treats it as informational:¶

This mapping is illustrative. Because verdict_class is registry-governed under Specification Required, no value here is added to AAC's registry; divergence_class is a namespaced extension value, not a verdict_class.¶

8. Anchoring and Hardware-Rooted Attestation Alignment

AAC's assurance block orders ledger evidence as standalone < chained < anchored (Section 5.3 of [I-D.mih-scitt-agent-action-capsule]). The memory-provenance profile uses the same ladder: its per-domain hash chain corresponds to "chained", and its external anchoring of chain roots to a transparency log (Section 7 of [I-D.rampalli-aiagent-memory-provenance]) corresponds to "anchored".¶

A producer MUST NOT report "ledger_mode": "anchored" on a Capsule on the basis of a referenced memory_chain_root UNLESS that chain root is itself committed to a transparency service whose receipt is verifiable, exactly as AAC requires for its own anchoring (a Capsule is "anchored" only with a verified SCITT Receipt, Section 3.2 of [I-D.mih-scitt-agent-action-capsule]). The two anchoring claims are independent: a Capsule MAY be anchored while the referenced memory chain is only chained, and vice versa. No-overclaim is preserved on both axes.¶

The transparency-service substrate used on both axes is the SCITT transparency service [I-D.ietf-scitt-architecture]; producers and verifiers SHOULD treat the substrate as shared rather than per-profile. Hardware-rooted attestation evidence, where present on either the Capsule or the memory chain, composes with the RATS architecture [RFC9334] and is referenced rather than re-specified here. This document defines no new attestation evidence format; it relies on the AAC attestation_mode field ([I-D.mih-scitt-agent-action-capsule], Section 5.3) and on the provenance read API ([I-D.rampalli-aiagent-memory-provenance], Section 10) to surface attestation tier on each axis independently.¶

9. Verification

The checks below EXTEND AAC verification. They are Class 2 (Section 8.2 of [I-D.mih-scitt-agent-action-capsule]) because confirming a reference requires evidence outside the Capsule bytes; they MUST NOT be required for Class 1. A Class 1 verifier ignores the extension (C3).¶

PB-1 (authorization binding).

If authz_ref resolves, the verifier confirms the authorization proof is bound to the Capsule's action_id per [I-D.rampalli-aiagent-authz-hmac]. Unresolvable or mismatched binding is reported; it does not, by itself, invalidate the Capsule's "did" claim.¶

PB-2 (authority consistency).

If both disposition.authority and authz_ref are present they MUST be equal.¶

PB-3 (quarantine rederivation).

If memory_chain_root is present and the provenance read API is reachable, the verifier rederives quarantine_attested by checking that no memory entry that influenced the decision was in the quarantine state (Section 8 of [I-D.rampalli-aiagent-memory-provenance]). A rederived value that contradicts the producer's claim is an overclaim finding, handled exactly as AAC handles assurance overclaims (Section 6, check 7).¶

PB-4 (divergence/verdict consistency).

A divergence_class present with an executing verdict_class ("executed") is a contradiction and is reported.¶

All four checks are deterministic given their inputs. PB-1 and PB-3 depend on external resolution and therefore inherit Class 2 status; PB-2 and PB-4 are computable from the Capsule alone and MAY be run by a Class 1 verifier as defensive assertions, consistent with AAC's allowance for defensive checks on hand-crafted input (Section 6).¶

10. Relationship to Existing Standards

This profile complements, and does not replace:¶

• [I-D.mih-scitt-agent-action-capsule] -- the post-execution Capsule. This document fills its deliberately-opaque authority reference and adds why-believed context, without modifying its header, registries, or Class 1 verification.¶
• [I-D.rampalli-aiagent-authz-hmac] -- the "may". Referenced by authz_ref.¶
• [I-D.rampalli-aiagent-memory-provenance] -- the "why-believed". Referenced by memory_chain_root; its provenance read API is the Class 2 evidence source for PB-3.¶
• Permits [I-D.munoz-scitt-permit-profile], referenced by AAC as its authorization companion. Where a Permit is the authority, the same disposition.authority field references it; this document does not compete with that profile.¶
• SCITT architecture [I-D.ietf-scitt-architecture] -- the anchoring substrate, by reference on both the Capsule and the memory-chain axes (Section 8).¶

11. Security Considerations

12. Privacy Considerations

References and digests carried here (authz_ref, memory_chain_root) are low-entropy in some deployments and subject to the digest-leakage / dictionary-attack consideration AAC raises (Section 13 of [I-D.mih-scitt-agent-action-capsule]); producers SHOULD salt or reference rather than inline. The memory chain root and the provenance read API can reveal which upstream sources an agent has read (Section 14 of [I-D.rampalli-aiagent-memory-provenance]); verifiers SHOULD treat resolved provenance as sensitive and SHOULD NOT persist it beyond the verification decision.¶

13. IANA Considerations

This document requests no IANA registrations. All vocabulary it introduces is namespaced under org.glyphzero.suradar. per the extension convention of Section 9.1 of [I-D.mih-scitt-agent-action-capsule] and is therefore registration-free. It adds no values to AAC's "Specification Required" registries.¶

Author's Address