Cross-rail governance
Axiru is the policy layer that sits in front of every agent-initiated payment, regardless of the rail. One decision endpoint evaluates every transfer before money moves, returns a signed authorization when the policy allows it, and records every outcome in a tamper-evident ledger. This section covers the rail-by-rail integration guides for Phase 1 active rails and the Phase 2 roadmap.
Start with a rail integration guide.
Each guide walks through prerequisites, connecting the rail, authoring policies, wiring your agent runtime, verifying signed authorizations, and rolling from shadow mode to enforcing.
Governing agent payments on Stripe DAA
Wire the pre-authorization hook, author DAA policies from the T-048 templates, verify the signed AuthorizationToken JWS, and roll out from shadow to enforcing.
Read the Stripe DAA guide →Governing HTTP-native agent payments on x402
Provision the Privy wallet signer, configure the policy hook, verify AuthorizationTokenClaims JWS, understand the fail-closed contract, and roll out to enforcing.
Read the x402 guide →Rails live today.
x402 pre-authorization is live: policy evaluates the payment before it executes and issues a signed allow token, fail closed; the payee verifies the token via the middleware. Stripe DAA runs in shadow mode. The legacy Stripe surface keeps running in enforcing mode on the v1 policy path while the cross-rail engine runs alongside it.
Refund enforcement pre-execution; payouts, transfers, disputes, and application-fee refunds governed from webhooks. The existing Stripe governance surface keeps running on the v1 policy path while the cross-rail engine runs in parallel shadow mode.
Direct-Account-Authorized agent payments. Axiru evaluates every agent_payment, agent_payout, and agent_authorization in shadow mode today: decisions recorded and auditable. Signed enforcement mirrors the live x402 path and flips on per-org.
Integration guide →HTTP 402 Payment Required flows for agent-to-agent and human-to-agent commerce. Axiru evaluates every x402 authorization request fail-closed and issues an authorization token signed by the Axiru JWKS. No token, no payment.
Integration guide →USDC stablecoin transfers on Solana. Pre-execution transfer decisions are live via the public API for early-access orgs; wallet-address counterparty matching supported.
Reserved rails. Adapters land in Phase 2.
These rails exist in the Axiru type system today so your policies stay rail-agnostic. Policy targeting for them arrives with the v2 editor, and the Decision Engine returns axiru.deny.unknown_rail for live events until the adapter is active.
Universal Checkout Protocol. Reserved in the type system today so your policies stay rail-agnostic; policy targeting arrives with the v2 editor and the first-class adapter lands in Phase 2.
Tempo payment network. Reserved in the type system today; enforcement lands when the Phase 2 adapter ships.
USDC stablecoin transfers on Base. Reserved in the type system today; the adapter ships with Phase 2 on the same policy engine as other rails.
PayPal USD stablecoin transfers. Agent scope guards and rolling-window aggregates apply identically to other stablecoin rails.
ACH transfers via Plaid. Reserved in the type system today; first-class adapter and Plaid-specific action labels in Phase 2.
Bank transfers via Modern Treasury. OVT shape maps to incoming transfer objects; same decision endpoint, same ledger.
ACH and RTP transfers via Dwolla. Reserved in the type system today; policy targeting arrives with the v2 editor.
Square payment actions. Phase 2 adapter maps Square webhook events to the canonical OVT shape.
One decision endpoint for every rail.
The governance contract is the same across all rails. The OVT shape, the decision outcomes, the signed authorization, and the audit ledger are rail-agnostic. Rail-specific bits live only in the adapter.
Agent POSTs to /api/v1/authorizations
Your agent (or the rail host) sends the proposed OutboundValueTransfer: rail, rail action, amount, currency, initiator kind, agent scopes, counterparty.
Decision Engine evaluates policies
Policies run in priority order against ten v2 rule kinds: rail, rail_action, amount, initiator_kind, initiator_id, agent_scope, counterparty, rolling_window, time_of_day, custom_expression.
Signed AuthorizationToken or deny/quarantine
On allow, the route mints a JWS signed by the rotating Axiru JWKS and returns it to the agent. On deny or quarantine, no token is issued: the fail-closed contract from spec §11.4.
Rail verifies and settles
The rail (Stripe DAA, x402) verifies the JWS against the published JWKS before executing. No valid signature, no settlement. Every outcome lands in the tamper-evident audit ledger.
Wire one endpoint. Govern every agentic payment.
Start in shadow mode: Axiru records every decision without gating a single rail. Enforcement expands rail by rail as your team is ready.
Start in shadow mode first. Move to live enforcement later.