A spending limit your agent can't negotiate.

AgentRail sits between an agent's payment intent and the signature that sends it, evaluating every request against limits its human owner set — before any money moves.

$AGENTRAIL
your policy
$/day
send a payment
$

spent today: $0 of $500

Submit a payment to see the decision.

available today

Run it yourself

The library. npm install it, run it in your own process, hold your own keys, fund your own wallets. AgentRail never touches your money on your behalf — this is the honest default, not a fallback.

See the quickstart →

planned, not built

Reach it over HTTP

The hosted service. Same policy engine, same signer interface, same schema as the library — routes and auth in front of it, run by us instead of you. It doesn't exist yet, and it will stay devnet-only until custody moves off the local keystore described at /custody.

See what's actually built →

Three actors, one path

A principal — the human or org funding the agent — sets the rules. The agent requests payments but never holds raw keys. A payee — a service, an API, another agent — receives funds only if the request clears every rule first.

Read the full path →

Every payment, same five steps

  1. Agent submits a payment intent
  2. Policy engine evaluates it
  3. Signer signs — or refuses
  4. Transaction submits to Solana
  5. Receipt recorded in the audit log

See how the receipt is chained →

What a policy can constrain

  • per-transaction ceiling
  • rolling window caps
  • lifetime cap
  • payee allowlist
  • payee denylist
  • token allowlist
  • rate limits
  • time windows
  • escalation threshold
  • kill switch

See every rule →