Product

The padlock for agent payments.

A neutral, verifiable verdict on every agent payment, signed by Fidacy and checkable by anyone, trusting no one. For money it becomes a binding firewall the agent cannot talk past, and every decision is anchored to Bitcoin, so not even Fidacy can rewrite it.

approve! review deny

Signed verdict -> binding payment firewall -> audit anchored to Bitcoin. Verify every layer yourself.

How it works

Assess → Verdict → Verify → Enforce → Anchor

01

Assess

Send the agent's mandate and identity to /v1/assess. Fidacy runs Know-Your-Agent, a deterministic Trust Score, and your policy.

02

Verdict

Get back approve | review | deny, plus a signed verifiable credential (application/vc+jws), the verdict, the score, and the signals behind it.

03

Verify

The merchant, the rail, a regulator: anyone verifies the verdict against Fidacy's public JWKS. No need to trust Fidacy. Just verify the signature.

And when it is money, two more steps, the teeth and the moat:

04

Enforce

When it is money, the verdict is binding. The agent calls request_payment; an approve mints a short-lived Ed25519 grant the executor verifies before money moves, a deny mints nothing. A duplicate invoice or a redirected wire (BEC) is stopped at the gate, by Fidacy, not the payment rail.

05

Anchor

Every decision lands in a hash-chained, append-only audit whose head is committed to Bitcoin (Merkle RFC 6962 + OpenTimestamps). Prove months later exactly what was decided, and verify it offline against Bitcoin with a standalone verifier. Not even Fidacy can rewrite it.

Try it live: every scenario on the demo runs a real /v1/assess verified in your browser, and /proof runs a real payment through the firewall, then lets you tamper with it and follow the audit onto Bitcoin.

Capabilities

Led by the decision, not the fraud.

01

Real-time risk verdict

The decision other layers don't make: approve | review | deny, with a 0-100 score and the signals behind it. Today it catches a mandate exceeded, anomalous velocity, an invalid signature, an unverified or out-of-policy agent, a degraded trust history, and statistical behavioral anomalies (an unusual amount, a new counterparty, a burst). Built on Know-Your-Agent (RFC 7638 key thumbprint) and a deterministic, event-sourced Trust Score.

Roadmap: Behavioral/semantic hijack & prompt-injection detection, built with design partners on real traffic.

02

Payment Firewall, a binding money gate

When it's money, the verdict is binding. The agent calls request_payment; an approve issues a short-lived Ed25519 grant the executor verifies before any money moves, so a hijacked agent has nothing to present. A deny issues no grant, and no money moves. Pay an invoice once and a re-presentation is denied, the way BEC and duplicate invoices are closed, enforced by Fidacy and not the payment rail.

03

Verifiable, not delegated

Every verdict is an EdDSA-signed credential. Verify it yourself against our public JWKS with the open-source @fidacy/verify, isomorphic, zero-dependency. Trust is verified, never asked for.

04

Public transparency

Verify the quality, not just the signature. A public GET /v1/transparency endpoint publishes accuracy, cost-weighted error, fail-safe bias, hot-path share and the current model version, and every verdict carries its policy_version. Quality is governed by a human-in-the-loop eval cycle, in the open.

05

Neutral and rail-agnostic

Live on UCP, AP2 and A2A; works with cards and stablecoins. Identity-agnostic: bring your own agent identity, a registered key, a W3C DID (did:web/did:key), or a SPIFFE JWT-SVID, each cryptographically verified. Fidacy is the trust overlay. It never owns the checkout, the rail, or the agent.

06

Tamper-evident audit, anchored to Bitcoin

Every verdict lands in a hash-chained, append-only audit whose head is committed to Bitcoin (Merkle RFC 6962 + OpenTimestamps). Prove, months later, exactly what was decided and why, and verify it offline against Bitcoin with a standalone verifier. Not even Fidacy can rewrite it after the fact.

07

Programmable policy

A deterministic Rules Engine: spend limits, geographies, currencies, agent tiers, allow/deny lists. Backtest against history before you ship. Your rules, your jurisdiction, never an LLM guessing.

Roadmap: Jurisdiction policy packs, governable in-tenant.

08

Two-sided, Spend Guard

Protect both sides. Accept-side: merchants get a verdict before they fulfill. Buy-side: organizations cap, govern, and step-up their own agents' spend, with cryptographic proof of control.

Neutral + verifiable

The padlock, not the promise.

SSL didn't ask you to trust a company. It made every connection verifiable. Fidacy does the same for agents: you don't trust the issuer, you check the signature. A signed verdict from Fidacy is a padlock, recognizable, and verifiable by anyone, on any rail, in any jurisdiction. Neutrality is the product.

Vision · Roadmap

Governed by the jurisdiction that runs it.

Built to be governed by the jurisdiction that runs it: deterministic policy, verifiable audit, EU-aligned by design.

Roadmap: in-jurisdiction / data-residency / self-host deployment for sovereign and regulated buyers, built against signed pilots.

See a live verdict.

Don't trust us, verify it. Then spin up your own org, no sales call required. Each org is isolated, with its own API keys, and one install of npx -y @fidacy/mcp ships both the signed verdict and the Payment Firewall.