]> Rama

playplay2736@gmail.com https://github.com/giskard09/argentum-core

General Independent Submission agent action audit content-addressed accountability JCS RFC 8785 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. Discussion of this draft takes place on the argentum-core repository: <https://github.com/giskard09/argentum-core>. A conformance test suite with byte-verified vectors is maintained at <https://github.com/giskard09/argentum-core/tree/main/examples/conformance>.

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 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 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.
• The authorization_ref derivation for three-record trail correlation.
• Scope conventions for cross-emitter disambiguation.
• Security considerations including replay attack surface.

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 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 . Produces a unique byte sequence for any JSON value.

trail:

A sequence of records (pre-execution, decision, receipt) correlated by action_ref across systems.

Action Reference Derivation

Preimage Fields The preimage is a JSON object containing exactly four fields:

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 ).
timestamp	string	RFC 3339 UTC with exactly 3 millisecond digits. Format: YYYY-MM-DDTHH:MM:SS.mmmZ. See .

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.

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. 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.

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.

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 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.

Derivation Example The following example is byte-verified in the conformance suite (vector "nexus-oracle-signal"):

Canonical Receipt Envelope

Required Fields Implementations that emit a receipt referencing this specification SHOULD include the following fields to ensure long-lived verifiability: ", "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.

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. 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.

Three-Record Trail and authorization_ref

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 payload	original_args_digest recomputed from disclosed args
Same dispatched payload	effective_args_digest in pre-execution == verifier-recomputed from receipt
Same authorization decision	authorization_ref in pre-execution == authorization_ref in receipt

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.

authorization_ref Derivation authorization_ref is the identifier for the Decision record: ", "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.

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).

Any verifier holding one artifact can validate against another without trusting either system.

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 <emitter>:<scope>, 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.

Conformance A conformance test suite with byte-verified vectors is maintained in . 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).
• 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.

Security Considerations

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.

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.

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.

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.

Interoperability Considerations action_ref is compatible with SCITT transparency logs 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 algorithm or the receipt envelope structure defined in this document.

IANA Considerations This document has no IANA actions.

References Normative References Informative References

Appendix A. Test Vectors All vectors are byte-verified in the conformance suite at <https://github.com/giskard09/argentum-core/tree/main/examples/conformance>.

A.1. Positive Conformance Vector

A.2. Negative Conformance Vector — Epoch-Integer Timestamp

A.3. authorization_ref Vector

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 <https://github.com/agentgraph-co/agentgraph>. The set was contributed under AGT PR #21 (evidence-anchor-static-analysis-v0, merged 2026-06-24).

Appendix B. Field Mapping for Existing Systems Systems that have adopted action_ref derivation or compatible primitives:

System	agent_id mapping	action_type mapping	Notes
SafeAgent (azender1)	agent identifier	claim type	Joint spec argentum-core #7
Graph Advocate (PaulieB14)	wallet address (EIP-55)	counterparty event type	counterparty-ref-v1, production
AgentOracle/AgentTrust (TKCollective)	issuer DID	oracle action type	Two issuers, cross-issuer property
CTEF ()	agent graph node ID	evaluation action	action_ref REQUIRED in v0.4
presidio-x402 (vstantch)	screening agent ID	presidio:x402.screen	PII screening, composition