Financial authorization for AI agents

One authorization call before your agent spends money.

TachyFi decides whether an agent may perform a financial action for its principal, under a versioned policy, and records the decision with its reason. Your payment provider and your credentials stay where they are.

tachyfi — POST /v1/authorizations
# request · from your execution service
POST /v1/authorizations
Authorization: Bearer <redacted>
Idempotency-Key: idem_9a4d7b2e

{
  "delegation_id": "dlg_31ab",
  "action": {
    "type": "payment",
    "amount_minor": 48200,
    "currency": "USD",
    "counterparty_id": "mrc_2f8a"
  }
}
# response
201 Created

{
  "id": "auth_8f21c4",
  "decision": "allow",
  "policy_version": "v14",
  "reasons": [
    "WITHIN_TXN_CEILING",
    "COUNTERPARTY_IN_SCOPE"
  ],
  "constraints": {
    "max_amount_minor": 48200,
    "currency": "USD"
  },
  "expires_at": "2026-09-17T14:07:00Z",
  "execution": null
}

A policy decision with its reasons, policy version, constraints and expiry. Separate from execution: not a network authorization, and not proof that a payment settled.

01 What it decides

May this agent perform this financial action for this principal, under these constraints?

Six things are modelled explicitly. Each one is named in the decision record, so the engineer asked to justify an authorization can point at every input.

[ 01 ]

Principal

The organization or person granting authority. Derived from authenticated tenant scope on every lookup, never from a field in the request.

[ 02 ]

Agent and delegation

The actor, its delegated scope, its limits, its expiry and its revocation. An expired or revoked delegation is not revived by changing a status.

[ 03 ]

Action

The intended financial operation: type, amount in integer minor units, currency with an explicit exponent, and the canonical counterparty.

[ 04 ]

Policy

Versioned, deterministic rules. Model output, merchant metadata, tool descriptions and retrieved content are input to a decision, never authority over one.

[ 05 ]

Authorization

allow, deny or review, with stable reason codes, constraints, expiry, the policy version and correlation identifiers. Bound to the action it was asked about.

[ 06 ]

Execution evidence

The separately verified outcome, linked to the authorization. allow does not mean executed, captured or settled; the record says which.

02 The decision

Four verdicts. Each one carries its policy version and its reason.

A verdict never appears without the policy that produced it and the reason it did. “Denied by policy v14 — merchant category outside delegated scope,” not “Denied.”

allow
Verified

Allowed by policy v14 — $482.00 is within the $500.00 per-transaction ceiling and mrc_2f8a is in delegated scope. Valid until 2026-09-17T14:07:00Z.

review
Medium

Escalated by policy v14 — $5,000.00 exceeds the $2,500.00 review threshold. Pending an authenticated reviewer. A review is not permission to execute.

deny
Critical

Denied by policy v14 — merchant category outside delegated scope.

expired
Expired

auth_8f21c4 expired unused at 2026-09-17T14:07:00Z. Execution requires a fresh authorization.

Policy denial, pending review and operational error are three different outcomes and are recorded as three different things. None of them is an allow.

03 How it works

Three steps between the agent and the spend.

01

Bind

delegation  dlg_31ab
principal   org_4d10
agent       agt_7c21
scope       payment · USD · vendors
ceiling     $500.00 / txn
daily       $2,500.00
expires     2026-10-01T00:00:00Z
revocable   yes

The principal grants an agent a delegated scope: what it may do, with whom, up to what ceiling, until when. Revocation takes effect on the next decision.

02

Authorize

POST /v1/authorizations
 201 · auth_8f21c4
 allow · policy v14
 expires 2026-09-17T14:07:00Z

Before the spend, your execution service asks. The policy is evaluated deterministically and the answer is bound to this principal, agent, action, counterparty, amount and expiry.

03

Execute and record

GET /v1/authorizations/auth_8f21c4
 decision   allow
 execution  captured · txn_91be
 recorded   2026-09-17T14:03:12Z

The service holding your provider credentials enforces the decision, then posts the outcome. The record links the execution reference to the authorization it consumed.

04 Boundaries

What TachyFi is, and is not.

A control plane sits between an agent and someone’s money. These are the constraints it is built to hold.

Not a payment processor

TachyFi evaluates authority and records evidence. Your existing provider executes the payment, on your account.

No custody

No balances, no stored value, no funds received or transmitted. Spend limits are control records, not money.

Credentials stay with you

Raw payment credentials and signing keys never enter TachyFi, an LLM context, a browser bundle or a log.

Enforcement at the boundary

The component holding the credentials enforces the decision. An SDK returning allow is not enforcement, and there is no bypass with the same privileges.

Deny-default

Invalid input, expired authority, an unavailable required check or an infrastructure failure never becomes allow. Errors are errors, not permissions.

Deterministic

Explicit, testable rules with a version. A model cannot change a policy, a limit or a permission by asking.

Exact amounts

Integer minor units with an explicit currency exponent and safe bounds. No binary floating point near money.

Single-use grants

Atomic consumption and tenant-bound idempotency keys. A retry does not create a second grant, reservation or payment.

Honest evidence

A check that did not run is recorded as not run. Nothing unscreened is labelled compliant; nothing unverified is labelled settled.

05 Where it fits

In front of any financial action an agent can take.

Built for agent platforms and agent-native SaaS with a financial action they cannot safely enable. The integration is one call inside your existing execution service, not a migration to a new provider.

Paid tools and APIs

Before an agent buys compute, data or a third-party service on your account.

Procurement

Before an agent places an order or approves a supplier invoice.

Refunds and credits

Before a support agent returns money to a customer.

Subscriptions

Before an agent starts, upgrades or renews a recurring charge.

Payouts

Before an operations agent instructs your provider to pay a counterparty.

Put one call in front of the spend.

One authorization call before an agent spends. A decision record after.