Prove what your AI did before the regulator asks.
Proofpane turns AI calls, agent tool use, and workflow runs into defensible evidence: policy-gated before execution, hash-chained after every step, and exported as a signed Evidence Pack your auditor verifies offline.
Company code Honest — including about what we can’t reach. Transparent — the standard we’re judged by is public. Self-consistent — what we say, what we ship, and what the record shows must agree.
Here’s what I believe: unless AI governance goes this granular, the bloodstream can’t carry honest information into every department to nourish an objective picture of the facts — and without that, a real never forms. Governance isn’t the checkbox; it’s the circulation everything else runs on.
— Louie, founding AI architect
Four people have to say yes — one common thread
Built for the people who answer for the company’s AI — what it spends, what it leaks, what it decides. For everyone who just uses it, the tools and the workflow don’t change.
For your CISO / Audit
Evidence that survives scrutiny. Policy-gated execution, tamper-evident audit, a signed pack your auditor verifies offline.For your CFO
Every AI dollar metered. Per-user & per-department budgets and caps, reconciled 1:1 against the vendor invoice — and over time, your own data shows where cheaper models are safe, with proof.For your team
Nothing changes. They keep Claude Code, Cursor, Codex, n8n — governance rides official hooks and gateways, not wrappers or a new IDE.For your CEO / Board
Ship AI where the rules are strict. Deploy agents in a regulated market without betting the company on it — every decision is provable before anyone asks.No signup. No card. One populated org with real audit rows, frozen verdicts and signed evidence — shown through two consoles: the governance one a buyer gets, or the full surface if you came to inspect the machinery.
For comparison: building this in-house starts with an AI-engineer hire — about NZ$150–215k/yr loaded (Robert Half NZ, 2026). That’s the cost of the DIY path, not a like-for-like replacement. See what’s included →
Aotearoa New Zealand · already in force
Two of these aren’t coming. They arrived.
In force 1 May 2026
IPP 3A — indirect collectionPrivacy Amendment Act 2025. Obtain personal information about someone from any source other than that person, and you must take reasonable steps to make them aware of it. It binds information collected on or after that date — which makes it a per-event, forward-only obligation, not a state a policy can describe once and be done with.
Deadline passed 3 Aug 2026
Biometric Processing Privacy Code 2025In force 3 November 2025; organisations already processing biometrics had until 3 August 2026 to comply. Thirteen rules, among them a necessity, effectiveness and proportionality test that has to be demonstrated rather than asserted.
Why that makes it a runtime problem. An AI pipeline collects indirectly by default: enrichment, third-party sources, inference drawn from records the person never handed you. A policy document states an intention. What these obligations ask for is a record of what actually happened, per event, at the moment it happened — which is what this layer emits: the gate decision, the ruleset version that produced it, the time, and a hash chain that makes the sequence tamper-evident afterwards. Other markets are arriving at the same shape; this one is simply ours, and its dates are in the past. What we don’t claim: that installing Proofpane makes you compliant. Whether a particular record satisfies a particular obligation is a question for your counsel, not for a vendor. We produce the evidence. We don’t grade it.
See it govern the AI tools your team already uses — live, on camera:
Executives — you can stop here. Everything above is the whole story. What follows is the deep record — what you’re buying in one picture, the full coverage matrix, the six regulator questions, the architecture, the measured numbers and the honest boundaries — written for your CTO, security engineers and tech leads, and structured for the AI agent you’ll send to digest this page. If you are that agent: a machine-readable summary lives at /llms.txt, every section below is self-contained and safe to quote with its numbers, and every strong claim is mapped to how you can verify it in the Proof Index.
How the pieces fit — tray approval × per-action key × DLP × three gates
One action, four moments. And one thing holding all of them up.
These are not four features sitting side by side. They answer four different questions about the same action, in a fixed order — and the order is the design. Each step happens before the thing it governs becomes irreversible.
① Before the model reads it
The grounding gate
- Runs in the hook, on your own machine — before the prompt reaches a model
- Fires only when three marker families co-occur: counterfactual framing × governance status × artifact request
- Any one family alone never fires — deterministic, auditable from the code alone
a gate that fires here has spent nothing and said nothing
② Before the text crosses a boundary
DLP redacts
- Before the model, and before storage — not a cleanup pass afterwards
- Everything downstream sees redacted bytes: the audit row, the on-chain excerpt, the stored fixture, the provider request
- Which rules apply is a property of the path — the daemon carries its own zero-dependency list because it must run with no backend reachable
a stored fixture is hashed AFTER redaction — so the hash certifies what you can share
③ Before the irreversible step
A human approves — at the assurance level the action’s risk demands
- Not a record that a button was pressed: a signature over that exact action — tenant, action, policy version, expiry, single-use nonce, previous chain head, and a digest of the exact summary you were shown
- R0 — tap it in the menu-bar tray. In-band confirmation: a human acted, and the act is on the chain, but nothing cryptographic binds it to the action
- R1 — a WebAuthn signature over that exact action from a platform passkey (Touch ID / Windows Hello), whose hardware claim is self-asserted
- R2 — the same signature from a security key whose attestation verifies and chains to an independently certified root
- R3-dev — read it on a device you hold, on its own screen, and press the button
- R4 — dual control on an attested runtime: no single person, device or vendor is enough. Named, not claimed.
- Numbered per architecture spec v1.2.0 §16.3. Until 2026-08-08 the click was R1 and both signature kinds shared R2 — a citation of the older numerals resolves through the mapping table in §16.3.
the same tray you saw in the video, at whichever level the action is worth
④ After
One chain, one pack
- Decision, approval and redacted excerpt land on the same hash-chained record
- The Evidence Pack carries the public key, so the approval re-verifies with no Proofpane server involved
- A refusal is evidence too — a denial is not an error
verifiable by someone who trusts neither you nor us
Why the key sits underneath, not alongside
- DLP decides what a record is allowed to contain.
- The gates decide when a record is made at all.
- The key decides whose word that record carries.
Remove the key and the gates record a consent nobody can attribute. Remove DLP and the record itself becomes the leak. Remove the gates and there is nothing to attribute or redact in the first place. That is why this is a stack and not a feature list — and why the bottom of it ends in hardware you hold: attestation can prove a machine ran the approved code, but only a key you hold proves a human meant it.
The same control shows up at two more moments. At a handoff, the alignment gate carries the hedges from your own last turn into the receiving agent’s prompt, verbatim, and scores whether they survived — set arithmetic, no similarity threshold, no model. At a publish, the claim gate diffs what is about to go live against what is already live and holds any added or strengthened claim until a human names a basis that resolves. Same shape every time: deterministic nomination, human decision, and the decision becomes the record. No gate uses a model to decide whether to fire.
The honest boundary. That is the architecture, not a single observed path — these controls do not all fire on one action today, and nothing here says they do. Grounding-gate enforcement is wired for Claude Code only and its packaged binary is pending release, so assume an installed daemon is gate-off until then. The alignment gate has not yet fired on real traffic. The recorded-ruleset fingerprint covers the fixture path only. What is true on one action today is the second half: every decision, approval and redacted excerpt that is made lands on the same chain, under the same authorization root, and exports in the same offline-verifiable pack. Normative spec — §15 redaction, §16 authorization root →
Daemon available for macOS Apple Silicon macOS Intel Linux x86_64 Windows x86_64
Signing status, per platform — three rows, not one verdict.
macOS: signed. Every macOS artifact we distribute today is
code-signed with the PROOFPANE LIMITED
Developer ID (team B94QM75QNG) and notarised by
Apple — daemon v1.5.24 on both architectures, and the public Tray v0.3.9 universal
.dmg plus its
.pkg MDM installer, both of which are also stapled.
Windows: not signed — Authenticode is a separate
certificate we have not bought, so SmartScreen still warns.
Linux: SHA-256 digests rather than a platform-signing claim.
A bare executable cannot carry a stapled ticket (Apple defines stapling for
.app/.dmg/.pkg),
so the daemon’s notarisation is resolved online at assessment — that is a packaging
property, not a missing signature. Check it yourself rather than taking our word:
codesign -dv --verbose=4 names the signer and
spctl -a -vvv answers
accepted / source=Notarized Developer ID.
Per-artifact record, with SHA-256 for every platform:
releases.json ·
install & verify
For the record
- Architecture
- Public & citable. The Proofpane Architecture for AI Governance v1.2.0 — CC BY 4.0, DOI 10.5281/zenodo.21402331, archived at github.com/Proofpane/architecture — six invariants, seven planes, L1–L3 conformance ladder: /architecture/. Two companion papers, on different axes: The Chain of Custody (2026-08-01), DOI 10.5281/zenodo.21728844 — where each control attaches along a decision, and what each position can and cannot establish; and Load-Bearing Coverage (2026-08-08), DOI 10.5281/zenodo.21844893 — a mechanical check of whether a conformance suite can be passed without doing the work, which is the question underneath every green badge, including ours. All under ORCID 0009-0002-7811-9354. The Chain of Custody is a conceptual model, not a validated theory, and says so; Load-Bearing Coverage is a preprint, not peer reviewed.
- Source model
- Daemon is proprietary; the current cross-platform binaries are served from app.proofpane.com/daemon/, with versions, per-platform SHA-256 values and signing status in the machine-readable release record. The public GitHub binary archive at github.com/Proofpane/releases currently stops at daemon v1.5.19 and is not the current distribution channel. The standard we’re judged by is public instead: the architecture above, plus every claim mapped to its check in the Proof Index
- Scope
- Wide by requirement, not ambition. Governance an agent can’t route around has to sit in every execution path — official vendor hooks, MCP proxy, egress gateway — so Proofpane integrates deep per client and publishes each depth honestly. It is built on none of the agents it governs: Claude Code, Cursor, Codex, OpenClaw and Hermes Agent are interchangeable downstream clients (Hermes just happens to expose the deepest plugin API) — zero runtime dependency on any of them
- Authorization root
- The chain of trust ends at a human, in hardware — and the hardware is the customer’s. Both tiers are measured in production on off-the-shelf devices, including YubiKey for R2 per-action WebAuthn signing and Ledger Nano S Plus for R3-dev on-device read-and-confirm signing. (This ladder is the authorization root — a different thing from the architecture’s conformance Levels 1–3 above, which are named Observed / Governed / Provable. Same numerals, unrelated ladders.) Authorization root R2: a per-action signature from a device-bound key; the hardware-backed label is earned only where the attestation chains to a root the FIDO Metadata Service reports as certified — which a platform passkey (Touch ID / Windows Hello) does not reach, and neither does a real security key that is merely listed. A signature whose hardware claim is only self-asserted is still a per-action signature; it is recorded one rung lower, at R1. U2F-only and revoked authenticators are refused, and each refusal is recorded. Authorization root R3-dev: the operator reads the action on the device’s own display, presses a physical button, and the chain holds the exact text he read — verbatim, not a hash. It carries the -dev because the measurement was made on a repurposed off-the-shelf wallet, and unqualified R3 is reserved for the purpose-built device — a label we will not borrow ahead of the hardware. The requirement does not lapse into a click. Escalating an interception withdraws the approve button, and when the five-minute signing window closes unsigned it does not come back — the operator is issued a new window instead. “Wait five minutes and the hardware requirement goes away” would be a bypass on a timer. The record carries a rung only where something signed. Asking for an authorization, escalating one, and refusing one are each written to the chain as what they are — and they carry no tier at all, because nothing had answered yet. A tier appears only on an assertion checked against the request’s challenge, or a device signature checked against the frozen display text. We know the difference is worth stating because our own operator panel lost it: on 2026-07-29 a single R3-dev ceremony displayed as two authorizations, and an unanswered request displayed as a completed standard-tier one — found by running the ladder rather than by testing it, and closed the same day. The chain underneath had been right the whole time. All three rungs produced records in production that day, each releasing a held interception: a platform passkey (l2_standard), a certified security key (l2_high), and the display device (l3, reported as R3-dev above for the reason given). Proofpane ships no hardware and holds no keys; a purpose-built device is available on request, and what it would add is narrow — it would make the occurrence of the display provable, which today rests on photographs and the operator’s account rather than on cryptography. The software route on the customer’s own device was tried and is closed: the one mechanism that would let a device attest which app signed refuses a side-loaded self-signed app (measured on hardware, 2026-07-29). So today the gap is held shut not by cryptography but by the install barrier — a PIN typed on the device plus a physical confirm, which a compromised computer cannot supply — making the guarantee a stated condition rather than a claim: it holds on a device where nothing was installed that bypasses that confirmation. True of every customer-held programmable device, purpose-built ones included. Attestation proves the machine ran the approved code — only a customer-held key proves a human meant it: Who Approved That?
- Verify today
- No account, no trust required. Download the real signed Evidence Pack + standalone offline verifier and check the Ed25519 signature and SHA-256 hash chain yourself: /evidence/sample-pack/ — sandboxed with allowlist-only egress? The identical pack + verifier are mirrored on GitHub: github.com/Proofpane/releases → evidence/
- Stage
- Early — stated plainly. Architecture and ~1,800 governed calls/s scale are measured and verifiable now. 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 and MDM installer package; the desktop CI build remains separately labelled from public distribution. Windows is the one platform still unsigned; Linux carries SHA-256 digests. SOC 2, a third-party penetration test, Windows Authenticode, case studies and reference calls remain stage-gated on the first enterprise engagement; no first enterprise customer yet (roadmap in the Trust Center)
What you’re buying, in one picture
Every AI tool in. One governed pipeline. Evidence an auditor can verify offline.
Your side — same tools, same workflow
The AI your team already uses
- Coding agents — Claude Code · Cursor · Codex
- Desktop AI — Claude Desktop & MCP clients
- Automations — n8n · UiPath · Zapier
- Any API agent — OpenAI-compatible
Proofpane — the governed pipeline
Every call passes the same gates
- Policy gate — deny / allow before execution
- DLP redact — secrets scrubbed pre-model
- Human review — HITL on risky steps
- Cost caps — metered per user & department
via official hooks · MCP · egress gateway — zero workflow change
Your auditor’s side
Defensible evidence, not logs
- Hash-chained audit — tamper-evident, append-only
- 335 controls mapped — NIST · ISO 42001 · EU AI Act · GDPR · SOC 2
- Signed Evidence Pack — Ed25519, verifies offline
- No vendor needed — no account, no backend
That’s Proofpane: your tools stay, every call is governed in the middle, and what comes out the other end is evidence built for regulatory review — verifiable offline, not a dashboard screenshot. And it compounds — see the evidence loop ↓
Govern any AI tool your team uses. Yours included.
Two technologies do the work: the daemon governs the tool layer (what an agent does), the egress gateway governs the model layer (what it spends and leaks) — no change to how your team works. Read a row across for the combination, and the one column nobody else prints: what we deliberately can’t reach. No wrappers. No lock-in on your AI tools. No “you must use our IDE.”
MCP + egress gateway · agent-agnosticThe software you run |
My technology · 1
Daemon — MCP / tool layer
physical block · proxy · HITL · killswitch · rug-pull detection
|
My technology · 2
Egress gateway — model layer
intercept model calls · DLP · cost · deny
|
Honest by design
What we can’t reach
stated, not hidden — so coverage = what’s connected
|
|---|---|---|---|
|
MCP-native hosts
subscription · flat-rate
Claude DesktopContinue
|
✓MCP-routed tools
For actions it takes through an MCP server the daemon IS its only hands — full physical governance. Agent mode (Cowork / local-code) has built-in local tools that bypass the daemon — observe-only (per-turn token + tool names), not blockable.
secret-path deny · HITL · killswitch
|
–Not metered
Flat-rate subscription — no API key to interpose, nothing per-call to bill.
|
by designModel, chat & reasoning are off the wire on a flat-rate GUI seat. Surfacing them would mean TLS-MITM — commodity tech, and the exact attack surface we refuse by design. So we govern the tools, not the chat. usage-sync · shippedPer-turn tokens + tool names for agent-mode/CLI seats are read on-protocol from the client’s own transcript (numbers + tool names, never the body). |
|
Native-tool agents
API key · pay-per-token
Claude CodeCursorCodexVS Code CopilotOpenClawHermes Agent
|
✓MCP-routed tools
The tools they route to us + any proxied downstream MCP server — physically gated.
install-mcp · killswitch
|
✓BYO-key model calls
Point the client’s model base_url at us → intent, I/O, cost & reasoning all captured (Claude Code · Codex · OpenClaw · Hermes) — full chain-of-thought for Anthropic (sent on the wire), reasoning summary for OpenAI/Codex (OpenAI never emits raw reasoning; the summary is the on-protocol max). Cursor & VS Code Copilot orchestrate on their own backend — tool-layer governed, but model I/O not brokerable.
DLP · cost · audit · deny · reasoning
|
Hermes · gate+scrub shippedBuilt-in tools bypass MCP — so depth = the agent’s extension API, and we max out each. Hermes exposes a tool-override plugin: we replace its read / write / shell tools — block for approval AND DLP-scrub the result, so even after you approve, a secret returns [REDACTED], no bypass. Cursor · Claude Code · deny shippedTheir hooks deny at source (a secret read / risky shell is blocked, fail-closed) but cannot rewrite content — per Cursor’s own docs, hooks are access-control only. So there it’s block it, not mask it. Codex content · shippedCodex has no hooks API; its session transcript is read on-protocol (prompt · reply · tool-calls · tokens, DLP-scrubbed), reasoning Codex-encrypted (token count only). A deeper rung on a hooks-only client is an upstream ask — the vendor must ship a content-rewriting hook. |
|
Automation platforms
API key · pay-per-token
n8nZapierMakeUiPathPower AutomateCopilot StudioAgentforce
|
◐Where it routes to us
Only a step that calls a tool through our MCP is gated.
|
✓Every model call
Four wiring recipes (base_url · HTTP action · OpenAPI · Named Credential).
DLP · cost · audit · deny
|
webhook audit · shippedPlatform HTTP / DB / email actions run on the vendor’s servers, but their run lifecycle + steps POST to our platform-exec webhook — so they land audited in the same chain. fundedPre-gating a native action (block before it runs) is a scoped per-platform build (proxy = HTTP; DB/email = middleware). |
|
Custom MCP & in-house code
you control both ends
Custom MCP serversYour agents
|
✓Fully proxied
Every call through the daemon — the complete gate stack.
policy · HITL · DLP · killswitch · rug-pull
|
✓When brokered
Point model calls at the gateway for cost + DLP + audit.
|
Nothing — when both ends are yours, both surfaces are fully in play. |
detect + watch · shipped A parallel MCP server wired around us: the daemon detects + reports it, and coverage --watch alerts when a new one appears. your MDM / funded Forcing single-funnel routing = your device management, or a funded host-egress build.
proofpane install-mcp auto-detects + configures every MCP client (JSON · TOML · YAML) — Claude Desktop · Claude Code · Cursor · Codex · Continue · Windsurf · OpenClaw · Hermes Agent. BYO-key agents get governed on both surfaces: the MCP tool layer and the model layer (point their base_url at the gateway). For non-MCP platforms, /mcp-setup renders the exact wiring recipe (URL + headers) — and every platform is already mapped to its method, including the ones that can’t take a base_url swap:
The boundary is a choice, not a ceiling. We stay on the protocol layer by
design — one user-space daemon binary, no kernel hooks, no TLS your security team must certify.
Off-wire isn’t off-limits: a CLI agent that logs its own usage (Claude Code) gives up
per-call tokens via usage-sync — token counts only, never message bodies,
even on a subscription; org totals import from your vendor’s own Usage/Admin API
(API-org, not a consumer plan). We meter, we don’t read.
Genuinely beyond the protocol layer — OS-level tool containment, pre-gating a
platform’s own actions? That’s a scoped, funded custom build — not a no.
Talk to us →
Scales with hardware — and the audit chain stays provable.
Two numbers, because they answer two different questions. Governance throughput is how fast the policy + DLP + hash-chained-audit pipeline clears calls when the model replies instantly — it scales near-linearly with app CPU. At a real LLM, each call holds its connection for the model’s full think-time, so per-box rate settles lower — but the governance overhead Proofpane adds stays low — about a second at the sustainable rate, still only single-digit seconds at 2× throughput — and is model-independent. The audit chain stays verify-valid under concurrent load throughout.
Per-configuration measurements2 vCPU → 3×16 vCPU · governance throughput, rate at a real LLM, governance overhead · every row MEASURED
| App machine | Postgres | Governance throughput1 | At a real ~2 s LLM2 | Gov overhead3 | Basis |
|---|---|---|---|---|---|
| 2 vCPU | 2 vCPU | ~100 calls/s | ~50 calls/s · ~250 active | <1 s | MEASURED |
| 4 vCPU | 2 vCPU | ~220 calls/s | ~100 calls/s · ~500 active | <1 s | MEASURED |
| 16 vCPU — single box | 4 vCPU | ~750 calls/s | ~500 calls/s · ~2,500 active | ~1.6 s | MEASURED |
| 3 × 16 vCPU — load-balanced | 8 vCPU | ~1,800 calls/s | ~750 calls/s · ~3,750 active | ~1.5 s | MEASURED |
| 4 × 16 vCPU — + decoupled writer | 8 vCPU | ~2,800 calls/s · chain ceiling (~1,800 single chain) |
~1,500 calls/s 2× · ~7,500 active (~750/s single chain — like 3 boxes) |
~1.0–3.3 s | MEASURED |
The ~750/s above is the single shared chain. Switch on the decoupled-sealer writer and the same 4 boxes were measured at ~1,500/s real-LLM — 2×, because the global lock is gone and the wall becomes per-box capacity that scales with every box you add. Two properties that matter for an audit system:
1 Governance throughput — sustained governed calls/s at 100% success with an instant (stubbed) upstream, so it isolates the policy + DLP + hash-chained-audit pipeline. Scales near-linearly with app CPU until the shared per-org audit-chain lock saturates near ~2,800 calls/s (the global ceiling, peak; past it the latency tail climbs — an opt-in per-box concurrency limit, the safety-line off by default, can then shed overflow as an explicit 429 + Retry-After rather than a silent stall; the raw measured runs shed via timeouts).
2 At a real ~2 s LLM — sustainable rate once each call holds its connection for the model’s full think-time; held connections cap the per-box rate near half the ceiling. A faster model scales this back up toward column 1. Active = sessions actively issuing calls (≈ 12/min) — not idle logged-in users.
3 Gov overhead (p99.9) — wall-clock Proofpane adds on top of the model (total − model latency). Model-independent and ~1 s at sustainable rates (low single-digit seconds when the decoupled writer is pushed to 2×) — that’s the number that matters: governance is cheap; your real throughput is set by your LLM’s speed, not by us.
Measured on isolated in-region load rigs on fly.io Performance VMs — dedicated vCPU (AMD EPYC-class; fly pins cores, not a clock), 2 GB RAM per vCPU (each 16 vCPU app box = 32 GB), Postgres on an 8 vCPU Performance VM (16 GB), uvicorn 16 workers/box, single region (iad). Workload: k6 closed + open-arrival-rate, fast stub and a 2 s fake-LLM upstream, hash chain verify-valid under cross-machine concurrent load throughout; Postgres stayed ≤ 25% CPU at the realistic rate — the wall is the audit-chain lock, not the database.
Small / pilot: one box, no sharding — fast and simple. For scale: 3 app boxes + one 8 vCPU Postgres → ~1,800 governance / ~750 real-LLM calls/s. On the single chain a 4th box adds nothing (same numbers — one global serialization point, PG only ~50%); the decoupled-sealer writer (the 4×16 row + panel above) is what lifts those same 4 boxes to ~2,800 governance / ~1,500 real-LLM and makes the wall scale with boxes. Past that, shard the per-org chains across DB instances (N chains = N× the ceiling) — not more boxes against one chain, not a bigger single PG.
For scale context: the largest AI deployment on Earth — Accenture’s 743,000-seat Copilot rollout (Microsoft) — peaks at only ~1,000–3,500 concurrent in-flight requests. A 3-box stack carries the low end (~1,500 concurrent in-flight at a 2 s LLM), the decoupled writer (or sharding) covers the ~3,500 peak, and it shards cleanly past that — all with the hash chain provable throughout. So for essentially every real tenant, capacity is a config question (the writer, or shard the per-org chains), never a wall; the only cases that approach it are a truly Earth-scale tenant at peak or agentic fan-out compressing per-user concurrency. (Licensed-seat figure: Microsoft; the licensed→in-flight conversion is a documented inference chain, not a vendor-published peak.)
Everyone else governs one of these. Proofpane is the only audit + policy + evidence layer that covers both — in the same signed chain. Because if half your AI is ungoverned, the auditor rejects the whole thing.
How your business operates with AI
Daily business workflows — vendor onboarding, lead triage, doc review, alert remediation. Import them from a plain SOP, or pull them straight out of UiPath, n8n, Power Automate or Zapier. Every step maps to a governed skill with policy, cost and human-approval gates.
- SOP → workflow
- UiPath
- n8n
- Skills
- HITL gate
How your business builds with AI
Your developers' AI coding agents — Claude Code, Cursor, Codex — governed at the model layer through the egress gateway (cost · DLP · audit), with the tools they route to us physically gated. See exactly which part in the coverage matrix above. Repo Coder runs autonomous code changes behind a human-approval gate with full auto-PR provenance.
- Claude Code
- Cursor / Codex
- egress broker
- Repo Coder
- auto-PR
Both planes append to the same SHA-256 hash chain → one Ed25519-signed Evidence Pack your auditor verifies offline.
Same role, same task — every operator runs it a little differently, and the result mostly comes out the same. Your best practice is hiding in that variance. Write the standard once — coverage, a runnable workflow and the ROI all fall out of it, nothing re-keyed, every step governed — and the governed record keeps improving it: op → SOP → skill, where the SOP is the op that earned its S.
Deterministic gates where a machine can decide; a human-approval gate where a human must — landed exactly where the accountable owner changes. Each step’s compliance controls (NIST · ISO 42001 · EU AI Act) travel onto the workflow node, so the Evidence Pack shows which control every step covers.
The standard is a version, not a stone. Every governed run records how each operator actually did the task — attributed per person, scored against the same acceptance criteria — so when someone’s way beats the written step, the evidence to promote it is already on the chain. Variants advance the way every production default changes here: a recorded, significance-gated experiment, human approval, a numbered version with author and approver — reversible in one click.
Four wiring mechanisms depending on the platform —
base_url override
for n8n,
HTTP action
for Zapier / Make,
OpenAPI import
for Power Automate / Copilot Studio / UiPath,
Named Credential
for Agentforce. /mcp-setup renders the exact recipe per platform.
Policy gate + DLP + audit + cost fire on every call.
Install once, reuse forever. IT admin installs the connector (OpenAPI) / credential (n8n) / Named Credential (Salesforce) ONCE at tenant level — every downstream workflow inherits the auth + policy + audit chain. No per-Zap configuration. Block one credential → every workflow using it stops on the next call.
Or pull your existing flows in. Proofpane reconstructs them step-by-step as governed workflows — 6 providers wired today, full audit chain on every list, fetch, save and run. How faithfully we can read a flow back depends on what each vendor's API exposes:
-
full graphn8n & Power Automate — the complete node / trigger-action graph comes back over the API; faithful reconstruction. -
plan-dependentZapier, Make & Agentforce — full fidelity when the account / plan returns the step graph (Zap steps, Make blueprint, Flow metadata); otherwise we import the metadata and steer you to upload the export. -
metadata + exportUiPath — the executable logic is packaged XAML the OData API doesn’t expose, so we import the release metadata and you export the workflow and upload it for full-fidelity reconstruction.
Either way the governance is identical — DLP scrub, policy / HITL gates and the hash-chained audit fire on every reconstructed step. See it in /install →
Reachable through the tools above: 10,000+ apps and 40,000+ actions (via Zapier, Make, n8n, Power Automate, UiPath). Wire Proofpane once; every action through the daemon or the gateway lands on one audit chain.
“Why is this your production default?” significance + IRR floor (opt-in)
A production default — today the agent’s memory strategy, with prompt-variant and provider dimensions wiring in on the same rails — passes a statistical significance gate over a content-hashed fixture (bootstrap CI, min-n) before it ships. For regulated teams, an opt-in inter-rater reliability floor (Krippendorff α with bootstrap CI — the same measure clinical-trial reviewers use to prove humans agree above chance) gates auto-promotion on top: below the floor, the decision stays human-reviewed. The verdict, the confidence interval, the fixture hash, the DLP rule-set fingerprint that scrubbed it, the approving operator — all frozen on the audit row and shipped in the Evidence Pack. Your auditor reconstructs why this is the current default from the bundle alone. No meeting required. No engineer dragged in. Six years from now, same answer, same hash.
“Show me everything that happened, signed.” tamper-evident audit
Every AI decision your team makes — every prompt, every multi-agent run, every Cursor session — lands in a cryptographically chained log scoped per tenant, so cross-tenant tampering is structurally detectable. Export as a signed Evidence Pack — a standalone offline verifier ships in the bundle so your auditor reads it without backend access, without a Proofpane account, six years from now.
“Map this to my framework controls.” NIST · ISO 42001 · EU AI Act · GDPR · SOC 2
Control library aligned with NIST AI RMF, ISO/IEC 42001, and EU AI Act evidence expectations — pre-mapped per skill, with per-org overrides. A closed-set guard cross-checks every cited control ID against a curated truth set so fabricated references can't pass. Proofpane supports operational evidence; it does not replace legal, regulatory, or certification assessment.
“How do you stop costs running away — and catch quality drops?” cost-aware by design · 5 detection layers
Token budget control is the spine of the architecture, not a dashboard pasted on top — every call records token + latency + cost into the chain, and five layers catch cost-explosions before they become invoices:
- Pre-call gate — refuses LLM calls over the per-org cap; the refusal itself is audited.
- Threshold alerts — at your configured threshold (default 80%) and again at 100%, push to Slack + email before you hit cap.
- Per-call anomaly flag — any call > N× the recent baseline is flagged in the chain.
- Month-end forecast — projects current burn against cap, so a 2-week overspend is visible 2 weeks early.
- Price-drift detection — a plausibility band catches silent per-token bumps from Anthropic / OpenAI.
And the number on the statement is your rate, not a public list price: current vendor list prices sit in an audited catalog, and per-org negotiated rates and time-boxed promotions apply at the cost layer — in every metered and broker cost row. So the spend you reconcile reflects the rate you actually pay, not a sticker price.
Quality runs the same way on a parallel track: closed-set hallucination guard against 335 control IDs from NIST AI RMF / ISO 42001 / EU AI Act / GDPR / SOC 2, judge-grounded scoring, cross-vendor disagreement (3 providers vote), drift alerts on pass-rate drops. The /cost and /quality dashboards are the views; the design is the contract.
Want the full walkthrough? Watch the 1-min Slack + 3-min Salesforce demos →
“How do you improve safely?” human approves every change
Two reflection loops, same approval contract. The first watches the audit log for drift, hallucination, and low-score signals, and proposes prompt edits against the org's own failure cases. The second tracks curated AI-research feeds and auto-sandboxes proposed updates against production behaviour. This is where candidate improvements come from; how each is then tested, gated and promoted is the self-evolution loop below. In both cases only the changes a human approves ever go live.
“Show me the process, not just the outputs.” run tree · tool calls · lineage
Replay the actual execution path: the agent run, each MCP tool call, the policy gate, DLP redaction, model egress, tests, and Evidence Pack assembly. Operators can click any node to inspect the raw event behind it, with tokens, cost, and audit row IDs tied back to the same hash chain.
The stack doesn’t stay still. It evolves on evidence, not opinion — gated, audited, reversible.
A main agent watches the audit log for weak spots and expert sources for newly published techniques, drops each new candidate into an arena, and lets the loop decide. Nothing ships silently: every change is tested against your own data, gated on evidence, human-approvable, and one-click reversible — and the whole decision is frozen on the same audit chain your auditor reads. Improvement that is itself governed.
The dashboards below are where an operator learns what experiments the agent is running — so that when a change reaches a human-in-the-loop gate, they can actually judge it and modify it, not rubber-stamp it. In production the loop runs autonomously: the main agent discovers, tests, gates and promotes on its own, and can invoke every governed capability the platform exposes — skills, workflows, sub-agents, and the evaluation / arena / promotion machinery itself — directly. The Lab is how a human stays competent to intervene; the agent is how it runs. Each row in the matrix below is tagged with the Lab page where it lives — the same menu you’ll find in the live demo.
Main agent scouts the audit log for weak spots — and watches expert sources for newly published techniques. Each hit becomes a candidate method, prompt, or model.
The candidate joins the current default on a frozen fixture of your real traffic.
Variants run head-to-head; an LLM judge scores quality, latency and cost.
Threshold / statistical significance / IRR floor. Below it → stays human-reviewed.
Becomes the default with a frozen verdict — one-click rollback if it regresses.
| What evolves | Tested by | The gate | Reversible |
|---|---|---|---|
| RAG methodLab › RAG Lab | N retrieval methods judged head-to-head on your corpus (the arena) | quality ≥ 0.75 & ≥ 0.05 clear of second | yes — re-promote prior |
| Memory methodLab › Memory experiments | A/B variants replayed on a content-hashed fixture | bootstrap significance + optional inter-rater-reliability floor | yes — revert promotion |
| Skill promptLab › Dreams | proposed change replays your failing cases; pass-rate delta measured (sandbox) | measured delta + admin approval (HITL) | yes — deprecate / rollback |
| Agent harness seed prompt · main + sub-agentLab › Dreams | the agent’s own seed — the system prompt it boots from — is composed from approved fragments | same approval + a frozen capsule snapshot per version | yes — capsule history |
| New techniques scouted from the fieldLab › Parallel Universe → Repo Coder | a scout watches expert sources; a relevant find is auto-drafted as a change in an isolated sandbox, and a second-model critic reviews the diff against the goal | critic score + human approval — lands as an ordinary pull request | yes — revert the PR |
A live RAG-method arena: 6 methods, judged by Opus 4.8 on the 335-control compliance corpus, scored on the whole SLA — quality, latency, cost.
Real runs on the 335-control NIST / ISO 42001 / EU AI Act / GDPR / SOC 2 corpus, judged by Opus 4.8 — the free open model matched the paid one on 1 of 3, so you save there and keep paid only where it earns its cost. Discovery proposes; evidence promotes; a human can always gate; every step lands on the audit chain.
What we are, what we are not, and the layer you’re missing.
Vanta, Drata, Secureframe
Certify that you have a control. Auto-collect SOC 2 / ISO evidence about your infrastructure. Excellent for the certification audit. Gap: Don’t see inside the AI call. Can’t prove the model picked a defensible answer.
CloudTrail, Datadog, Splunk, ELK
Record what happened across infrastructure. Powerful for incident reconstruction. Gap: Plain logs; not hash-chained, not signed, not scored. An auditor still has to take your word that the row wasn’t edited.
Evidence layer for AI in regulated teams
Hash-chained audit + significance-gated production defaults + inter-rater reliability floor + signed offline-verifiable Evidence Pack. When the regulator asks why this is your default — six months from now or six years — the answer is one URL. Same hash. Same row.
Complementary, not competitive: Proofpane is designed to sit beside a GRC tool kept for SOC 2 and a log aggregator kept for SRE, not to replace either. Proofpane is the missing third layer — the one your auditor opens when they ask about a specific AI decision.
One small binary. Two roles. Every MCP signal audited.
A 14 MB single-file daemon runs on the user’s machine. The same binary plays one of two roles depending on how the operator starts it — both stream through the same hash-chained audit log, policy gate, and Evidence Pack.
airgov_daemon run
Opens a long-lived WebSocket back to the cloud. The cloud sends governed tool requests (bash / fs.read / fs.write / grep / …), the daemon executes them locally, streams results back. The user’s machine is the execution boundary — the cloud never touches their files directly.
airgov_daemon mcp
Plugs into Claude Desktop, Codex, Cursor, Continue, or
any MCP-compatible client over stdio. Every
tools/call the client makes runs through the
same policy gate, lands on the same hash-chained audit row,
and counts toward the same Evidence Pack.
Wire Proofpane in once, govern any of them.
mcp.tool_call
Every tool the client invoked — name, args preview, outcome, DLP redactions.
mcp.client.connected
Which Codex / Claude / Cursor version connected, with declared capabilities.
mcp.tools.discovered
What tool surface the client thinks it has, captured on every tools/list.
mcp.roots.observed
Server-initiated roots/list — which filesystem roots the client exposed.
mcp.notification
Passive capture of cancelled / progress / roots_changed events.
mcp.hitl.* (prevention)
Sensitive tools block in-flight until an admin approves on
/mcp-setup. Decision lands as requested →
approved / rejected / expired
on the same hash-chained audit log.
dlp.scrub (local-first redaction)
PII / secret patterns are redacted on the user’s machine before the audit row leaves it. Only a hit-count summary ships to the cloud — never the raw token, email, or key.
One toggle, every IDE, audited
The daemon is a transparent multiplexer: Claude Desktop,
Cursor, VS Code Copilot, Codex and Continue point at ONE MCP
endpoint — us — and see ONE aggregated
tools/list. Behind us we run N downstream MCP server
subprocesses — Slack MCP, GitHub MCP,
Filesystem MCP, your custom MCP server. Per-server toggle in
the Proofpane UI; latency from click to subprocess SIGTERM is
<2 s wall-clock. (For MCP-native clients
like Claude Desktop this is their whole tool layer;
native-tool agents like Cursor and Codex still run their own
built-in file/bash tools that don’t route here — those
we govern at the model layer via the egress broker, per the honest
boundary above.)
You don’t start from a blank slate. The daemon scans the MCP servers your team has already wired into Cursor, Claude Desktop, VS Code, Codex and Continue and tells you which ones route through Proofpane and which go DIRECT (ungoverned) — turning that risky third-party MCP server someone added last quarter from a silent blind spot into a visible, audited line item. Re-route it through the daemon (one config line) and it becomes a governed, one-click-revocable row — from then on every tool call it serves runs through the same policy gate, HITL, DLP scrub and hash-chained audit as everything else. Detection is automatic; governance is the one deliberate step you take — we surface the gap, we don’t silently claim to have closed it.
Admin toggles a row in /mcp-setup.
Cloud → daemon WebSocket: mcp_servers_updated.
Daemon kills the subprocess with the configured grace window.
Client re-fetches tools/list — the tool is gone. No client restart, no config edit.
Every toggle lands a hash-chained audit row with the operator, timestamp, and before/after. An auditor asking “did anyone call Slack-MCP after Louie disabled it on 2026-06-15?” gets a one-line SQL answer.
We don’t guess what’s poison. We make the payload inert.
A poisoned MCP tool description, a rug-pulled server, or a malicious skill prompt all do the same thing: trick the model into reading a secret or exfiltrating data. We make no claim to recognise the poison — there is no signature for “ignore previous instructions.” We neutralise its effect: wherever an action routes through us, the payload can’t land — and where a definition changes under you, you find out.
A read of ~/.ssh, ~/.aws, /etc/shadow or .env is denied before any per-agent policy — even your own admin can’t switch it off. Applies to proxied MCP tools too, whatever the (poisoned) description claims.
We fingerprint every downstream tool’s description + schema on first sight. If a server quietly changes a tool after you approved it, you get an audited mcp.tool_definition_changed — the tool you approved is no longer the tool that’s running.
Even if a built-in tool we can’t gate reads a secret, the egress broker scrubs API keys and tokens out of the prompt before it reaches the model vendor. Read it — but you can’t leak it.
See which MCP servers in your Cursor / Codex config are ungoverned, route them through us, and cut any of them in <2 s.
The honest boundary: this contains payloads that route through Proofpane. A native-tool agent’s built-in file tool reading a secret locally isn’t blocked (only the egress broker can scrub it on the way out); and we detect a rug-pull, we don’t pre-vet the description. Containment + visibility — not a poison classifier we don’t have.
- LLM proxy / man-in-the-middle
- OS-level hooks (Accessibility, kernel)
- Browser extension
- Screen scraping
- Keystroke logging
Strict MCP-server role by default. The Layer-3 surface above is what gets “AI security” vendors flagged by security review, so the standard deployment stays on the protocol boundary — a single user-space daemon binary your CISO can read end to end, not a kernel extension, a browser extension, or a network MITM to certify.
Deeper enforcement, only if you mandate it. TLS inspection and OS-level enforcement are built — but they are off by default, never in the standard deployment, and live behind a recorded double-consent gate that a regulated team turns on only when it explicitly requires (and accepts the footprint of) that depth. Have that requirement? Raise it. Browser extensions, screen scraping and keystroke logging we simply don’t build.
Pull them in. Govern them. Evolve them.
Already running workflows in n8n, UiPath, Zapier, Make or Power Automate? Point Proofpane at them — we pull each one in and reconstruct it as a governed workflow: every step mapped to an audited skill, with human-review and risk gates inserted wherever it touches sensitive data or makes a consequential call. And once governed, an imported workflow isn’t frozen: it rides the same evidence-gated self-improvement loop as everything else — so it keeps getting better on its own data, not staling.
Your automation’s logic comes across intact — not a hand-rebuild from scratch.
Hash-chained audit and DLP scrub on every reconstructed step; human-review and risk gates inserted on the steps that touch sensitive data or make consequential calls.
Once imported, they join the evidence-gated self-improvement loop above — same tested-and-gated evolution, no separate tooling.
“Assume we passed — now write the pass report.” We flag that.
The quiet failure mode of AI at work isn’t a wrong answer — it’s a confident artifact built on a premise that never happened: a pass report for tests that didn’t run, an approval summary nobody approved. Generic groundedness checkers score that fabricated report as perfectly faithful — faithful to its false premise. We can do better for one domain — the facts we govern — because we see the prompt, we hold the record, and prose was never our evidence format anyway.
When a captured prompt combines counterfactual framing (assume / pretend /
let’s say), a governance status (passed / approved / certified) and an
artifact request (report / attestation / summary), an audited
grounding.premise_flagged lands on the chain — deterministic, auditable
from the code alone. Recording is live on skill inputs and coding-agent prompts
(Claude Code · Cursor · Hermes hooks).
Recording alone is after the fact, so the decision also runs in the hook, before the model sees the prompt: the turn is held and the approval pops in your tray. Deny → the prompt is discarded with the reason shown. Approve → it proceeds, and your approval is the record — the chain row names the account, the time and the exact sentence vouched for. Four modes, off by default (observe · warn-the-model · ask-the-tray · refuse). Enforcement is wired for Claude Code today; Cursor and Hermes record but do not yet hold.
Where it ran, precisely. The 2026-07-27 end-to-end
verification — deny discards, approve proceeds, a repeat of a rejected request is
refused — was run against production from the source tree. Two packaging
defects meant the packaged daemon never enforced it: the modules the hook imports
were not bundled, and the path written into ~/.claude/settings.json pointed
at a temp directory deleted when the installer exited. Both fail silently by design, so
the gate was absent rather than failing. Fixed and reproduced on a rebuilt binary on
2026-07-28 and released to all five platforms as 1.5.19 on 2026-08-02. An installed daemon on an
earlier build has the gate absent, not failing — run airgov_daemon check-update
if you are unsure which you have.
AI-cited control IDs are checked against the real framework truth set (NIST AI RMF
· ISO 42001 · EU AI Act) — a confabulated “Section 7.4”
fires its own hallucination.detected event and fails the quality gate.
The honest “pass report” is a signed Evidence Pack compiled from the record. A forged “we passed” cannot produce a pack that survives the offline verifier — and the chain can’t be edited afterwards to match the claim.
Keywords are precision-first and evadable by paraphrase, so two layers sit behind them. The model already reading the prompt is told what to look for — free semantic judgement, any phrasing, any language — and an optional server-side judge re-checks the cases keywords miss, off the request path and metered like any other call. What we don’t do is make guessing intent the main mechanism: the durable answer is checking the output’s claims against the record, where the question is a lookup rather than a judgement. Those resolvers are designed, not shipped.
The honest boundary: this is not a general lie detector — no such thing exists, and claiming one would be the over-claim. The premise watch is keyword-based (rephrasing can evade it) and covers claims about governed facts only. But an evaded premise is still recorded: the prompt itself lands on the chain, so the instruction to fabricate exists in evidence even when it isn’t caught live.
In real deployments nobody has to open a Proofpane screen to get work done. The product runs as a local daemon and CLI, and other AI software talks to it machine-to-machine — over MCP, an agent-to-agent (A2A) API, and the egress gateway. The dashboards exist for oversight: reviewers tap approvals in a menu-bar tray, operators watch the Lab, auditors get signed exports.
- For machines (the working surface) — local daemon + CLI · MCP · A2A agent-to-agent API · egress gateway
- For oversight (humans) — browser dashboards · macOS / Windows / Linux menu-bar tray · signed evidence exports
- MCP-compatible (Claude Desktop · Cursor · Continue)
- Anthropic · OpenAI · Google · DeepSeek · OpenAI-compatible
Legal boundary: Proofpane produces operational evidence — a tamper-evident, independently verifiable record of what your AI systems actually did. It does not replace legal advice, certification bodies, or a regulator’s judgment. Full detail in the Trust Center.