# Ixrail Infrastructure for governed autonomous-agent payments: policy evaluation, approval boundaries, isolated signing, and decision receipts. # Documentation ## Introduction A mental model for governed agent payments. ### What Ixrail does Ixrail sits between agent intent and transaction signing. It normalizes payment requests, evaluates a versioned policy, pauses exceptional spend for approval, and produces a receipt for every decision. ### The control loop A merchant responds with HTTP 402 terms. The agent passes those terms to Ixrail. Ixrail verifies merchant, amount, asset, network, and budget before returning allow, review, or deny. ### Start safely Use the local simulator to validate policy behavior. The examples do not connect to a wallet or submit a network transaction. ## Quickstart Model a bounded purchase flow in a local sandbox. ### 1. Describe the policy Declare the budget, maximum transaction amount, approval threshold, approved merchants, networks, and assets. Policies are versioned inputs to evaluation. ### 2. Evaluate intent Send normalized purchase intent to the evaluator. Treat merchant-provided fields as untrusted until policy checks complete. ### 3. Handle the decision Proceed only on allow. Route review to an independent human approver. Treat deny as final for that immutable request. ## Policy configuration Controls that turn broad autonomy into scoped authority. ### Budget controls Set aggregate windows and per-transaction caps. Evaluation uses the current committed spend plus the requested amount. ### Merchant controls Prefer stable merchant identifiers over display names. An unknown merchant is denied unless a policy explicitly allows discovery. ### Approval workflows Threshold approval should be performed outside the agent context. Approval authorizes one normalized request, not a reusable spending grant. ## Security model Design assumptions and controls for hostile or compromised requests. ### Agent isolation The agent can propose intent but cannot access signing keys, rewrite policy, or approve its own exception. ### Protected signing The signer accepts a narrow transaction envelope bound to a policy decision and request identifier. Expired or replayed envelopes fail closed. ### Auditability Receipts preserve inputs, individual checks, decision, policy version, and signer verification references. Avoid placing secrets in receipts. ## Decision receipts A durable record of what was checked before execution. ### Receipt anatomy A receipt includes request ID, policy ID and version, normalized intent hash, checks, final decision, timestamp, and optional settlement reference. ### Verification Verify that the receipt decision matches the signed envelope and that policy and request identifiers are the expected values. ### Retention Choose retention based on your legal and operational needs. Encrypt sensitive metadata and keep payment credentials out of receipt payloads. # Field notes ## The payment rail is the permission system Published: 2026-07-08 URL: https://ixrail.dev/blog/payment-rail-permission-system Why autonomous purchasing requires an authority boundary beyond wallet custody. ### Custody is not control A wallet can prove that a key authorized a transaction. It cannot prove that the transaction matched the operator’s budget, merchant constraints, or approval policy. Autonomous systems need those questions answered before signing. ### Authority should be narrow The useful unit of authorization is one normalized purchase intent under one versioned policy. This keeps an agent productive without turning a broad capability into unrestricted authority. ### Receipts close the loop A payment rail should preserve the checks, decision, policy version, and settlement reference as part of execution. That evidence makes exceptional behavior inspectable rather than anecdotal. ## Treat HTTP 402 as a negotiation Published: 2026-06-19 URL: https://ixrail.dev/blog/http-402-negotiation A practical model for resolving price, asset, network, and policy before settlement. ### A challenge, not a checkout An HTTP 402 response can describe payment terms in a machine-readable way. The agent still needs to compare those terms with its policy before accepting them. ### Normalize before evaluation Merchant identity, amount, asset, network, and resource should be converted into a stable intent envelope. Untrusted response fields never move directly into signing. ### Resolve explicitly The result should be allow, review, or deny. Explicit states make retries, approvals, and observability predictable across tools and merchants. ## Receipts are part of control Published: 2026-05-30 URL: https://ixrail.dev/blog/receipts-part-of-control Decision evidence should be produced during execution—not reconstructed after it. ### Evidence at decision time Post-hoc logs often omit the policy version or normalized intent that actually governed a payment. A decision receipt records those inputs when they are still authoritative. ### Useful, not exhaustive Receipts should contain identifiers, hashes, checks, timestamps, and outcomes while excluding credentials and unnecessary sensitive metadata. ### Verification matters Operators can compare a receipt with the signed envelope and settlement reference to verify that intent, authorization, and consequence remained bound together. # Changelog ## Sandbox 0.4.0 Published: 2026-07-10 URL: https://ixrail.dev/changelog/0-4-0 Policy simulator receipts and projected-budget checks. ## Sandbox 0.3.0 Published: 2026-06-17 URL: https://ixrail.dev/changelog/0-3-0 HTTP 402 resolution and approval-threshold documentation. ## Sandbox 0.2.0 Published: 2026-05-22 URL: https://ixrail.dev/changelog/0-2-0 Isolated signer boundary examples for local development. # FAQ ### Does Ixrail give an agent a wallet? No. The agent proposes purchase intent. Policy evaluation, approvals, and protected signing remain outside the agent context. ### Can I test Ixrail without moving funds? Yes. The simulator and documentation examples are deterministic local models and do not connect to a wallet or network. ### What happens when a request exceeds policy? Ixrail returns review when independent approval is permitted, or deny when the request violates a hard constraint such as merchant, network, asset, or maximum amount. ### What is recorded after a decision? A structured receipt can include the request and policy identifiers, normalized intent hash, individual checks, final decision, and settlement reference.