FireProof is an acceptance layer that runs inside a system of record. It verifies an AI-issued Authority against a locally pinned trust manifest, checks the current record state inside the database transaction, commits atomically, and writes a signed evidence bundle that can be verified later without calling any external service.
AI agents are starting to write to ERP systems. The governance and audit tooling built around that hasn't caught up to the actual write path.
An AI agent proposes replacing a supplier's payment destination. An upstream authority signed the request. A governance platform approved it. There's an entry in a vendor audit log.
Six months later the change is disputed. The agent platform is gone. The vendor log is inaccessible. The question is simple: did your ERP actually verify that request, check the live record state, and commit atomically — and can you prove it?
With current tooling, no. Governance tools run before execution. Evidence systems record after. The database transaction itself — the actual acceptance moment — produces nothing independently verifiable.
It's not a governance platform, an agent framework, or a logging system. It's a specific layer that none of those cover.
The receiver owns its own trust root, manifest pin, current-state check, write transaction, and Fulfillment signing key. An upstream Authority says "this change is authorized." FireProof says "and here is proof that this receiver verified it, matched live state, and committed — or didn't."
All of this runs reproducibly on a clean Ubuntu VM at a fixed commit.
42/42 integration tests passed.
Bare request, tampered payload, replay, stale version, expired authority — each rejected without touching the supplier record.
pip install fireproof-verifier. No receiver credentials, no network, no private key. Verifies DSSE, JCS canonicalization, Ed25519 signatures, trust chain, and commitment linkage.
This proves the receiver's durable acceptance decision and what it committed. It does not prove a bank transfer completed, a legal obligation was met, or any effect outside the receiver's own transaction.
The protocol spec and the Python verifier are Apache 2.0.
Any third party can verify a FireProof bundle with pip install fireproof-verifier — no private runtime needed.
The receiver runtimes and Go reviewer are separate.
| Component | What it is | Status |
|---|---|---|
| fireproof-protocol | R2 v0.1 profile spec — schemas, canonicalization rules, safe test vectors, conformance fixtures | Open — Apache 2.0 |
| fireproof-verifier | Python offline verifier — DSSE, JCS, Ed25519, trust chain, commitment linkage. pip install fireproof-verifier |
Open — Apache 2.0 |
| fireproof-receiver | Python R2 runtime — trust admission, state comparison, atomic transaction, Fulfillment signing | Private |
| fireproof-reviewer | Go independent reviewer — second verifier implementation, pure standard library | Private |
| fireproof-jvm | Java 17 receiver — second independent R2 v0.1 acceptance runtime | Private |
This is not a SaaS product and there's no sign-up flow. If you're working on AI-to-ERP write paths, looking at this as a protocol integration, or evaluating the IP — email directly.
Relevant conversations: enterprise architects dealing with AI agent write paths into ERP, compliance teams working on EU AI Act Article 12 or SOX audit requirements, or anyone seriously evaluating this space.