EMILIA Protocol, Inc.

US team@emiliaprotocol.ai

sec AI agents evidence admissibility reliance policy replay JCS The standards landscape now produces many signed artifacts about an AI agent's action: workload identity credentials, delegation and grant tokens, call-chain transaction tokens, runtime attestation results, pre-execution policy permits, named-human authorization receipts, post-execution action records, and transparency-log inclusion receipts. No specification defines how a relying party decides whether a collection of such artifacts is SUFFICIENT to rely on for a given purpose: releasing a payment, honoring a trade, satisfying an auditor, or paying an insurance claim. This document defines three things that together fill that layer: the Action Evidence Graph (EP-AEG), a portable, content-addressed graph of references to signed artifacts about one action, whose identity is independent of how much of it is disclosed; Evidence Policy Replay, a deterministic, offline evaluation of a graph against a RELYING-PARTY-supplied evidence policy, yielding one of five closed verdicts (admissible, missing_evidence, stale, conflicted, unverifiable) with a replay digest that lets any third party recompute the decision; and the Reliance Result (EP-RELIANCE-RESULT), the verdict as a signed artifact, making the reliance decision itself auditable evidence. Six policy packs profile the mechanism for concrete irreversible action classes. A verdict is evidence of sufficiency under a stated policy; it is not adjudication, and the graph never carries its own sufficiency bar.

Introduction Standards efforts have converged on signing artifacts about agent actions, and on a shared substrate for doing so: a canonical digest of the action (JSON Canonicalization Scheme, JCS ) bound under a signature. Workload identity (WIMSE, SPIFFE), delegation and grants (OAuth, GNAP ), call-chain context (OAuth transaction tokens), runtime attestation (RATS , EAT ), pre-execution permits, named-human authorization receipts, post-execution action records, and transparency services (SCITT ) each produce their own artifact. Each artifact answers its own question. None answers the relying party's question: Given all of these artifacts, is this action evidence sufficient for THIS reliance purpose? A bank releasing a wire, an insurer paying a claim, a regulator auditing an agent's action, and a gateway deciding whether to execute an irreversible call each need a different sufficiency bar over the same artifacts. Today that decision is made ad hoc, is not reproducible, and leaves no evidence of its own. This document defines the missing layer. It deliberately defines no new receipt type: every leg of an evidence graph is an existing artifact verified under its own specification's rules. Within the same family, defines the named-human authorization artifact this layer most often consumes, and defines same-action composition of heterogeneous receipts into one ALLOW/DENY; this document generalizes that composition into a referenced graph and adds the purpose-relative sufficiency decision, its replay property, and the signed reliance result.

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. Relying party: the entity deciding whether to act on the evidence (execute, settle, audit, insure). Presenter: the entity assembling and conveying the graph, typically the agent operator. The presenter and relying party MUST be assumed to be different trust domains.

The Action Evidence Graph (EP-AEG-v1) An evidence graph is a JSON document with members "@version" (the string "EP-AEG-v1"), "action_digest" (the JCS/SHA-256 digest of the canonical action), "nodes", and "edges".

Nodes are content-addressed references Each node has an "id" equal to the SHA-256 digest of the referenced artifact's JCS-canonical bytes, a "type" token naming the artifact class (for example authorization_receipt, policy_permit, workload_identity, execution_attestation, transparency, delegation, recourse_reference), and OPTIONALLY the artifact itself inline. A verifier MUST reject an inline artifact whose canonical digest does not equal the node id. Because nodes are references, a presenter can disclose the SHAPE of its evidence without the contents; an undisclosed node contributes nothing to sufficiency and a required undisclosed node fails closed.

Edges are presenter claims, verified against bytes Each edge has "from" and "to" node ids and a "rel" from the relation registry: authorizes, permits, delegates, executes, records, attests_runtime, revokes, provides_recourse, supersedes. An edge is a PRESENTER CLAIM. A verifier MUST NOT credit an edge unless the claimed binding is present in the source artifact's own canonical bytes (at minimum, containment of the target's digest; artifact-type-specific verifiers MAY require a stricter, field-level binding). A claimed edge that the bytes do not back MUST poison the evaluation: the graph has asserted something its evidence does not support, and the verdict MUST NOT be admissible.

Graph identity is disclosure-independent The graph digest is computed over the sorted (id, type) node pairs, the sorted edges, and the action digest, and never over inline artifact bytes. Two parties holding different disclosures of the same graph agree on what graph they are discussing.

Evidence Policy Replay The sufficiency bar is an EVIDENCE POLICY supplied by the relying party. The graph document has no policy member, by construction: a presenter choosing its own sufficiency bar is the confused-deputy failure of evidence systems. A policy names its reliance purpose; a boolean requirement expression over node types; per-type freshness bounds; per-type revocation requirements; and REQUIRED EDGES — bindings that must be present and byte-backed (for example, an execution record MUST provably reference the authorization it acted under). Evaluation is deterministic and offline: given the same graph, policy, and evaluation time, any implementation reaches the same verdict and the same replay digest (a canonical digest over the policy, the normalized evidence facts, the graph digest, and the evaluation time). The verdict is one of a CLOSED set of five: admissible, missing_evidence, stale, conflicted, unverifiable, with precedence unverifiable over conflicted over stale over missing_evidence over admissible, so no failure ever degrades toward admissibility. Machine-readable reason codes accompany the verdict; the reference implementation currently emits unbacked_edge_claim, malformed_graph, and action_digest_mismatch, and additionally reserves (declares but does not yet emit) missing_human_approval, untrusted_workload, contradicted_outcome, revoked_artifact, and stale_evidence for richer classifications. The reason vocabulary is open, the verdict set is not. The token "admissible" is a protocol token naming sufficiency under the stated policy; it carries no legal meaning, and whether the wire name should instead read "sufficient" is an open editorial question for -01 -- the semantics are fixed.

Replay determinism, precisely The replay digest is the canonical digest (JCS-style, I-JSON subset) of exactly three inputs: the policy object as supplied; the ordered list of NORMALIZED EVIDENCE FACTS; and the evaluation time. This composite is then bound to the graph digest. A normalized evidence fact carries, per node and nothing more: type, label, verified (boolean), the action digest the artifact itself attests, outcome (if the artifact carries one), revoked (boolean), age in seconds relative to the evaluation time, the derived staleness boolean, and whether the policy required a revocation check for that type. Raw artifact bytes, network state, and clock reads are excluded by construction; two evaluators disagreeing on a replay digest are by definition evaluating different inputs. Failure semantics are fixed, not implementation-defined. A node whose type has no registered verifier, whose inline artifact does not hash to its node id, or whose verifier throws yields verified=false and the bundle cannot reach admissible (unverifiable-class failures). A node REFERENCED but not disclosed (no artifact bytes available) contributes a fact with verified=false: if the policy's requirement needed that type, the verdict is missing_evidence -- the evidence may exist but was not presented; nothing about the graph lied. By contrast a CLAIMED edge the source artifact's bytes do not back is a lie about the evidence and forces unverifiable regardless of what else verified. The distinction is deliberate: absence degrades to "not enough", deception degrades to "not trustable".

The Reliance Result (EP-RELIANCE-RESULT-v1) The verdict MAY be issued as a signed artifact carrying the verdict, reason codes, action digest, graph digest, policy digest and identifier, reliance purpose, replay digest, and evaluation time, signed by the relying party's verifier key. The signature adds ACCOUNTABILITY, never authority: any third party can recompute the replay digest rather than trust the signer. A consumer distinguishes VERIFIED (the signature holds over the canonical payload) from ACCEPTED (the consumer additionally trusts the signing verifier via an out-of-band pinned key); a reliance result from an unpinned verifier MUST NOT be accepted. Signed reliance results make reliance decisions themselves auditable: an institution can prove, later, which policy it applied to which evidence before it acted.

Policy Packs This document profiles six policy packs for concrete irreversible action classes: wire transfer, vendor bank-account change (a distinct-human quorum, not a single approver), credential rotation, production data deletion, regulated trade execution (post-hoc: the execution record must provably reference its authorization, and the record must be transparency-logged), and healthcare record export. A pack is a starting point the relying party adopts and owns: pinning its own trust anchors and tightening freshness to its risk appetite. No pack waives fail-closed behavior.

Security Considerations The presenter controls the graph; every defense in this document assumes it. Edges are claims verified against artifact bytes; the policy is never read from the graph; undisclosed required nodes fail closed; a lying edge poisons the verdict; verdict precedence never degrades toward admissibility; and the replay digest makes every decision recomputable. What this layer does NOT do is equally load-bearing: a verdict of admissible is evidence that a bundle met a stated policy at a stated time; it is not a guarantee the action was correct or safe, it does not adjudicate disputes, and it confers no authority beyond what the underlying artifacts carry. Each artifact class is verified under its own specification; this document inherits, and does not weaken, each one's trust model.

IANA Considerations This document has no IANA actions. Future versions may register the edge-relation and reason-code vocabularies.

References Normative References Informative References EMILIA Protocol, Inc. EMILIA Protocol, Inc.

Worked Example (Non-Normative) The following objects are a complete, verifiable vector produced by the reference implementation with a fixed test seed; the runnable form ships with the reference implementation (examples/evidence-graph/). Long lines are wrapped per the single-backslash strategy of RFC 8792. The graph carries three disclosed nodes for one wire-transfer action and one claimed edge (the permit provably references the authorization it permits); under the wire-transfer policy pack at evaluation time 2026-07-02T12:03:00Z the verdict is admissible, and one hour later the same graph under the same policy is stale. The evidence graph: The relying-party policy (the wire-transfer policy pack): The signed reliance result (Ed25519 over the canonical payload; the replay digest is recomputable from the graph and policy above):

Implementation Status A reference implementation (graph evaluation, policy replay, signed reliance results, and all six policy packs) is published under Apache-2.0 in the EMILIA Protocol repository, with a test suite covering the fail-closed invariants described here, including disclosure-independent graph identity, unbacked-edge poisoning, required-edge stripping, freshness degradation, and replay determinism. It builds on the same codebase's authorization-receipt, quorum, evidence-chain, and admissibility layers.

Acknowledgments The composition seam this document builds on was materially sharpened by Songbo Bu's review of the digest bindings between the human-authorization and action-record layers, and by his independent execution and verification of the published EP artifacts against a pinned commit, reported to the SECDISPATCH list on 23 June 2026. The comparative, claim-disciplined framing of the surrounding landscape owes much to the authorization- evidence survey maintained by Mohamad Khalil-Yossif. Acknowledgment implies no endorsement of this document.