Authorized to act is not the same as accepted by the receiver.
FireProof sits at the receiver's transaction boundary. It verifies an AI-initiated change against the receiver's current business state, commits the business change and final acceptance record together, and produces portable signed evidence of what the receiver accepted — or rejected.
Identity, policy and approvals can decide whether an agent may attempt an action. They do not necessarily tell the receiving system whether that exact transaction is still acceptable against its state at commit time.
Example: an agent is authorized to raise a customer's credit limit from €50k to €80k while the account is active, risk band B, record version 17.
Before the write reaches the system of record, the account changes to risk band D and version 18. The agent can still be correctly authenticated. The tool call can still be permitted. The original transaction should no longer be accepted.
FireProof makes the receiver recompute that decision from its own live state. If the expected state no longer matches, the receiver rejects the transaction and records that final result without applying the business change.
FireProof is not an IAM product, AI governance platform, agent framework or observability layer. It is designed to complement those controls at the write boundary.
The distinction: an upstream authority can prove “this action was authorized.” FireProof is designed to prove “this receiver verified that exact action against its own state and accepted or rejected it.”
FireProof is designed for receiving systems with a controllable transactional boundary. It is not a universal proxy for arbitrary APIs.
If the commit result is uncertain, the receiver checks the final acceptance record instead of blindly retrying the business write. Evidence signing happens after commit and cannot mutate the business row.
The same acceptance model has been exercised across two different business profiles and two different transactional database engines. The implementations are prototypes, not claims of production ERP deployment.
| Profile | Receiver | What was exercised |
|---|---|---|
| Supplier master change | PostgreSQL | Signed authorization, exact-state matching, stale/expired/tampered/replay rejection, atomic business change + final acceptance record, post-commit receiver-signed result and offline bundle verification. |
| Customer credit limit | MySQL / InnoDB | Same semantic model in a different domain and engine, including stale-risk rejection, nonce fencing, replay recovery, lost commit acknowledgement recovery, and forced rollback after both transactional writes. |
Deliberate limits: FireProof does not prove an external bank transfer completed, that a legal obligation was satisfied, that wall-clock time is objectively true, or that key custody is secure. It proves the receiver-owned acceptance facts encoded by the profile.
The protocol specification and Python verifier are Apache 2.0 so the evidence format can be inspected and verified independently. Receiver implementations remain separate.
| Component | Purpose | Status |
|---|---|---|
| fireproof-protocol | Evidence profile specification, schemas, canonicalization rules and conformance fixtures | Open — Apache 2.0 |
| fireproof-verifier | Python offline verifier for DSSE/JCS/Ed25519 trust and commitment linkage | Open — Apache 2.0 |
| fireproof-receiver | Receiver runtimes and transactional acceptance experiments | Private |
| fireproof-reviewer | Independent Go reviewer and extracted semantic profile kernel | Private |
| fireproof-jvm | Java 17 independent receiver implementation | Private |
FireProof is an independent infrastructure project, not a SaaS dashboard. The useful conversation is with teams building write-enabled AI agents or consequential automation into finance, procurement and other systems of record.
If receiver-owned transaction acceptance maps to a real boundary in your architecture, reach out directly. The project is open to technical evaluation, integration discussions and design-partner conversations.