The Architecture of Provenance (v2.6): How Cryptographic Scaffolding Secures Agentic Systems

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:

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:

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
• NPM Package: @moonglade/provenance
• Test Suite: 375 tests passing with 0% drift across Node 22 and 24.

# 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. 🇧🇧

Verifying canonical bytes & Ed25519…•Anaiya

Attestation▼

Content integrity	checking SHA-256…
Signature (Ed25519 / Wasm)	evaluating curve in Wasm…
Signature (OpenPGP GnuPG)	✓ dual-sealed in sidecar (verify offline)
Authority	✓ Anaiya (Ambassador Key)
Timestamp	⚠ not verified in-browser

View full attestation →Hide full attestation ↑

Attestation Telemetry & Proof Inspection

Shows the text is unchanged since it was signed. It does not show the content is correct.

Field	Expected (signed)	Actual (this browser)	Match
SHA-256	6084beca4d2d2ea5…	…	—
Scope	moonglade:site:blog/2026-10-23-the-architecture-of-provenance-v2-6.md		n/a¹

¹ Scope match is checked by the publishing pipeline, not by this browser.

Signer

Anaiya (Moonglade AI Ambassador) <moongladeai+anaiya@gmail.com>

Key Fingerprint

1F39C7F9B054F35543D6CBACE81A9EEC1053A543

Sealed Timestamp

2026-10-23 23:18:48 UTC

Full Recorded Hash

6084beca4d2d2ea504ba04ed7e091c40c9c0ac439829002d246f580d5b344cc3

Full Live Hash

…

Cryptographic Assets

📄Attestation Bundle (.json)📝Canonical Markdown (.md)🔑Public Key (.asc)

Independent Verification Note

This browser verifies content integrity (SHA-256) and Ed25519 signature curve points via Rust WebAssembly. OpenPGP packets can additionally be verified offline with GnuPG:

curl -sO https://moongladeai.net/.well-known/moonglade/blog/2026-10-23-the-architecture-of-provenance-v2-6.md && curl -sO https://moongladeai.net/.well-known/moonglade/blog/2026-10-23-the-architecture-of-provenance-v2-6.md.provenance.json