Provenance blindness in agent data pipelines

Understand why autonomous agents trust ingested data they cannot verify, and how a cryptographic "epistemic watermark" attaches four verifiable guarantees — authenticity, integrity, temporal binding and origin traceability — to any artifact without contacting a central authority.

Track

Research

Module

5 · Research case studies

Prerequisites

Hash functions · Digital signatures

Autonomous agents act on data from the outside world — text, images, documents, structured feeds. Acting on that data means assuming things about it: that the document was created when its metadata says, that the image was not modified since, that three "independent" feeds are not secretly the same source, that the processing chain applied to the data was the declared one. The source paper argues these assumptions are false in the general case and, worse, fail invisibly: nothing in a plain artifact lets a verifier detect that the timestamp was back-dated or the bytes were swapped after the fact.

The paper frames this as a single root cause it calls provenance and processing blindness, and ties it to three named structural defect classes in agent systems: stale beliefs acted on as fresh, post-hoc filtering with no causal trace, and a single source laundered into apparent independence so a belief looks corroborated when it is not.

The core move is an analogy the paper calls an isomorphism. Blockchain developers faced a structurally identical problem in 2012: verify that a transaction was authorized by the claimed sender, at the claimed time, unmodified in transit, without contacting any authority in real time. Their answer — hierarchical deterministic (HD) wallets built on BIP32 key derivation with BIP39 mnemonic seeds — is now deployed at scale and heavily audited. The proposal reuses that exact cryptographic foundation for artifact provenance rather than inventing new primitives.

Concretely, every artifact entering the pipeline carries a small signed header. A verifier checks that header offline, using only the artifact itself and a cached public-key registry — no live call to the emitter, no trusted third party in the request path.

Artifact

Any unit of data an agent ingests: a JSON record, a PDF, a JPEG, a medical image, an HTTP feed response, a CSV row set.

Emitter

The party that produced and signed the artifact, identified by a decentralized identifier (a DID such as did:web:org.example), not by a network address.

Provenance header

A compact, signed structure embedded in or alongside the artifact that carries the facts a verifier needs to check authenticity, integrity, freshness and origin.

Offline verification

Checking those facts without contacting the emitter or any central authority in real time — the property that makes the scheme deployable at pipeline speed.

The paper defines the header as a fixed tuple of fields plus a signature. The fields pin down the bytes, the time, the origin and the context; the signature binds all of them together so none can be changed without detection.

EWS header fields (schematic — transformed from the paper's Definition 1)
header = {
  version:      "1.0",
  content_hash: SHA256(artifact_bytes),   // integrity anchor
  sourced_at:   <unix timestamp of creation>,
  origin_id:    <emitter DID, e.g. did:web:org.example>,
  domain:       <content-domain label>,   // e.g. "medical", "financial"
  ttl_hint:     <recommended time-to-live, seconds>,
  signature:    EdDSA over a canonical serialization of the fields above
}

From a valid header the paper claims four verifiable guarantees. Read them as distinct properties, each defeating a distinct attack:

G1 — Authenticity

The artifact was signed by the holder of the private key registered for origin_id. Defeats identity spoofing.

G2 — Integrity

The bytes have not changed since signing; any edit breaks the content_hash and invalidates the signature. Defeats tampering after signing.

G3 — Temporal binding

sourced_at cannot be altered retroactively, because the signing key itself is derived from the timestamp (developed in part 2). Defeats back-dating.

G4 — Origin traceability

A verifier can check structural independence of sources from signed origin_id values alone, without building an external provenance graph. Defeats single-source laundering.

Suppose an agent ingests three "independent" market feeds before raising a high-confidence belief. Without provenance headers, three responses that all trace back to one upstream database look like three corroborating witnesses.

synthetic — origin independence from signed headers
feed_A.header.origin_id = did:web:source-one.example
feed_B.header.origin_id = did:web:source-one.example   # same emitter!
feed_C.header.origin_id = did:web:source-two.example

# G4 check at ingestion:
distinct_origins = { A.origin_id, B.origin_id, C.origin_id }
# -> only 2 truly independent origins, not 3
# the agent must NOT treat A and B as independent corroboration

The honest reading: the header does not tell the agent the feeds are correct, only that two of them share a signed origin. That is enough to refuse the "three independent sources agree" inference — a structural check, done offline, with no external graph lookup.

The design intent is to move provenance from something you detect after the fact to something enforced by construction at the ingestion boundary. The paper specifies that an agent architecture mandating a valid header on every ingested artifact makes its three target defect classes impossible to introduce: a belief cannot be stale if freshness is checked against a signed timestamp; post-hoc filtering cannot hide its causal trace if every artifact is hash-anchored; single-origin amplification cannot occur if independence is verified from signed origins.

This connects to agent-security failure modes elsewhere in the knowledge base. Memory poisoning and retrieval poisoning both rely on injecting data the agent cannot attribute or date; a mandatory provenance header raises the cost of those attacks by forcing injected artifacts to either carry a valid registered-emitter signature or be flagged unverified before any belief is derived from them.

What is actually established at this stage, stated honestly:

• ▸PROVEN by construction: if every ingested artifact must pass a valid header check, the three named defect classes cannot be introduced through ingestion — this is an architectural property of mandatory enforcement, not an empirical result.
• ▸DESIGN / SPECIFICATION: the header schema, the four guarantees, and the format-specific embeddings are a specification the paper proposes; they reuse standard, audited primitives (BIP32, EdDSA, SHA-256) rather than new cryptography.
• ▸OPEN (the residual trust assumption): the scheme cannot stop a registered, legitimate emitter from signing false content. Authenticity of origin is not truthfulness of content — the paper names this threat T8 and defers it to accountability, not cryptography.
• ▸OPEN: migration of pre-existing, header-less "legacy" data is acknowledged as a real adoption cost, handled by a transitional pragmatic mode rather than solved.

Expected direction: G4 (origin traceability). The signed origin_id fields let the verifier see that two of the three feeds share the same emitter, so they are not independent corroboration. A plain artifact carries no verifiable origin, so three responses from one laundered source look identical to three from three genuinely independent sources.

What does a valid provenance header prove, and what does it NOT prove?

It proves authenticity, integrity, freshness and origin of the exact bytes (G1–G4). It does not prove the content is true — a legitimate emitter can still sign false data (threat T8).

Why does the proposal reuse BIP32/BIP39 rather than invent new cryptography?

Because the agent-provenance problem is structurally the same as verifying a blockchain transaction offline, and HD-wallet key derivation is already deployed at scale and heavily audited.

Which defect class does G4 (origin traceability) target?

Single-origin belief amplification — a lone source laundered into apparent independent corroboration. Signed origin_id values let a verifier detect shared origins offline.