Fidacy documentation

Authority before action. Evidence after.

Fidacy is the neutral permission layer for AI agents. Define what an agent may do, enforce payments and other consequential actions before execution, and retain signed evidence of every decision and control boundary.

Choose the integration path

Use the path that matches the boundary you need. An assessment is a signed risk decision. An action mandate makes a specific consequential action enforceable. Control Coverage makes the boundary, liveness and evidence gaps visible to the operator.

• ·Assess a payment or protocol request. Call POST /v1/assess to evaluate an AP2 payment mandate and receive approve, review or denywith a signed JWS. AP2, A2A and UCP bindings package that result at their protocol edge.
• ·Gate an action in the real world. Create an action mandate, ask Fidacy to decide a request, then redeem the issued grant in the executor before it reaches Stripe, a CRM, a mail system or another protected system.
• ·Show operational coverage. Send authenticated connector signals and read a signed Control Coverage Report that distinguishes a current observation, a historic hard gate and a gap in evidence.

What the records prove

identity → mandate → decision → signed receipt → optional grant redemption → audit / anchor

Each arrow has a different meaning. Fidacy exposes those meanings instead of
collapsing them into a generic “protected” status.

• ·A signed decision proves what Fidacy decided for the submitted, hashed request at that time.
• ·A redeemed one-time grant proves the Fidacy executor enforced its gate before continuing its own side-effect path.
• ·An authenticated heartbeat proves a connector was recently observed. It does not by itself prove a hard gate is active.
• ·Hash chains and external checkpoints make later alteration evident. They do not invent visibility into actions that bypass every Fidacy-connected boundary.

Core building blocks

Start with a test key

Test keys begin with fky_test_. They exercise the same API contract without live billing. Keep the key server-side, use a minimal scope, and move to a live key only when the protected executor is ready.