How It Works

Architecture

Axiom consists of two main components:

1. Axiom API — Manages payment methods, processes payments, and serves as the MCP server for agent communication.
2. Axiom Dashboard — A web app where users manage their accounts, link payment methods, set rules, and monitor transactions.

Payment Flow

When an AI agent needs to make a purchase:

1. Agent requests payment details — The agent calls get_payment_details via MCP with the item, amount, merchant, and reason for purchase.
2. Rules check — Axiom evaluates the user's spending rules to determine if the purchase is allowed.
3. Card issuance — A single-use virtual debit card is created with a spend limit matching the purchase amount.
4. Charge — The user's linked payment method is charged for the transaction amount.
5. Purchase — The agent uses the virtual card details to complete the purchase at the merchant. The card is automatically closed after the first authorization.
6. Transaction recorded — The transaction is logged with full details including the AI's reasoning and any rules that were applied.

Why mcporter?

We recommend using mcporter to connect your agent to Axiom rather than having the agent handle OAuth directly. Here's why:

• Separation of access — mcporter manages the OAuth token and gives the agent access to MCP tools only. The agent never has access to your Axiom dashboard, wallet settings, or spending rules UI.
• Simplified token lifecycle — mcporter handles token caching, refresh, and re-authentication. Your agent doesn't need to implement OAuth2 with PKCE.
• Cross-device auth built in — mcporter integrates with Axiom's "Sign in on another device" flow, making it easy for browser-based agents (like OpenClaw) to authenticate without native browser access.

For agents that need to handle OAuth directly, the same security model applies — scoped OAuth2 tokens ensure agents can only access the MCP tools they've been granted permission for.

Security Model

Axiom is designed with multiple layers of protection:

• Single-use cards — Each card works for exactly one transaction, eliminating the risk of card reuse or theft.
• Spend limits — Cards are created with explicit limits so agents can never spend more than authorized.
• User-defined rules — The rules engine evaluates every purchase attempt against user-configured policies before authorizing.
• Scoped permissions — MCP connections use OAuth2 with granular scopes, so agents only get access to the capabilities they need.