Enforcement

Payment Firewall

The verdict layer answers should this happen?The Payment Firewall can make the answer binding when the payment executor verifies the compatible grant before it calls the rail. The MCP package provides a local payment-guard surface; a protected executor is the additional component that refuses to move money without the grant. Its history is hash-chained and can be anchored, making later alteration detectable. An MCP installation alone is not a universal interception point for a host's other payment tools.

How it works

The firewall sits between the agent and the money. A payment runs through four steps, and money only moves if all four pass:

·Authorize. 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.
·Grant. On ALLOW the firewall issues a short-lived Ed25519 grant that binds the subject, payee, amount, and currency. On DENY no grant is issued, so the executor has nothing to present.
·Execute. 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.
·Record. Every decision, ALLOW or DENY, is appended to a hash-chained audit and later anchored to Bitcoin.

The protected executor is the boundary. A prompt-injected or hijacked agent can still call any tool the host exposes. It cannot settle through an executor that requires a valid, matching grant and rejects absent, expired, replayed, or altered grants.

Use the local payment guard

The local guard ships with @fidacy/mcp. Configure it in an MCP host to expose request_paymentand the related audit tools. Then wire your own payment path to an executor that validates the grant it receives. The configuration below is for the package's HTTP core mode, not a substitute for that executor integration:

{
  "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_…"
      }
    }
  }
}

Tool	What it does
`request_payment`	Authorize a payment against the signed mandate. Returns ALLOW + a grant, or DENY + the rule that blocked it.
`execute_payment`	The companion executor pattern. Couple it to your PSP or rail and require a matching grant before settlement.
`verify_mandate`	Read the active mandate for a subject.
`get_audit_proof`	Fetch the hash-chained audit record for a decision, with a chain-integrity check.

Duplicate-invoice fraud (BEC), closed at the firewall

Business email compromise turns on paying the same invoice twice, or re-presenting an invoice for a larger amount. Pass an invoiceRef with the payment 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.

This is enforced by Fidacy, not by the payment processor and not by the integrator's idempotency-key discipline. Caps protect the budget; the invoice lock stops re-presentation. Together they close the hole BEC exploits.

Tamper-evident audit

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, so a retroactive change is detectable by recomputing the chain. get_audit_proof returns the record plus a chainIntactflag, and the same check runs client-side against Fidacy's public key, with no account.

Anchored to Bitcoin

A hash chain proves no record was edited without detection. But the party that signs the chain holds the keys and could, in principle, regenerate the whole chain from scratch. To close that, Fidacy commits the head of the chain to Bitcoin, a public ledger no single party controls.

·Audit records are batched into a Merkle tree (RFC 6962) and the root is stamped to Bitcoin via OpenTimestamps.
·A standalone verifier recomputes the inclusion proof and checks the Bitcoin timestamp proof, trusting neither Fidacy nor the calendar servers, only the blockchain and the math.
·Once confirmed, the checkpoint existed by a specific Bitcoin block. It makes alteration of the anchored checkpoint detectable; it does not establish that Fidacy observed every external action.
·These are standard, audited primitives, not a homegrown scheme: the RFC 6962 Merkle tree is the same construction behind Certificate Transparency, and OpenTimestamps + Bitcoin do the anchoring. Nothing bespoke to trust.

GET/v1/artifacts/:id

Not "immutable." The chain is tamper-evident, Merkle-batched, and anchored to Bitcoin. A freshly anchored batch is pending until Bitcoin confirms it, which takes about an hour. Confirmation anchors a checkpoint in Bitcoin. It makes later alteration detectable, but it does not turn an incomplete operational record into a complete one.

See it yourself

The /proofpage 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, and follow the chain head's journey onto Bitcoin in four stages. Don't trust us; try to forge it.

← PreviousSpend Guard

Next →Verify a Payload