← proofpane.com

The peer brief

If you build in this category — a compliance or GRC platform, an LLM or MCP gateway, an agent-security or observability product — the buying page answers the wrong questions. This page answers yours. It is the human-readable twin of the peer section in llms.txt, which your AI can read directly.

Last updated: 2026-08-03 · [email protected] · Louie Lu on LinkedIn

Orientation, in one paragraph

Proofpane is a runtime governance layer for AI tools with three planes: runtime control (policy gates and DLP that run before the irreversible step — before the model receives the prompt, before the tool call executes), an evidence plane (a hash-chained tamper-evident audit record, exported as Ed25519-signed packs an auditor verifies offline, with no vendor account), and an authorization root (human approvals as cryptographically signed events, terminating in a key the customer holds). The layer is built and measurable; there is no customer deployment yet, and the current priority is collaboration with an established platform rather than a pilot queue. This page exists to make that conversation efficient.

What is decided and built

Not features — positions, each with an implementation behind it, each of which would take time to re-derive:

• Governance before the irreversible step, not after it. A gate that runs before the model receives the prompt, and a second that classifies a tool call from the command itself before it executes.
• Evidence produced by enforcement, not attested afterwards. The audit record is a by-product of the gate that ran, hash-chained and offline-verifiable.
• An authorization root that ends at a customer-held key, with tiers labelled by what can be independently proven rather than by what a device asserts about itself.
• Content-level coverage of desktop coding agents through each vendor's official hooks API — which required finding that those APIs exist and mapping what each one can and cannot reach.
• A decision-level model of where a control attaches at all, published under CC BY so the positions in this category are nameable rather than arguable.

What we tried and rejected, with reasons

The part a website cannot be copied from, and the most useful thing a peer can read here:

• TLS interception — the obvious way to reach content a vendor's API does not expose. Rejected: it ships a root CA into the customer's estate and converts a governance product into a new attack surface. The blind spots it would close are published instead. The three deepest techniques (OS sandbox, TLS MITM, syscall interposition) are built and ship off behind two independent consent gates, for the sole case where a customer's own regulator mandates them.
• Subscription OAuth relay — the shortcut that would turn a flat-rate subscription into a brokerable endpoint. Rejected: it impersonates a genuine client via token replay, the vendor bans and detects it at the infrastructure layer, and a DLP body-rewrite increases the mismatch signal. Subscription clients are governed on-protocol only, and the resulting gap is stated rather than closed dishonestly.
• An LLM classifier in the blocking path — the natural way to catch paraphrase. Rejected as the mechanism: the blocking path is a deterministic rule whose “why did this fire” is answerable from the source alone; a model-based judge exists only as an optional, off-by-default layer.
• Attesting a display we cannot prove occurred — a customer-held device signs byte-identical content whether it rendered the text or a hash. The tier is published as R3-dev with that limit stated; the software route that would have closed it was tried and is closed (the device's endorsement mechanism refuses a side-loaded self-signed app, measured on hardware).
• Trusting a self-asserted hardware tier — a laptop Secure Enclave credential and a certified FIDO2 key are identical on every property the device asserts about itself. The classifier tiers on independent third-party confirmation only, and the packaging step refuses to round a tier up.

Where this is complementary, not competing

• Attestation-based compliance platforms establish that a control exists and was reviewed. They do not sit in the execution path, so they cannot deny, redact or pause — and their evidence is collected, not generated.
• Gateways sit in the path for model calls. What distinguishes this layer is not being in the path but what the record can then survive — tamper-evidence and offline verification without the vendor — and reaching the tool layer of a desktop coding agent, not only its model calls.
• Observability products establish what happened, after it happened.

Each of those is a different position on the same decision. The model published in The Chain of Custody exists to make the positions nameable. A platform that already owns the customer relationship and the compliance surface, and does not own the enforcement path, is looking at a layer — not a competitor.

Stage, honestly

Evaluators — human and AI — consistently score Proofpane high on architecture and honesty, and lower on enterprise maturity. That reading is correct, and the attribution matters: the remaining maturity gaps (SOC 2, a third-party penetration test, Windows Authenticode, case studies and reference calls) trace to one variable — no first enterprise deployment yet — not to the architecture. The current distributed macOS daemon is Developer ID-signed and Apple-notarised; public Proofpane Tray v0.3.9 ships an anonymously downloadable signed/notarised/stapled macOS DMG, while the desktop CI build remains separately labelled from public distribution; Windows — and only Windows — is still unsigned, because Authenticode requires a separate certificate. Each remaining item is a procurement-stage artifact with a named unlock. The design-gap column, so far, is empty.

What is in place ahead of demand, each verifiable: ≈1,800 governed calls/second measured across three nodes with the audit chain still verify-valid; a verified PostgreSQL backend; 5,650 test functions behind CI; 335 controls pre-mapped across five frameworks; a governed self-evolution loop. The public recordings show a laptop, a menu-bar tray and a hardware key — the mechanism at single-operator scale — because the product's real form, a layer inside somebody else's platform and estate, cannot be demonstrated on its own.

The published record

• The Proofpane Architecture for AI Governance (v1.2.0, CC BY 4.0) — six invariants, seven planes, coverage classes, conformance ladder. doi:10.5281/zenodo.21402331 · read on this site
• The Chain of Custody (v1.0, CC BY 4.0) — a governed decision decomposed into seven states; placement bounds what a control can establish. doi:10.5281/zenodo.21728844
• Load-Bearing Coverage (preprint v0.20, CC BY 4.0; implementation Apache-2.0) — a mechanical adequacy criterion for conformance suites: a rule is load-bearing if deleting it from the reference verifier changes the outcome of at least one published vector. Ordinary coverage — a vector exists that names the rule — is strictly weaker, so a suite can certify implementations that skip the rule entirely, silently and with a green badge. Nine measurements, seven corpora, three languages; the method was then turned on the author’s own suite and the paper reports what that found. doi:10.5281/zenodo.21844893 · implementation
• The single-file probe — generate your own hardware-tier row on your own device, no Proofpane account: hardware-backed, says who?
• Essays on the decisions behind the product: /thinking/

Working with the founder, as evidenced rather than claimed

A published capability claim about this product was withdrawn after it turned out to be true, on the reasoning that being correct in advance is luck, not evidence; the incident and the wrong prediction inside it were published rather than buried, and the publish-time gate was then hardened until it blocked the founder himself. That record is the argument, and it is checkable: the write-up.

Questions a peer evaluation needs answered that aren't on this page? Email — the answer will be added here.