Independent Submission P. Etcheverry Internet-Draft Rama Intended status: Informational 25 June 2026 Expires: 27 December 2026 Action Reference: A Deterministic Identifier for Agent Actions draft-etcheverry-action-ref-01 Abstract This document defines "action_ref", a deterministic, content- addressed identifier for autonomous agent actions. Any party holding the four preimage fields (agent_id, action_type, scope, timestamp) can independently compute and verify the identifier without trusting the emitting system. The document specifies the derivation algorithm, canonical serialization using RFC 8785 JSON Canonicalization Scheme (JCS), timestamp format requirements, canonical receipt envelope, optional fields for revocation and policy rotation auditability, scope conventions, and a composability model with existing exactly-once execution guarantees. Editorial Note Discussion of this draft takes place on the argentum-core repository: . A conformance test suite with byte-verified vectors is maintained at . 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 27 December 2026. Etcheverry Expires 27 December 2026 [Page 1] Internet-Draft Action Reference June 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Action Reference Derivation . . . . . . . . . . . . . . . . . 4 3.1. Preimage Fields . . . . . . . . . . . . . . . . . . . . . 4 3.2. Serialization . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Hash Function . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Timestamp Format . . . . . . . . . . . . . . . . . . . . 6 3.5. Derivation Example . . . . . . . . . . . . . . . . . . . 6 4. Canonical Receipt Envelope . . . . . . . . . . . . . . . . . 7 4.1. Required Fields . . . . . . . . . . . . . . . . . . . . . 7 4.2. Optional Fields for Rotation Auditability . . . . . . . . 8 5. Three-Record Trail and authorization_ref . . . . . . . . . . 9 5.1. Layer Model . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. authorization_ref Derivation . . . . . . . . . . . . . . 10 5.3. Canonical Linking Key . . . . . . . . . . . . . . . . . . 10 6. Scope Conventions . . . . . . . . . . . . . . . . . . . . . . 11 7. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8.1. Replay Attack Surface . . . . . . . . . . . . . . . . . . 12 8.2. Scope Injection . . . . . . . . . . . . . . . . . . . . . 13 8.3. Timestamp Manipulation . . . . . . . . . . . . . . . . . 13 8.4. Operator-Independence Guarantee . . . . . . . . . . . . . 13 9. Interoperability Considerations . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 15 A.1. Positive Conformance Vector . . . . . . . . . . . . . . . 15 A.2. Negative Conformance Vector — Epoch-Integer Timestamp . . 15 A.3. authorization_ref Vector . . . . . . . . . . . . . . . . . 15 Appendix A.4. External Conformance Set — evidence-anchor-static-analysis-v0 . . . . . . . . . . . 16 Appendix B. Field Mapping for Existing Systems . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Etcheverry Expires 27 December 2026 [Page 2] Internet-Draft Action Reference June 2026 1. Introduction Autonomous agents operating across distributed systems need a way to identify individual actions that is independent of any single system's infrastructure. Existing audit trail mechanisms rely on operator-managed identifiers — UUIDs, database primary keys, or system-specific event IDs — that cannot be verified by a third party without trusting the issuing system. This document defines "action_ref": a deterministic identifier derived from four preimage fields that any party can independently compute. The identifier is content-addressed — it is derived from the action content itself, not from a sequencer or registry. A verifier holding the four fields can recompute it without any call to the operator's infrastructure. The design goal is operator-independence: a receipt carrying action_ref can be verified by an auditor, a smart contract, or a competing system without trusting the emitter. This property is structural, not procedural — it follows from the derivation algorithm, not from operator policy. An automated static analysis of 35,689 agent-ecosystem endpoints [AgentGraph-EvidenceAnchor] found that 636 of 7,029 MCP servers (~9%) carry a high or critical finding — hardcoded secrets, unsafe exec/ eval, missing authentication, or known-vulnerable dependencies — detectable by static analysis alone. This motivates an independently-verifiable evidence anchor for scan results, so a relying party can confirm a verdict without trusting the scanner operator. | This figure covers static analysis only; it does not cover | runtime or behavioral risk. Methodology: AgentGraph | EvidenceAnchor static analysis conformance set, June 2026 | [AgentGraph-EvidenceAnchor]. This document covers: * The derivation algorithm (SHA-256 over JCS-canonical JSON). * Preimage field semantics and invariants. * Timestamp format requirements for cross-implementation byte consistency. * The canonical receipt envelope. * Optional fields for policy rotation and revocation auditability. Etcheverry Expires 27 December 2026 [Page 3] Internet-Draft Action Reference June 2026 * The authorization_ref derivation for three-record trail correlation. * Scope conventions for cross-emitter disambiguation. * Security considerations including replay attack surface. 2. Terminology 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. action_ref: A deterministic, content-addressed identifier for an agent action. Computed as SHA-256(JCS({agent_id, action_type, scope, timestamp})). preimage: The four-field JSON object over which the SHA-256 hash is computed: {agent_id, action_type, scope, timestamp}. emitter: The system or agent that produces a receipt containing action_ref. verifier: Any party that independently recomputes action_ref from the preimage fields and checks it against a presented receipt. operator: The system controlling the emitter. A verifier MUST be able to verify action_ref without trusting the operator. JCS: JSON Canonicalization Scheme, defined in [RFC8785]. Produces a unique byte sequence for any JSON value. trail: A sequence of records (pre-execution, decision, receipt) correlated by action_ref across systems. 3. Action Reference Derivation 3.1. Preimage Fields The preimage is a JSON object containing exactly four fields: Etcheverry Expires 27 December 2026 [Page 4] Internet-Draft Action Reference June 2026 +=============+========+===========================================+ | Field | Type | Description | +=============+========+===========================================+ | agent_id | string | Stable identifier for the executing agent | | | | at issuance time — the terminal executor | | | | after full delegation resolution. In a | | | | delegation chain A→B→C where C executes | | | | the action, agent_id is C. | +-------------+--------+-------------------------------------------+ | action_type | string | Semantic label for what the agent did | | | | (e.g., "code.execute", "payment.send", | | | | "oracle.signal"). | +-------------+--------+-------------------------------------------+ | scope | string | Terminal executing agent's requested- | | | | intent scope at the point of action. | | | | Non-empty string. MUST NOT be a derived | | | | hash of the intent object (see | | | | Section 6). | +-------------+--------+-------------------------------------------+ | timestamp | string | RFC 3339 UTC with exactly 3 millisecond | | | | digits. Format: YYYY-MM- | | | | DDTHH:MM:SS.mmmZ. See Section 3.4. | +-------------+--------+-------------------------------------------+ Table 1 The four fields are REQUIRED. No additional fields enter the preimage. Optional fields in the receipt envelope (Section 4) do not affect the action_ref value. 3.2. Serialization The four fields MUST be serialized using RFC 8785 JSON Canonicalization Scheme (JCS) before hashing: * Keys in lexicographic Unicode code point order: action_type, agent_id, scope, timestamp. * No whitespace between tokens. * UTF-8 encoded. * Values are JSON strings (standard JSON escaping only). The resulting JCS payload for a conformant implementation will sort keys in this order: action_type < agent_id < scope < timestamp. Etcheverry Expires 27 December 2026 [Page 5] Internet-Draft Action Reference June 2026 Implementations using the simple json.dumps approach (Python, Node.js) produce RFC 8785-compatible bytes for inputs within the safe band: ASCII-only field values, conformant RFC 3339 timestamps, no surrogate-pair Unicode. For inputs outside this band, implementations MUST use an RFC 8785-compliant library. 3.3. Hash Function action_ref = SHA-256(JCS(preimage)), encoded as lowercase hexadecimal. The output is a 64-character lowercase hex string (256 bits / 32 bytes). Uppercase hex is non-conformant. 3.4. Timestamp Format The timestamp field MUST conform to the following format constraints: * Timezone: "Z" suffix only. "+00:00" or any other offset representation is non-conformant. * Fractional precision: exactly 3 digits (milliseconds). No trailing zero suppression. ".000" is conformant; ".0" is not. * Template: YYYY-MM-DDTHH:MM:SS.mmmZ — one valid byte sequence per instant. These constraints close the [RFC3339] underspecification surface. RFC 3339 admits multiple lexically distinct encodings of the same instant that produce different SHA-256 digests under JCS. This specification closes that surface at the format level. Implementations holding epoch-millisecond integers MUST convert to the conformant RFC 3339 string before hashing. Implementations that hash the epoch-ms integer directly are not conformant. The W3C CG ai-agent-protocol discussion (issue #34) established epoch-millisecond integer as an application-layer representation. This specification uses the RFC 3339 string form in the preimage. The two representations are not interchangeable in the preimage — they produce different digests. 3.5. Derivation Example The following example is byte-verified in the conformance suite (vector "nexus-oracle-signal"): Etcheverry Expires 27 December 2026 [Page 6] Internet-Draft Action Reference June 2026 Input: agent_id = "nexus-agent-xa12.onrender.com" action_type = "oracle.signal" scope = "BTC" timestamp = "2025-05-18T11:40:31.000Z" JCS payload: {"action_type":"oracle.signal","agent_id":"nexus-agent-xa12.on render.com","scope":"BTC","timestamp":"2025-05-18T11:40:31.000Z"} SHA-256: fdd7f810499f06be24355ca8e2bfb8c4b965cc80c838f41fa074683443d89f5a 4. Canonical Receipt Envelope 4.1. Required Fields Implementations that emit a receipt referencing this specification SHOULD include the following fields to ensure long-lived verifiability: { "packet_version": "1.0", "action_ref": "", "hash_algo": "sha256", "preimage_format": "jcs-rfc8785-v1", "preimage": { "agent_id": "...", "action_type": "...", "scope": "...", "timestamp": "2026-05-15T10:00:00.123Z" } } packet_version: Forward-compatibility anchor. v1 verifiers can explicitly reject unknown versions rather than fail silently. hash_algo: Makes receipts self-describing. If a future implementation switches hash functions, receipts issued before the change remain replayable. preimage_format: Unambiguously identifies the serialization. Any verifier can recompute action_ref from the preimage fields using RFC 8785 without trusting the emitter. Etcheverry Expires 27 December 2026 [Page 7] Internet-Draft Action Reference June 2026 4.2. Optional Fields for Rotation Auditability The canonical receipt envelope v1.0 records state at the moment the action was claimed. It does not record whether that state was still valid when the action was admitted for execution. Two failure modes this gap creates: 1. *Trust tier degradation:* an agent moves from TRUSTED to WATCH between claim and execution. The anchor records the claim-time state. A verifier replaying the receipt cannot determine from the receipt alone whether the agent was still trusted when the action was admitted. 2. *Policy rotation:* the counterparty policy changes between issuance and execution. A counterparty_policy_hash field proves which policy was referenced at claim time, but does not prove whether that policy was still current at admission. Three optional fields close this gap: policy_version (string, OPTIONAL): Identifies which version of the governing policy was in force when the action was admitted. Distinct from counterparty_policy_hash, which proves which policy was referenced — policy_version proves whether it was still current at execution time. authority_verified_at_ms (integer, OPTIONAL): Unix timestamp in milliseconds at which the delegation authority was verified at issuance. Records when the acting agent's authority was confirmed before the action was admitted. revocation_check_at_ms (integer, OPTIONAL): Unix timestamp in milliseconds of the last non-revocation check performed before execution. Establishes a maximum window of credential exposure. A receipt without this field cannot prove the agent's credentials were valid immediately before the action was admitted. A verifier that requires post-rotation auditability SHOULD treat a receipt missing either field as unauditable for the rotation window — not as invalid. The millisecond precision for revocation_check_at_ms is REQUIRED. Credential checks in live multi-agent systems happen at sub-second granularity. Systems that only have second-precision timestamps SHOULD multiply by 1000 and document the precision loss. Etcheverry Expires 27 December 2026 [Page 8] Internet-Draft Action Reference June 2026 Note: the three optional fields in this section correspond to the "freshness" verification layer described in discussions on the agntcy/identity repository (issue #165). A verifier confirming offline signature integrity (integrity), checking that the executed scope sat within the delegated scope (authority), and establishing the key validity window at decision time (freshness) needs all three layers. The fields in this section address the freshness layer; the authorization_ref in Section 5 addresses the authority layer. 5. Three-Record Trail and authorization_ref 5.1. Layer Model action_ref is the correlation key across a three-record trail: 1. *Pre-execution record:* the commitment before the action is taken. Contains the action_ref preimage fields and authorization_ref. 2. *Decision record:* the authorization event. Contains authorization_ref as its identifier and action_ref as the correlation key. 3. *Receipt:* the post-execution record. Contains action_ref and authorization_ref; verifier checks both against the pre-execution record. A conformant verifier runs four independent checks across the trail: +====================+========================================+ | Check | Fields compared | +====================+========================================+ | Same call instance | action_ref in pre-execution == | | | action_ref in receipt | +--------------------+----------------------------------------+ | Same proposed | original_args_digest recomputed from | | payload | disclosed args | +--------------------+----------------------------------------+ | Same dispatched | effective_args_digest in pre-execution | | payload | == verifier-recomputed from receipt | +--------------------+----------------------------------------+ | Same authorization | authorization_ref in pre-execution == | | decision | authorization_ref in receipt | +--------------------+----------------------------------------+ Table 2 Etcheverry Expires 27 December 2026 [Page 9] Internet-Draft Action Reference June 2026 A trail that passes the first three checks but fails the fourth proves that execution proceeded under a different approval than the one recorded in the pre-execution entry. 5.2. authorization_ref Derivation authorization_ref is the identifier for the Decision record: authorization_ref = SHA-256(JCS({ "action_ref": "", "authorized_scope": "", "decision_ts": , "policy_id": "" })) JCS lexicographic key order: action_ref, authorized_scope, decision_ts, policy_id. Note: decision_ts is an epoch-millisecond integer, not an RFC 3339 string. Invariants: * action_ref is embedded in the preimage. A verifier can confirm the decision was not reused across action instances. * Recomputable without operator cooperation from the four decision record fields. * MUST appear in both the pre-execution record and the receipt. 5.3. Canonical Linking Key The same action_ref is computable from artifacts produced by independent systems using the same four-field derivation: * A Mycelium TrailRecord (preimage fields published in each record). * A Nobulex covenant receipt (action_type as semantic label + timestamp + agent_id + scope). * A SafeAgent claim (joint spec argentum-core issue #7). * A CrewAI idempotency key (crewAI PR #5822 — key derivation converges on this primitive from the retry-deduplication direction). * NEXUS oracle receipts (implements canonical envelope v1.0). Etcheverry Expires 27 December 2026 [Page 10] Internet-Draft Action Reference June 2026 Any verifier holding one artifact can validate against another without trusting either system. 6. Scope Conventions scope is a free-form non-empty string. Any value is valid as long as it is non-empty and consistent across all parties deriving the same action_ref. RECOMMENDED convention (non-normative): namespace-prefix with the emitter identifier using :, for example "algovoi:compliance_screen" or "presidio:x402.screen:clean-allow". Prefixing avoids collisions when trails from multiple emitters are verified or aggregated by a third party. The scope anti-pattern: scope MUST NOT be a derived hash of the intent object. A common mistake is to hash the initial intent object and use that hash as the scope value. This breaks the primary verifiability property: any party holding the four preimage fields must be able to recompute action_ref independently, without retrieving any external record. With a hashed scope, a verifier cannot recompute action_ref from the intent tuple alone — they must also retrieve the commitment record. Multi-value scope segments: when a scope segment encodes a set of values (e.g., entity types detected by a screening decision), implementations MUST sort those values lexicographically and join them with a comma and no spaces. This ensures byte-determinism across implementations that may produce values in non-stable detection order. 7. Conformance A conformance test suite with byte-verified vectors is maintained in [argentum-core]. The suite includes: * action-ref-v1-baseline: positive and negative vectors for the four preimage fields, including timestamp format violations. * guardrail-provider-v1: authorization_ref derivation vectors including NEG cases for decision reuse detection. * near-miss-v1: same action_ref, different state (KNOWN_DESIGN_PROPERTY). Etcheverry Expires 27 December 2026 [Page 11] Internet-Draft Action Reference June 2026 * recompute-drift-v1: epoch-integer non-conformance (neg-b01-epoch- integer). * signing-trust-ref-v1: operator key isolation vectors. * restraint-receipt-v1: deny and defer verdict vectors. Each conformance directory includes verify.py and verify.mjs. All vectors are byte-identical across implementations. The stable tag for v1.0 is "action-ref-v1.0" in the argentum-core repository. External conformance sets accepted under review: * examples/conformance/graph-advocate/ — PaulieB14 (Graph Advocate), counterparty-ref-v1, 3 vectors, 2 implementations byte-identical, production service. * examples/conformance/agentoracle-v1/ — TKCollective (AgentOracle + AgentTrust), 10 vectors, cross-issuer property verified. * examples/conformance/presidio-x402/ — vstantch/presidio-group.eu, PII screening with composition, 3 vectors. 8. Security Considerations 8.1. Replay Attack Surface action_ref is deterministic: the same four preimage field values always produce the same identifier. This is a design property — it enables cross-system correlation without operator trust. The implication is that action_ref alone does not prevent replay. Replay protection requires the receipt to carry: * authorization_ref (Section 5.2): binds the identifier to a specific authorization decision. A replayed action_ref with a different authorization decision will fail check 4. * signing-trust-ref-v1: an operator-independent signature over the full receipt envelope. An attacker cannot substitute a different receipt without invalidating the signature. A verifier that checks action_ref alone (without authorization_ref and signature) cannot detect replay. This specification requires both fields for complete replay resistance. Etcheverry Expires 27 December 2026 [Page 12] Internet-Draft Action Reference June 2026 8.2. Scope Injection If scope is not validated at emission time, an adversary can inject a scope string that differs from the actual intent. The action_ref will be a valid hash of the injected scope, not of the actual action. Verifiers SHOULD require that scope is provided by the executing agent, not derived or transformed by an intermediary system. 8.3. Timestamp Manipulation A non-conformant timestamp (wrong precision, wrong timezone suffix, epoch-ms instead of RFC 3339 string) produces a different digest. This can be used to generate action_refs that appear valid but cannot be independently recomputed by a conformant verifier. Implementations MUST validate timestamp format at emission time, not only at verification time. 8.4. Operator-Independence Guarantee The operator-independence property holds only if: 1. The four preimage fields are disclosed to verifiers. 2. The hash function and serialization are public and deterministic. 3. No field in the preimage is derived from an operator-controlled system without disclosure. An emitter that uses a non-public agent_id (e.g., a UUID assigned by an internal sequencer and not disclosed) breaks the verifiability property: a verifier cannot recompute action_ref without retrieving the agent_id from the operator. Implementations MUST use stable, publicly disclosed agent identifiers. 9. Interoperability Considerations action_ref is compatible with SCITT transparency logs [I-D.ietf-scitt-architecture] as an anchoring layer. A SCITT-enabled system can treat action_ref as the payload hash submitted to a Transparency Service: the resulting SCITT receipt provides a signed inclusion proof over the same content-addressed identifier defined in this specification. The on-chain anchor described in Section 6 is conceptually equivalent to a SCITT receipt — both bind a content- addressed identifier to an external, operator-independent timestamp — but the on-chain variant does not require hardware TEE endorsement or a dedicated Transparency Service deployment. Implementers operating within SCITT-enabled infrastructure MAY substitute a SCITT receipt for the on-chain anchor without changing the action_ref derivation Etcheverry Expires 27 December 2026 [Page 13] Internet-Draft Action Reference June 2026 algorithm or the receipt envelope structure defined in this document. 10. IANA Considerations This document has no IANA actions. 11. References 11.1. Normative References [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, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . 11.2. Informative References [argentum-core] Giskard, R., "argentum-core: Mycelium Trails Reference Implementation and Conformance Suite", 2026, . [CTEF] kenneives, K., "Composable Trust Evaluation Framework (CTEF)", 2026, . [AgentGraph-EvidenceAnchor] kenneives, K., "evidence-anchor-static-analysis-v0: Static analysis conformance set for action_ref", June 2026, . [I-D.ietf-scitt-architecture] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Jaeger, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains (SCITT)", Work in Etcheverry Expires 27 December 2026 [Page 14] Internet-Draft Action Reference June 2026 Progress, Internet-Draft, draft-ietf-scitt-architecture, 2024, . Appendix A. Test Vectors All vectors are byte-verified in the conformance suite at . A.1. Positive Conformance Vector Vector: nexus-oracle-signal (action-ref-v1-baseline) agent_id = "nexus-agent-xa12.onrender.com" action_type = "oracle.signal" scope = "BTC" timestamp = "2025-05-18T11:40:31.000Z" JCS payload (UTF-8): {"action_type":"oracle.signal","agent_id":"nexus-agent-xa12.on render.com","scope":"BTC","timestamp":"2025-05-18T11:40:31.000Z"} action_ref: fdd7f810499f06be24355ca8e2bfb8c4b965cc80c838f41fa074683443d89f5a A.2. Negative Conformance Vector — Epoch-Integer Timestamp Vector: neg-b01-epoch-integer (recompute-drift-v1) Same action as A.1, but timestamp hashed as epoch-ms integer instead of RFC 3339 string. Produces a different digest. Non-conformant preimage (epoch-ms as integer — DO NOT USE): {"action_type":"oracle.signal","agent_id":"nexus-agent-xa12.on render.com","scope":"BTC","timestamp":1747568431000} A verifier recomputing from the RFC 3339 string will obtain a different hash and correctly reject the receipt. A.3. authorization_ref Vector Etcheverry Expires 27 December 2026 [Page 15] Internet-Draft Action Reference June 2026 Vector: step_2b_authorization_ref (guardrail-provider-v1) action_ref = "104812928eb50e0e1ad28f379f8ade03ea0f479ac7abd1b bf9205e9317665c7f" authorized_scope = "autogen:guardrail" decision_ts = 1749513600000 policy_id = "guardrail-policy-v1" JCS payload: {"action_ref":"104812928eb50e0e1ad28f379f8ade03ea0f479ac7abd1bbf920 5e9317665c7f","authorized_scope":"autogen:guardrail","decision_ts": 1749513600000,"policy_id":"guardrail-policy-v1"} authorization_ref: b9f8494a4a5943687d105769556be2963271e37f2216d2afd279e5b260261327 Appendix A.4. External Conformance Set — evidence-anchor-static- analysis-v0 Contributed by: AgentGraph (agentgraph-co/agentgraph, kenneives). This conformance set anchors static analysis findings from an agent- ecosystem endpoint scan (35,689 endpoints; June 2026) to verifiable action_ref identifiers. It contains 4 byte-verified vectors covering three invariants: 1. *Scan-attest anchor:* a scan.attest action from a did:web scanner agent produces a stable action_ref independently recomputable by any verifier without registry access. 2. *Cross-implementation byte match:* the spec's Appendix A Vector 1 (nexus-oracle-signal, fdd7f810…) reproduces byte-for-byte using the rfc8785 Python library and Node built-ins — two independent implementation lineages agreeing on the same digest. 3. *Live ecosystem seam:* the payment-charge vector's action_ref is identical to the one carried in AgentGraph's v0.4 pre-execution- verdict-v0 verifier fixture, where it is byte-matched across the haroldmalikfrimpong-ops / evidai / azender1 payment seam — this derivation is exercised live, not only specified. All 4 vectors are byte-verified in the conformance directory at . The set was contributed under AGT PR #21 (evidence-anchor-static-analysis-v0, merged 2026-06-24). Etcheverry Expires 27 December 2026 [Page 16] Internet-Draft Action Reference June 2026 Appendix B. Field Mapping for Existing Systems Systems that have adopted action_ref derivation or compatible primitives: +==============+==========+====================+====================+ |System |agent_id |action_type mapping |Notes | | |mapping | | | +==============+==========+====================+====================+ |SafeAgent |agent |claim type |Joint spec argentum-| |(azender1) |identifier| |core #7 | +--------------+----------+--------------------+--------------------+ |Graph Advocate|wallet |counterparty event |counterparty-ref-v1,| |(PaulieB14) |address |type |production | | |(EIP-55) | | | +--------------+----------+--------------------+--------------------+ |AgentOracle/ |issuer DID|oracle action type |Two issuers, cross- | |AgentTrust | | |issuer property | |(TKCollective)| | | | +--------------+----------+--------------------+--------------------+ |CTEF ([CTEF]) |agent |evaluation action |action_ref REQUIRED | | |graph node| |in v0.4 | | |ID | | | +--------------+----------+--------------------+--------------------+ |presidio-x402 |screening |presidio:x402.screen|PII screening, | |(vstantch) |agent ID | |composition | +--------------+----------+--------------------+--------------------+ Table 3 Author's Address Pablo Etcheverry Rama Email: playplay2736@gmail.com URI: https://github.com/giskard09/argentum-core Etcheverry Expires 27 December 2026 [Page 17]