Documentation

The Trust Layer for Agent Payments

Fidacy verifies the agent, checks the mandate against the user's signed intent, scores the risk, and issues a cryptographically signed verdict, then keeps a tamper-proof record of it. It fills the risk_data container in AP2 and rides natively on A2A v1.0, so AI agents can move money and you can prove who authorized what.

The problem

Autonomous agents are starting to pay for things. The protocols that carry those payments, Google's AP2, the A2A agent-to-agent standard, leave a deliberate gap: a place to attach a risk decision, but no opinion on who fills it. Without a trust layer, a merchant or PSP receiving an agent-initiated payment has no way to know whether the agent is who it claims to be, whether it stayed inside the user's mandate, or who to hold accountable in a dispute.

Fidacy is that trust layer. It is a generic decision engine in code, the same primitives assess any agent action, but its first and sharpest job is the one the market needs now: making agent payments accountable.

What happens on every request

A single call to POST /v1/assess runs the full pipeline and returns in milliseconds:

• ·Identify (KYA).The calling agent is matched to a verified identity by the RFC 7638 thumbprint of its key, an indexed lookup. An embedded, unverified key is marked self-asserted and earns no trust.
• ·Authorize. The mandate is validated and checked against your active policy, amount, currency, geography, velocity.
• ·Score. A deterministic risk score with the exact signals behind it. An optional reasoning layer refines ambiguous cases after the verdict commits, never on the hot path.
• ·Sign. An EdDSA-signed Risk Payload is issued and embedded in the AP2 risk_data (or an A2A Task.metadata). Anyone can verify it against the public JWKS.
• ·Audit. The decision is hash-chained into an append-only log and sealed with periodic Merkle anchors, the head of that chain is committed to Bitcoin, so the record is tamper-evident and re-verifiable offline, not even Fidacy can rewrite it.

The verdict

Every assessment returns a flat decision plus a rich, versioned outcome object, risk level, the consolidated reason, per-dimension confidences, typed signals, rejection reasons, and pointers to the signed payload and the audit entry.

{
  "decision": "approve",            // approve | review | deny
  "score": 12,
  "assessmentId": "asmt_…",
  "riskPayloadJws": "eyJhbGciOiJFZERTQSJ9…",
  "outcome": {
    "object": "assessment",
    "outcome": { "decision": "approve", "risk_level": "normal", "reason": "approved" },
    "confidences": { "agent_identity": 1, "mandate_validity": 1, … },
    "risk_payload": { "alg": "EdDSA", "kid": "…", "verify_url": "https://api.fidacy.com/.well-known/jwks.json" },
    "audit": { "entry_id": "ae_…", "sequence": 41, "status": "pending" }
  }
}

Making the verdict binding

The verdict answers should this happen? The Payment Firewall makes the answer enforceable: an agent calls request_payment, and money can only move when an approve issues a short-lived Ed25519 grant the executor verifies first. A deny issues no grant, so no money moves. That closes duplicate-invoice and BEC fraud at the gate: one payment per invoice, enforced by Fidacy, not the PSP.

Both the signed verdict (assess_action) and the firewall (request_payment) ship in a single install: npx -y @fidacy/mcp. See the MCP server.

Standards & compliance

• ·AP2, fills the risk_data container in Payment Mandates.
• ·A2A v1.0, version negotiation, Agent Card verification, verdict as Task.metadata.
• ·EU AI Act, the append-only, hash-chained audit trail is the non-repudiable evidence Article 10-class systems require.
• ·EdDSA / JWS, every risk payload is a signed JWS, verifiable by any party against the public JWKS.

Where to go next

• ·Quickstart, your first verified payment in three calls.
• ·MCP Server, one install for the signed verdict and the payment firewall.
• ·Payment Firewall, the hard money gate, grants, and the Bitcoin-anchored audit.
• ·Transparency & Evals, the public quality metrics behind every verdict.
• ·How Fidacy Works, the model: principals, agents, mandates, policies, trust, audit.
• ·A2A Protocol, negotiate, verify the Agent Card, return Task.metadata.
• ·API Reference, every endpoint, field, and error.