Axiomdocs

How It Works

Understand Axiom's architecture and payment flow.

Architecture

Axiom consists of two main components:

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

Payment Flow

When an AI agent needs to make a purchase:

  1. Agent requests a card — The agent calls the create_card tool via MCP, specifying an optional spend limit.
  2. Balance check — Axiom verifies the user has sufficient funds.
  3. Card issuance — A single-use virtual debit card is created with the specified spend limit.
  4. Purchase — The agent uses the card details to complete the purchase at the merchant.
  5. Card closure — After the first authorization, the card is automatically closed to prevent reuse.
  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.

On this page