| Internet-Draft | AAC Provenance Binding | July 2026 |
| Rampalli | Expires 6 January 2027 | [Page] |
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.¶
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 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.¶
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 (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.¶
Three questions must be answered to hold an autonomous agent accountable for a consequential action:¶
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.¶
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.¶
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.¶
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.¶
This profile is constrained by AAC's own rules and MUST NOT violate them:¶
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.¶
org.glyphzero.suradar.¶
A Capsule MAY carry a single payload member named
org.glyphzero.suradar.provenance (an object). Its
presence is OPTIONAL; when present it
MUST contain:¶
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.¶
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:¶
| divergence class | typical AAC verdict_class |
|---|---|
| ScopeCreep | blocked |
| InjectedDelegation | blocked |
| UnauthorizedActor | denied |
| ExpiredDelegation | denied / expired |
| (clean flow) | executed |
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.¶
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.¶
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).¶
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.¶
disposition.authority and authz_ref are
present they MUST be equal.¶
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).¶
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).¶
This profile complements, and does not replace:¶
authz_ref.¶
memory_chain_root; its
provenance read API is the Class 2 evidence source for PB-3.¶
disposition.authority field
references it; this document does not compete with that profile.¶
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.¶
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.¶
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.¶
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.¶
As stated in the front matter, this document establishes prior art on the binding it describes.¶
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.¶
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.¶