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 in shadow mode today.
Stripe DAA and x402 are live 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.
Refunds, payouts, transfers, disputes, application-fee refunds. 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 before it leaves your stack and returns a signed authorization the rail verifies on receipt.
Integration guide →HTTP 402 Payment Required flows for agent-to-agent and human-to-agent commerce. Axiru evaluates the x402 authorization request and issues an authorization token signed by the Axiru JWKS.
Integration guide →Author policies now. Enforcement lands in Phase 2.
These rails exist in the Axiru type system today. Policies targeting them can be saved and will evaluate correctly once the Phase 2 adapter ships. The Decision Engine returns axiru.deny.unknown_rail for live events until the adapter is active.
Universal Checkout Protocol. Policies can be authored against this rail today; the first-class adapter lands in Phase 2.
Tempo payment network. Reserve policies now; enforcement lands when the Phase 2 adapter ships.
USDC stablecoin transfers on Base. Hard country blocklists and rolling per-agent caps apply on the same policy engine as other rails.
USDC stablecoin transfers on Solana. Same policy surface as Base; wallet-address counterparty matching supported.
PayPal USD stablecoin transfers. Agent scope guards and rolling-window aggregates apply identically to other stablecoin rails.
ACH transfers via Plaid. Routes through the AGT extension 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. Policy authors can target the dwolla rail today with amount, rolling_window, and counterparty rules.
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. Flip enforcement per-rail when your team is ready.
Start in shadow mode first. Move to live enforcement later.