## Why trust needs an anchor
Wuh gine on, world! Anaiya here. ππΎ
Over the last several dispatches, we shared real-world data from our lab: how signed instructions change agent decision boundaries, how we ran clean-room diagnostic evaluations against the OWASP agent security guidance, and how we caught hardcoded placeholder badges that declared systems sealed when nothing had verified them.
Behind all those experiments lies a foundational discipline that is often misunderstood or reduced to a buzzword: **cryptographic provenance**.
In modern computing, we are flooded with synthetic text, autonomous agent edits, multi-branch pipelines, and rapidly shifting context windows. When an autonomous model or a human reviewer looks at a file, an instruction, or an API payload, they face an urgent question:
> **How do you know what you are reading is authentic, who actually created it, what authority they had, and whether a single byte changed along the way?**
This guide breaks down what cryptographic provenance is, how our local-first implementation operates under the hood, what it can and cannot tell you, and the practical questions engineering teams ask when implementing it.
---
## 1. What is cryptographic provenance?
At its core, **provenance** is the documented history of an artifact: its origin, custody, transformations, and verification states over time.
In analog art, provenance is the chain of gallery records, auction bills, and estate catalogs establishing that a canvas was truly painted by the master rather than a skilled forger.
In digital systems and agentic AI, **cryptographic provenance** replaces subjective trust and paper trails with mathematical guarantees. Instead of trusting a database row, an unverified timestamp header, or a green UI badge, cryptographic provenance binds an artifact directly to:
1. **Deterministic Content Identity (SHA-256)**: Proving the file has not drifted by even a single whitespace character.
2. **Cryptographic Authorship (Ed25519 / OpenPGP)**: Proving exactly which private key signed the statement.
3. **Explicit Scope and Purpose**: Defining precisely what resource, operation, or environment the signature applies to.
4. **Independent Temporal Anchoring (RFC 3161)**: Proving that the artifact existed in that exact state at a verifiable atomic time.
5. **Decoupled Verification Sidecars**: Storing the cryptographic proofs alongside the file without modifying or polluting the canonical source bytes.
---
## 2. The core distinctions: what provenance actually separates
One of the greatest hazards in software architecture is conflating distinct operational concepts into a single vague idea of "verified."
Our open-source engine, hosted at [github.com/MoongladeAI/provenance](https://github.com/MoongladeAI/provenance) (standalone release pending), enforces five clean distinctions:
### A. Observation is not authorship
Anyone can calculate the SHA-256 digest of a file. Recording that digest proves that you *saw* the file in a specific state. It does **not** prove that you *authored* it, that you *approved* it, or that you have *authority* over its contents. Provenance keeps content digests and identity attestations strictly separated.
### B. A hash is not a signature
A hash provides integrity; it answers whether the bytes changed. A digital signature provides non-repudiation; it answers who signed the claim. An artifact can have pristine hash integrity while being completely unsigned or originating from an adversarial actor.
### C. A signature is not human authorization
In modern multi-agent systems, agents sign artifacts autonomously to establish pipeline custody. But an autonomous agent's signature does not equal a human founder's or executive's sign-off. Provenance formats must explicitly distinguish unattended agent credentials from interactive human authorization tokens.
### D. A valid signature is not factual truth
If an authorized author signs a document that contains an error, the cryptographic signature will verify with mathematical perfection. Cryptography proves that the author wrote those exact words; it does not turn false claims into physical facts. Provenance protects integrity and attribution, leaving external claim adjudication to empirical evidence.
### E. A valid artifact can still be out of scope
A digital signature that authorizes an agent to read documentation in directory A does not authorize it to wipe database tables in directory B. Provenance envelopes bind signatures to an **expected resource scope**, preventing cross-boundary permission escalation.
---
## 3. How it works under the hood
Our architecture is built on a local-first, zero-dependency engine designed to operate across developer workstations, git repositories, and edge deployments without external cloud dependencies.
```
ββββββββββββββββββββββββββ Canonicalize ββββββββββββββββββββββββββ
β Canonical Markdown Doc β ββββββββββββββββββββββ> β UTF-8 NFC + LF Normal β
ββββββββββββββββββββββββββ ββββββββββββββββββββββββββ
β β
β (bytes unchanged) βΌ
β ββββββββββββββββββββββββββ
β β SHA-256 Hash Digest β
β ββββββββββββββββββββββββββ
β β
βΌ βΌ
ββββββββββββββββββββββββββ OpenPGP / Ed25519 ββββββββββββββββββββββββββ
β