The verdict layer answers should this happen? The Payment Firewall makes the answer binding: an agent cannot move money unless Fidacy authorized the payment against a signed mandate and issued a short-lived grant the executor verifies first. Every decision is written to a hash-chained, append-only audit, anchored to Bitcoin. It installs as one MCP server, with no change to the agent’s code.
The firewall sits between the agent and the money. A payment runs through four steps, and money only moves if all four pass:
The agent calls request_payment. The firewall evaluates the request against the active, signed mandate for that subject (per-transaction cap, payee allowlist, category, window, cumulative spend) in a single locked transaction.
On ALLOW the firewall issues a short-lived Ed25519 grant binding subject, payee, amount and currency. On DENY no grant is issued, so the executor has nothing to present.
The agent calls execute_payment. The executor verifies the grant against Fidacy’s public key before it touches the payment rail. No valid grant, no settlement.
Every decision, ALLOW or DENY, is appended to a hash-chained audit and later anchored to Bitcoin.
The agent cannot talk past it. A prompt-injected or hijacked agent controls what it intends, but it does not hold Fidacy’s private key. Without a valid grant the executor refuses to move money, and any grant it did not issue is a forgery the executor rejects.
{
"mcpServers": {
"fidacy-firewall": {
"command": "npx",
"args": ["-y", "@fidacy/mcp"],
"env": {
"FIDACY_MODE": "http",
"FIDACY_API_URL": "https://fidacy-core.vercel.app",
"FIDACY_API_KEY": "fky_live_…"
}
}
}
}request_paymentAuthorize a payment against the signed mandate. Returns ALLOW + a grant, or DENY + the rule that blocked it.
execute_paymentSettle only after verifying the grant against Fidacy’s public key. The template you couple to your PSP.
verify_mandateRead the active mandate for a subject.
get_audit_proofFetch the hash-chained audit record for a decision, with a chain-integrity check.
Business email compromise turns on paying the same invoice twice, or re-presenting it for a larger amount. Pass an invoiceRef and the firewall enforces one payment per invoice: a second authorization for the same invoice, at any amount and with any idempotency key, is DENY duplicate_invoice. The grant binds the invoice, so the executor also refuses a settlement whose invoice differs. Enforced by Fidacy — not the processor, not the integrator’s idempotency discipline.
Every decision is written to an append-only log where each record hashes the previous record’s hash, this decision’s digest, and its timestamp. Editing any record breaks every hash after it. get_audit_proof returns the record plus a chainIntact flag, and the same check runs client-side against Fidacy’s public key, with no account.
A hash chain proves no record was edited. But the party that signs it holds the keys and could regenerate the whole chain. To close that, Fidacy commits the head of the chain to Bitcoin, a public ledger no single party controls.
MerkleAudit records are batched into an RFC 6962 Merkle tree and the root is stamped to Bitcoin via OpenTimestamps.
Standalone verifyA verifier recomputes the inclusion proof and checks the Bitcoin attestation — trusting neither Fidacy nor the calendar servers, only the blockchain and the math.
Standard primitivesRFC 6962 (the Certificate Transparency construction) + OpenTimestamps + Bitcoin. Nothing bespoke to trust.
/v1/anchor/latestNot "immutable." The chain is tamper-evident, Merkle-batched, and anchored to Bitcoin. A freshly anchored batch is pending until Bitcoin confirms it (about an hour). Once confirmed, rewriting it would mean rewriting Bitcoin.
The Proof page runs a real payment through the live firewall with no account, then lets you verify the Ed25519 grant and the hash-chained audit in your own browser — tamper with a field to watch the signature and the chain break. Don’t trust us; try to forge it.