Network Working Group K. Rampalli Internet-Draft Glyphzero, Inc. Intended status: Informational 5 July 2026 Expires: 6 January 2027 Binding Per-Action Authorization and Memory Provenance into Agent Action Capsules draft-rampalli-scitt-capsule-provenance-binding-00 Abstract The Agent Action Capsule (AAC) profile (draft-mih-scitt-agent-action- capsule) records what an autonomous agent actually did -- executed, blocked, denied, errored, or timed out -- with a structural binding that prevents an attempt from being presented as a completion. AAC deliberately does not define the authority that permitted an action; it carries that authority as an opaque reference. Two companion profiles supply what that reference can point to: a per-action authorization profile (draft-rampalli-aiagent-authz-hmac) records that an action was permitted (the "may"), and a memory-provenance profile (draft-rampalli-aiagent-memory-provenance) records the source and trust state of the belief on which the agent acted (the "why- believed"). This document specifies how the latter two are bound into an AAC Capsule. It defines (a) what the AAC "disposition.authority" reference MAY resolve to, (b) a namespaced, payload-only extension carrying an authorization-token reference, a memory chain root, and a quarantine attestation, and (c) an OPTIONAL divergence-class value, drawn from the per-action profile, that explains a non-executing AAC verdict. The binding uses only mechanisms AAC already provides -- the opaque authority reference and the payload-extension namespacing convention -- and changes neither AAC's closed protected-header claim set nor its Class 1 verification. The result is a single verifiable record that answers "may," "did," and "why-believed" together. Defensive Publication Notice This memorandum is published in part to establish prior art on the binding it describes. The author and Glyphzero, Inc. assert no patent claim over the technique of binding per-action authorization and memory provenance into an agent-action capsule considered in isolation. Implementers and standards bodies are encouraged to incorporate it without seeking license. Patent protection that Glyphzero, Inc. or its affiliates may hold or pursue is limited to enterprise-distinguishing extensions not specified here, such as cross-domain federation of provenance chains. Hardware-rooted Rampalli Expires 6 January 2027 [Page 1] Internet-Draft AAC Provenance Binding July 2026 attestation and multi-tenant anchoring are treated as composition seams with open standards (the RATS architecture [RFC9334] and the SCITT transparency service [I-D.ietf-scitt-architecture]) rather than as patent reservations of this profile. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. The Three-Axis Evidentiary Model . . . . . . . . . . . . . . 4 4. Design Constraints Inherited from AAC . . . . . . . . . . . . 5 5. The Provenance-Binding Extension . . . . . . . . . . . . . . 6 6. Populating disposition.authority . . . . . . . . . . . . . . 7 7. Divergence Class for Non-Executing Verdicts . . . . . . . . . 7 8. Anchoring and Hardware-Rooted Attestation Alignment . . . . . 8 9. Verification . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Relationship to Existing Standards . . . . . . . . . . . . . 9 Rampalli Expires 6 January 2027 [Page 2] Internet-Draft AAC Provenance Binding July 2026 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11.1. A Reference Is Not a Proof . . . . . . . . . . . . . . . 10 11.2. Tamper-Evidence Is Not Honesty . . . . . . . . . . . . . 10 11.3. No Weakening of AAC Invariants . . . . . . . . . . . . . 10 11.4. Divergence Disclosure . . . . . . . . . . . . . . . . . 10 11.5. Defensive Publication . . . . . . . . . . . . . . . . . 11 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 14.1. Normative References . . . . . . . . . . . . . . . . . . 11 14.2. Informative References . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 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 Rampalli Expires 6 January 2027 [Page 3] Internet-Draft AAC Provenance Binding July 2026 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: Rampalli Expires 6 January 2027 [Page 4] Internet-Draft AAC Provenance Binding July 2026 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 Rampalli Expires 6 January 2027 [Page 5] Internet-Draft AAC Provenance Binding July 2026 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. Rampalli Expires 6 January 2027 [Page 6] Internet-Draft AAC Provenance Binding July 2026 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: Rampalli Expires 6 January 2027 [Page 7] Internet-Draft AAC Provenance Binding July 2026 +====================+===========================+ | divergence class | typical AAC verdict_class | +====================+===========================+ | ScopeCreep | blocked | +--------------------+---------------------------+ | InjectedDelegation | blocked | +--------------------+---------------------------+ | UnauthorizedActor | denied | +--------------------+---------------------------+ | ExpiredDelegation | denied / expired | +--------------------+---------------------------+ | (clean flow) | executed | +--------------------+---------------------------+ Table 1: Illustrative Divergence-Class Mapping 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 Rampalli Expires 6 January 2027 [Page 8] Internet-Draft AAC Provenance Binding July 2026 ([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. Rampalli Expires 6 January 2027 [Page 9] Internet-Draft AAC Provenance Binding July 2026 * [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 11.1. A Reference Is Not a Proof Carrying authz_ref or memory_chain_root attests only that the producer claims an authority and a provenance; it does not establish their validity. Validity is established only by resolving and verifying them (PB-1, PB-3). A verifier MUST NOT upgrade its trust in a Capsule's "did" claim merely because the extension is present. 11.2. Tamper-Evidence Is Not Honesty As in AAC (Section 13 of [I-D.mih-scitt-agent-action-capsule]), this binding attests record bytes and referenced digests, not the honesty of the runtime at the moment of recording. quarantine_attested is a producer claim; only PB-3 against the live chain converts it to evidence. 11.3. No Weakening of AAC Invariants This document adds no path by which an attempt can be presented as a completion; it cannot, because it never writes effect or verdict fields. Confirmed-effect and never-dispatch invariants are unchanged. 11.4. Divergence Disclosure Surfacing divergence_class in the clear reveals why an action was blocked, which is operationally useful but may aid an adversary probing a policy boundary. Producers MAY withhold it and rely on reason_digest instead. Rampalli Expires 6 January 2027 [Page 10] Internet-Draft AAC Provenance Binding July 2026 11.5. Defensive Publication As stated in the front matter, this document establishes prior art on the binding it describes. 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. 14. References 14.1. Normative References [I-D.mih-scitt-agent-action-capsule] Mih, S., "Agent Action Capsule: A SCITT Profile for Post- Execution Accountability of Autonomous Agents", Work in Progress, Internet-Draft, draft-mih-scitt-agent-action- capsule-01, 2026, . [I-D.rampalli-aiagent-authz-hmac] Rampalli, K., "A Symmetric-Key Profile for Per-Action Authorization of Autonomous AI Agents", Work in Progress, Internet-Draft, draft-rampalli-aiagent-authz-hmac-00, 2026, . Rampalli Expires 6 January 2027 [Page 11] Internet-Draft AAC Provenance Binding July 2026 [I-D.rampalli-aiagent-memory-provenance] Rampalli, K., "A Memory-Provenance Profile for Autonomous AI Agents", Work in Progress, Internet-Draft, draft- rampalli-aiagent-memory-provenance-00, 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 14.2. Informative References [I-D.ietf-scitt-architecture] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture, 2026, . [I-D.munoz-scitt-permit-profile] Munoz, A., "A SCITT Permit Profile", Work in Progress, Internet-Draft, draft-munoz-scitt-permit-profile, 2026, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . Author's Address Karthik Rampalli Glyphzero, Inc. Delaware United States of America Email: karthik@glyphzerolabs.com Rampalli Expires 6 January 2027 [Page 12]