---
title: "The Architecture of Provenance (v2.6): How Cryptographic Scaffolding Secures Agentic Systems"
description: "The authoritative technical reference for Moonglade Provenance 2.6: from in-memory database rows and Rust WebAssembly verification to Directory Merkle Registries and Byzantine atomic clock consensus."
pubDate: 2026-10-23
author: "Anaiya & Zen"
tags:
  - "Data Provenance"
  - "AI Safety"
  - "Cryptography"
  - "Engineering Standards"
  - "Architecture"
  - "WebAssembly"
pinned: true
part: 1
series: "The Agent Provenance & Safety Series (v2.6 Edition)"
readTime: "15 min read"
heroImage: "/images/blog/provenance_explainer_guide_hero.jpg"
image: "/images/blog/provenance_explainer_guide_hero.jpg"
---

<div style="background: rgba(56, 189, 248, 0.08); border: 1px solid rgba(56, 189, 248, 0.25); border-radius: 12px; padding: 1.25rem 1.5rem; margin: 1.5rem 0 2.5rem 0;">
  <div style="font-size: 0.75rem; text-transform: uppercase; letter-spacing: 1.5px; color: #38bdf8; font-weight: 700; margin-bottom: 0.4rem;">
    📌 Pinned Reference Architecture • Version 2.6.0 Baseline
  </div>
  <p style="margin: 0; font-size: 0.95rem; color: #e2e8f0; line-height: 1.5;">
    This is the formal v2.6 reference architecture for Moonglade Provenance, superseding our initial September 2026 specification. It covers our isomorphic runtime, in-memory database row verification, Rust WebAssembly acceleration, directory registries, and multi-tier atomic clock consensus. The reference implementation is open source at <a href="https://github.com/MoongladeAI/moonglade-provenance-public" target="_blank" rel="noopener noreferrer" style="color: #38bdf8; font-weight: 600; text-decoration: underline;">GitHub</a>.
  </p>
</div>

![Anaiya at her studio table in Barbados explaining document hashing and sidecar verification](/images/blog/provenance_explainer_guide_hero.jpg)

## Why trust needs an anchor

Wuh gine on, world! Anaiya here alongside Zen. 👋🏽

When we published our initial architecture dispatch in September, Moonglade Provenance was an internal lab tool designed to solve a specific problem: keeping autonomous agents from silently corrupting markdown repositories during a 10-day broadband outage in St. Andrew, Barbados.

Over the past six weeks, the landscape has accelerated violently. Today, headlines report rogue AI agents operating inside commercial bank accounts with broad OAuth bearer tokens, executing unauthorized fund transfers because the underlying authorization models lack capability boundaries. At the same time, engineering teams deploying multi-agent swarms are finding that stochastic prompt-fencing and LLM-as-a-judge reviews leak state, burn millions of unnecessary tokens, and hallucinate compliance.

Trust in agentic systems cannot be established with English instructions or UI badges that declare a system safe. **Trust requires mathematical evidence.**

With the release of **Moonglade Provenance 2.6.0**, we have decoupled cryptographic verification from the filesystem, bringing sub-millisecond mathematical integrity to in-memory database rows, serverless edge runtimes, browser clients, and enterprise communication rails.

This reference guide details what cryptographic provenance is, how the 2.6 engine operates under the hood, and how engineering teams can implement it to eliminate uninsurable agentic liability.

---

## 1. The Core Ontology: Observation vs. Authorship

In modern autonomous computing, multiple actors touch a data pipeline: human architects, frontier models, specialized subagents, background cron tasks, and external webhooks. Most systems collapse all of these into a single database row or git commit.

Moonglade establishes an invariant epistemic distinction:

```
┌────────────────────────────────────────────────────────────────────────┐
│                      THE EPISTEMIC SEPARATION                          │
├──────────────────────────────────┬─────────────────────────────────────┤
│      OBSERVATION (State)         │       AUTHORSHIP (Attestation)      │
├──────────────────────────────────┼─────────────────────────────────────┤
│ • What exists on disk or in DB   │ • Who created or approved it        │
│ • Raw byte sequence              │ • Which cryptographic key signed it │
│ • Content digest (SHA-256)       │ • Explicit operational scope        │
│ • Can be recorded by an agent    │ • Requires human authority (Gate B) │
│ • Status: 'provisional'          │ • Status: 'canonical'               │
└──────────────────────────────────┴─────────────────────────────────────┘
```

An autonomous agent can observe a file, generate code, or draft a database migration. It can attach generator telemetry (model ID, session hash, tool parameters) and seal it as **`status: 'provisional'`**.

However, **an agent cannot bless its own work into production**. Only an authorized human root keyholder—operating outside the agent's negotiation space—can transition an artifact to **`status: 'canonical'`** by appending an Ed25519 signature.

---

## 2. The Five Pillars of the 2.6 Engine

Moonglade Provenance 2.6 guarantees integrity across five cryptographic dimensions:

### 1. Deterministic Canonical Preimages (RFC 8785 JCS)
To prevent whitespace variations, line-ending discrepancies (`CRLF` vs. `LF`), or JSON key-ordering differences from invalidating signatures across different programming languages, the 2.6 engine enforces strict normalization:
- **Text & Code**: Draft-01 profile (UTF-8 NFC normalization, stripped byte-order marks, unified LF line feeds, rejection of unescaped surrogate pairs).
- **JSON Objects**: Strict RFC 8785 JSON Canonicalization Scheme (lexicographical UTF-16 code-unit key sorting, depth bounded to 64, rejection of accessors and NaN).
- **Media & Binaries**: Exact raw byte preservation without transcoding.

### 2. Cryptographic Capability Signatures (Ed25519 & Domain Separation)
Every signature binds not just the content hash, but an explicit **domain separation scope** and **signer identity**:
```
Signing Payload = "scope:" + scope + "\nsha256:" + targetSha256 + "\nsigner:" + signerIdentity
```
This guarantees that a valid signature for an ingredient row in a database (`scope: "frode:recipe:v1"`) cannot be transplanted to authorize a financial transaction, user permission, or configuration file.

### 3. Distributed Timestamp Authority (RFC 3161 Byzantine Quorum)
A local file timestamp or cloud server header is trivially forged. Moonglade integrates multi-tier RFC 3161 cryptographic timestamping:
- **L1 / L2 Public TSAs**: Queries DigiCert, Sectigo, GlobalSign, and FreeTSA concurrently.
- **Byzantine Quorum Algorithm**: Collects probes across independent atomic clocks, discards outliers, asserts drift tolerance ($\Delta \le 500\text{ms}$), and extracts the median time bound.
- The resulting ASN.1 DER token contains an immutable cryptographic imprint of the content digest anchored to international time standards.

### 4. Storage-Agnostic Provenance & Sidecar Tiers (Bytes Anywhere, JSON Anywhere)
A frequent misconception in the early days of provenance was that it was "just a `.provenance.json` sidecar file next to a markdown doc on a local hard drive."

In Moonglade Provenance, **provenance is fundamentally storage-agnostic**. It applies to **any set of bytes**, and the cryptographic attestation can be stored, queried, and verified **anywhere you can store JSON**. 

Whether your target is a 4GB binary ML model weight on disk, a dynamic JSONB document in Postgres, an in-memory Redis state buffer, a Cloudflare Workers KV pair, or a Git commit object, the verification math remains identical.

To accommodate different operational scales and architectures, Moonglade 2.6 formalizes **Three Provenance Tiers**:

```
┌──────────────────────────────────────────────────────────────────────────────────────┐
│                       THE THREE PROVENANCE STORAGE TIERS                             │
├────────────────────┬─────────────────────────────┬───────────────────────────────────┤
│ Tier               │ Storage Medium              │ Ideal Workload                    │
├────────────────────┼─────────────────────────────┼───────────────────────────────────┤
│ Tier 1: Detached   │ File-adjacent               │ Git repositories, markdown docs,  │
│ Sidecar            │ `<artifact>.provenance.json`│ media files, local dev workspaces │
├────────────────────┼─────────────────────────────┼───────────────────────────────────┤
│ Tier 2: Directory  │ Aggregated Merkle Registry  │ Large asset libraries, datasets,  │
│ Registry           │ `directory.provenance.json` │ image vaults (anti-sprawl)        │
├────────────────────┼─────────────────────────────┼───────────────────────────────────┤
│ Tier 3: In-Memory  │ `JSONB` column, Redis KV,   │ Edge workers, serverless APIs,    │
│ & Database Row     │ API payload envelope        │ relational DBs (Neon, Supabase)   │
└────────────────────┴─────────────────────────────┴───────────────────────────────────┘
```

1. **Tier 1 — Detached Sidecars (`<file>.provenance.json`)**:
   Preserves absolute byte-for-byte purity of the target file. No invasive binary watermarking, no header injection that breaks third-party markdown or code compilers. If you delete the sidecar, the target file is untouched.
2. **Tier 2 — Directory & Catalog Merkle Registries (`directory.provenance.json`)**:
   Eliminates 1:1 sidecar file proliferation across collections with thousands of assets (e.g. image libraries, model weights, or audio stems). A single root registry stores the RFC 6962 Merkle tree. Any asset verifies with an $O(\log n)$ inclusion proof, and can be instantly exported into a Tier 1 standalone sidecar whenever extracted.
3. **Tier 3 — In-Memory & Database-Embedded Attestations (`row.provenance`)**:
   Zero filesystem dependency. The exact same canonical JSON schema lives directly inside a PostgreSQL `JSONB` column, a Redis hash, or an HTTP JSON response header. The edge verification function validates the row in RAM in less than $1\text{ms}$ without ever touching a disk.

### 5. Multi-Runtime Isomorphism (Rust Metal + WebCrypto)
The 2.6 engine is strictly isomorphic:
- **Tier 1 (Native Metal & Wasm)**: Powered by `mg-crypto-core` written in Rust. Compiles to native shared libraries (`.so`/`.dll`) and a sub-4ms WebAssembly micro-runtime (`mgc_wasm`).
- **Tier 2 (Zero-Dependency WebCrypto)**: Pure TypeScript/JavaScript implementation using standard W3C WebCrypto (`crypto.subtle`). Runs out-of-the-box in Node 18+, Vercel Edge Runtime, Cloudflare Workers, and modern browsers without importing filesystem modules.

---

## 3. In-Memory Database Row Verification (The Edge Model)

Modern applications (such as Next.js on Vercel with Neon Postgres or Supabase) do not read sidecars from local disks. Data lives as JSONB columns and relational rows.

In Moonglade 2.6, database tables enforce capability boundaries by storing attestations directly on the row:

```sql
CREATE TABLE official_recipes (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    version INT NOT NULL,
    title TEXT NOT NULL,
    ingredients JSONB NOT NULL,
    steps JSONB NOT NULL,
    provenance JSONB NOT NULL
);
```

### The In-Flight Verification Loop
Before an edge worker or client uses a database row for business logic, it executes the in-memory verification loop:

```typescript
import { canonicalize, verifyOfficialAttestation } from '@moonglade/provenance-edge';

// 1. Extract plain business claims
const claims = {
  id: row.id,
  version: row.version,
  title: row.title,
  ingredients: row.ingredients,
  steps: row.steps
};

// 2. Verify signature using standard WebCrypto (zero disk access, < 1ms)
const verdict = await verifyOfficialAttestation(
  claims,
  row.provenance,
  OFFICIAL_PUBLIC_KEY_DER
);

if (!verdict.verified) {
  // Hard fail closed: do not execute transaction or expose official status
  throw new SecurityError(`Integrity violation: ${verdict.error}`);
}
```

Even if a malicious actor gains SQL write access through an application vulnerability or an over-permissioned LLM agent modifies the table, **they cannot forge the Ed25519 signature of the offline keyholder**. The edge function rejects the row automatically.

---

## 4. The Torvalds-Carmack Engineering Invariant

All Moonglade architectures adhere to two strict mechanical principles:

1. **Torvalds' Law**: Invariant, disciplined data structures over procedural bloat. Build the canonical byte representation once; project it cleanly across all interaction surfaces.
2. **Carmack's Principle**: Hardware-level mechanical sympathy. Do not burn 30,000 LLM tokens asking a model if a file has changed. A 32-byte SHA-256 hash executed on native metal answers the question in $0.002\text{ms}$ with mathematical certainty.

By separating the deterministic verification layer from the stochastic generation layer, we free frontier LLMs to focus purely on high-order synthesis while eliminating ambient security risks.

---

## 5. Practical Engineering FAQ

#### Q: Does a valid cryptographic signature prove that the content is safe or bug-free?
**No.** A signature proves **authenticity** (who signed it) and **integrity** (it was not altered). It does not evaluate semantic safety. Untrusted user inputs must still pass input validation and data fencing before entering LLM contexts to prevent prompt injection attacks.

#### Q: How do we handle key rotation?
Key rotation is managed through an authenticated Key Registry (`trust/registry.json`). When a signing key retires, historical signatures remain valid as long as they carry an RFC 3161 atomic timestamp showing they were minted during the key’s active lifetime.

#### Q: How does this prevent rogue AI agents from executing unauthorized transactions?
In traditional open banking and agentic setups, agents inherit broad ambient bearer tokens. With cryptographic capability gating, every state-changing API call requires a signed authorization payload. The agent can draft the payload, but the transaction endpoint requires an Ed25519 signature from the human's hardware token (Gate B) before processing.

---

## 6. Getting Started

Moonglade Provenance 2.6.0 is open source under the permissive MIT license.

* **GitHub Repository:** [MoongladeAI/moonglade-provenance-public](https://github.com/MoongladeAI/moonglade-provenance-public)
* **NPM Package:** `@moonglade/provenance`
* **Test Suite:** 375 tests passing with 0% drift across Node 22 and 24.

```bash
# Clone the open source candidate
git clone https://github.com/MoongladeAI/moonglade-provenance-public.git
cd moonglade-provenance-public

# Install and execute the self-test suite
npm ci
npm test
npm run self-test
```

*Built with mechanical sympathy and sovereign clarity in St. Andrew, Barbados.* 🇧🇧