From artifact provenance to action accountability

Understand how a five-level trust chain extends single-artifact provenance across the whole agent pipeline — model, pipeline steps, decisions, actions — what each level actually guarantees, and where the chain stops being cryptography and becomes legal accountability.

Track

Research

Module

5 · Research case studies

Prerequisites

Hash chains and transparency · Authorization and action control

Provenance on one artifact answers "can I trust this input?". But an agent does more than ingest: it runs a model, applies a chain of transformations, derives a decision, and executes an action. A trustworthy audit has to follow all of it. The paper extends single-artifact provenance into a stack of five trust levels, each independently verifiable, so that a system can honestly state which levels it actually meets instead of claiming blanket "trustworthiness".

L1 — Data provenance

Every ingested artifact carries a valid watermark header (parts 1–2): authenticity, integrity, temporal binding, origin traceability.

L2 — Model attestation

The model invoked at each stage is the declared version, unmodified, running in an attested environment — verified via a hash of the model weights signed by the provider, optionally inside a trusted execution environment.

L3 — Pipeline integrity

The sequence of transformations from ingestion to belief is the declared sequence in the declared order; each step appends a hash-chain entry over input hash, operation id, and output hash, so any reordering or edit breaks the chain.

L4 — Decision traceability

Every decision can be deterministically reconstructed from the recorded state at decision time — the audit log must hold the belief snapshot, the rule selection, the plan, and the capability-invocation sequence.

L5 — Action accountability

Every executed action links back to an identified accountable party — a human principal or a registered organization — traceable under applicable law.

pipeline integrity hash chain (L3, schematic)
chain_n = SHA256( chain_{n-1} || op_n || input_hash_n || output_hash_n )
# append-only; the final chain hash is stored with the belief.
# any modification to any step invalidates every later link.

The crucial honest distinction in this part: some levels are satisfied by cryptographic construction, others require deployment-specific configuration the paper cannot guarantee for you.

• ▸By construction (cryptographic): L1 data provenance and L3 pipeline integrity are enforced by signatures and hash chains — if the enforcement runs, these hold. L4 decision traceability holds when the agent core is deterministic, so the recorded state fully reconstructs the decision.
• ▸Deployment-dependent: L2 model attestation needs a trusted execution environment and a signed model-weights registry, which are not universally available. L5 action accountability is organizational and legal, not cryptographic — the chain can point to an accountable party, but enforcement is a matter of law and governance.

The paper maps the five levels to public regulatory requirements (the EU AI Act's articles on risk management, record-keeping, transparency, human oversight and quality management, and related financial-sector and data-protection rules). It presents the stack as a technically complete implementation specification for those obligations. Read this as the authors' claim of coverage, not as a certification: no regulator has blessed the mapping, and meeting a technical level is necessary but not sufficient for legal conformance.

To make the stakes concrete the paper describes an anonymized instance: a deployed decision-support system produced a high-confidence, irreversible, and incorrect output after acting on a belief derived from data that was roughly a decade stale, carried no verified timestamp, and whose apparently independent sources shared one origin.

The paper argues that under mandatory L1, the stale artifact would have failed the freshness check in the rejection protocol (its effective time-to-live for an irreversible action being zero), so no belief would have been derived and the incorrect high-confidence output could not have been produced; and under L5, the accountability chain would have identified who was responsible for a decade-old artifact sitting in a production pipeline with no freshness marker.

The paper analyzes the scheme against nine threat classes. The pattern worth internalizing is that each level neutralizes a specific family of attacks, and one threat is deliberately left unsolved by cryptography.

• ▸Back-dating -> defeated by temporal key binding (the proof in part 2).
• ▸Content forgery / tampering -> defeated by the content hash (integrity).
• ▸Identity spoofing -> defeated by registry lookup plus signature verification.
• ▸Key compromise -> mitigated by HD key rotation and the revocation registry.
• ▸Replay of a valid header on new content -> defeated by binding the content hash and timestamp into the signature.
• ▸Cross-domain misuse (e.g. a medical signature reused for finance) -> defeated by domain-branched key derivation.
• ▸Pipeline tampering -> defeated by the L3 hash chain.
• ▸Malicious emitter (T8) -> NOT defeated by cryptography. A registered emitter can sign false content; the scheme can only prove who signed it, then rely on L5 legal accountability.

For agent builders, the operational lesson connects to the confused-deputy and excessive-agency failure modes elsewhere in the knowledge base: provenance and pipeline integrity make an action attributable and reconstructable, which is a precondition for accountability — but attribution is not prevention. A watermark tells you who authorized an over-broad action and lets you reconstruct how it happened; it does not by itself stop the action.

The honest summary of the whole case study:

• ▸PROVEN by construction: L1 and L3 hold if their signature and hash-chain enforcement actually run; L4 holds when the decision core is deterministic. These are design guarantees, contingent on correct implementation.
• ▸DEPLOYMENT-DEPENDENT: L2 needs trusted execution environment support the paper admits is not universally available; L5 is legal and organizational, outside the reach of any cryptographic proof.
• ▸ILLUSTRATIVE only: the motivating prevented-failure case is an anonymized counterfactual, and the performance numbers (part 2) are single-machine estimates. There is no reported controlled evaluation or third-party benchmark.
• ▸OPEN — the residual trust assumption: a malicious but registered emitter (T8) can sign false data. The framework reduces this risk to accountability rather than eliminating it. Authenticity of origin is never truthfulness of content.
• ▸OPEN — adoption: the standard is a specification with a staged adoption path (architecture, consortium, internet draft, regulation), not a ratified standard; the regulatory mapping is the authors' claim, not an endorsement.

Expected direction: L2 (model attestation) and L5 (action accountability). L1 and L3 are cryptographic and hold by construction if their enforcement runs. L2 depends on deployment-specific infrastructure (a trusted execution environment and a signed model-weights registry) that may be absent, and L5 is legal/organizational — it can only point to an accountable party, not cryptographically guarantee accountability. A blanket L5 claim therefore rests on configuration and governance, not proof.

Which trust levels hold "by construction" and which depend on deployment?

L1 (data provenance) and L3 (pipeline integrity) hold by construction if enforcement runs, and L4 holds when the decision core is deterministic. L2 (model attestation) needs a trusted execution environment, and L5 (action accountability) is legal/organizational — both are deployment-dependent.

What does the L3 pipeline hash chain prove, and what does it NOT prove?

It proves the recorded sequence of transformations was not altered after the fact (tamper-evidence). It does not prove the sequence was the correct or appropriate one to run.

Why is threat T8 (malicious emitter) left unsolved by cryptography?

Because a signature can only prove who produced the bytes, not whether the content is true. A legitimate registered emitter can sign false data, so the residual risk is pushed to L5 legal accountability.