Wallet for Agents

A payment primitive for AI agents — crypto or fiat — with spending rules enforced on Keyban's servers.

• Two rails. Crypto on Base; fiat virtual cards via Stripe Issuing.
• Autonomous within policies. The agent pays on its own under the budgets, velocities, and allow-lists you set in the dashboard — all enforced server-side.
• Human in the loop only on demand. A payment above your threshold pauses for confirmation; everything below ships without you.
• Secure by design. Five independent enforcement layers sit between an agent's intent and a settled payment — full breakdown on the Security architecture page.
• Verifiable identity. Every payment carries a W3C Verifiable Credential proving the agent acts for your organisation — readable by any merchant with a standard VC library.

Two payment rails

Rail	What the agent pays
Crypto on Base (other EVM chains to follow)	Simple USDC transfers + x402 machine-to-machine payments
Fiat virtual cards via Stripe Issuing	Ephemeral debit cards with pre-authorised spend caps

Both rails go through the same policy engine, the same authentication, and the same human-approval workflow. The split only exists at the moment of payment.

Architecture at a glance

1. Client side

   • AI agent

     Your LLM workflow. Calls Keyban MCP tools to submit payment intents.

   • Keyban MCP

     Local process. Holds the client TSS share in the OS keychain. Routes intents, does not arbitrate.

   • Treasury signers

     Humans in your org. Each holds a TSS share. Co-sign treasury funding moves from the dashboard.

2. Keyban services

   • Policy Engine

     Authorizes every intent against your quotas, velocities, thresholds, allow-lists. Same engine for both rails.

   • TSS co-signer

     Holds the server share for every wallet. Co-signs only after the Policy Engine approves.

   • Identity & Agent Passport

     Provisions your organisation's decentralised identity (DID) and issues a W3C Verifiable Credential for every Agent Wallet.

   • Keyban relayer

     Sole broadcaster. The agent has no direct path to the chain. Gas is taken care of — the agent never pays.

3. On-chain wallets

   • Agent Wallet · hot wallet

     Smart account in 2-of-2 TSS (agent + Keyban). ERC-1271 signature validation, relayer-only entry point. One per agent.

   • Treasury · warm wallet

     Smart account in N-of-M multisig human TSS. Holds the bulk of your funds, funds the Agent Wallets on demand.

4. Payment rails

   • Base · x402

     Machine-to-machine HTTP payments. No gas for the agent to pay.

   • Base · simple transfer

     Stablecoins or any supported token, to any recipient address.

   • Credit card

     Virtual cards with pre-authorisation, issued through Stripe Issuing.

Four layers: the agent and the Keyban MCP run on the operator's machine; the Policy Engine, TSS co-signer, and relayer run on Keyban's servers; the treasury and Agent Wallets are on-chain smart accounts; payments settle on Base or, soon, Stripe Issuing.

The client / server boundary is the security boundary. Nothing the agent does on its own carries spending authority — the Policy Engine, the TSS co-signer, and the relayer all live with Keyban, and the on-chain wallets enforce these constraints at the contract level.

Treasury and Agent Wallets — warm and hot

Two kinds of smart accounts live in your application:

• Treasury — warm wallet. N-of-M human multisig TSS. Holds the bulk of your funds; every move is co-signed from the dashboard.
• Agent Wallet — hot wallet. One per agent. 2-of-2 TSS (agent + Keyban). Funded by the treasury, spent under policy.

1. Agent Wallet · sales$3,000/mo · allow-list of lead-data vendors
2. Agent Wallet · ops$1,000/mo · human approval above $500
3. TreasuryWarm wallet · N-of-M human multisig TSS · AA smart account. Funded from an external wallet or via the built-in on-ramp.
4. Agent Wallet · research$1,500/mo · any x402 endpoint

The treasury is the central warm wallet, governed by human signers in N-of-M multisig. It funds each Agent Wallet on demand. Each Agent Wallet has its own balance, policies, and audit trail.

How a payment is processed

A payment goes through four enforcement points: identity, authorization, signature, submission.

1. AgentLLM workflow
2. MCPlocal process
3. Policy EngineKeyban server
4. TSS co-signerKeyban server
5. RelayerKeyban server
6. Basepayment rail

1. 1submit intent (recipient, amount, rail)
2. 2forward intent + X-Api-Key
3. 3evaluate policies
4. 4approve · request co-signature
5. 5TSS ceremony — both shares required
6. 6hand signed transaction
7. 7broadcast
8. 8result

The agent sends an authenticated intent through the MCP, the Policy Engine evaluates it, the TSS co-signer signs only if the policy approves, and the Keyban relayer broadcasts the signed transaction. Above-threshold intents pause for human approval.

Above your threshold, the Policy Engine parks the payment in the dashboard for manual approval — the agent waits, you confirm.

Security — enforcement layers

The architecture above is built on layered enforcements. Each layer is independent of the others — bypassing any one of them is not enough to spend. The full picture lives on the Security architecture page; the summary below is enough to understand the model.

1. Common to both rails

   • Authenticated identity · X-Api-Key

     Every MCP → server call carries an API key scoped to one application and one wallet.

   • Authorization · Policy Engine

     Every intent evaluated server-side against your policies.

2. Blockchain rail

   • Key custody · TSS

     FROST threshold scheme. The private key is never assembled. Unlike MPC wallets, no key reconstruction at any point. The server share itself is encrypted at rest on Keyban's infrastructure.

   • Client share · OS keychain

     The client TSS share is sealed in the OS keychain (macOS Keychain, Linux Secret Service, Windows Credential Manager). Never leaves the user's device.

   • On-chain · Smart account

     ERC-1271 validates the TSS signature on-chain. Signers can be rotated without changing the wallet address.

   • Submission · Keyban relayer

     Even if the upstream layers were bypassed and a valid signature were produced outside the TSS protocol, the agent still could not send the transaction to the blockchain. Submission goes exclusively through the Keyban relayer.

   Fiat rail

   • Ephemeral virtual cards

     Single-use or short-lived cards with pre-authorised spend caps.

   • Stripe Issuing security stack

     Industry-standard card-network protections layered underneath — PCI DSS Level 1, card-number tokenisation, fraud detection (Stripe Radar), and the issuing networks' own risk engines.

   • Stripe authorization webhook

     Every charge is approved by the Policy Engine before it settles.

Two enforcement layers shared by both rails (authenticated identity, Policy Engine), then rail-specific layers: TSS / Smart account / Keyban relayer for the blockchain rail, ephemeral cards / Stripe security stack / Stripe authorization webhook for the fiat rail.

Verifiable identity — Agent Passport

With Wallet for Agents, Keyban provisions a decentralised identity (DID) for your organisation — a W3C-standard identity you own, anchored to your domain. Keyban generates the signing key, your domain hosts the public did.json, and any third party on the open web can resolve and verify it with a standard library — no Keyban dependency, no proprietary protocol.

Every Agent Wallet you provision is then issued an Agent Passport under that identity: a W3C Verifiable Credential proving the agent acts on behalf of your organisation, signed by your DID's key. The passport travels as an Agent-Passport HTTP header on every outgoing request the agent makes (x402 payments today, any HTTP API your agent integrates with tomorrow). It identifies the agent by its smart account address, so the same scheme works whether the payment settles in crypto, fiat, or a future rail.

Setup is one-time: you publish the did.json Keyban generates for you on your domain (the dashboard walks you through it). From then on, every Agent Wallet you create inherits the same verifiable organisational identity.

Onboarding workflow

1. Configure

   Create the wallet in the dashboard, set budgets, velocities, thresholds, alerting rules.

3. Fund

   Top up the wallet from an external wallet, the built-in on-ramp, or create a treasury multisig wallet.

5. Connect

   Copy the generated MCP config into the agent.

7. Operate

   The agent makes payments under policy. You monitor consumption live and can hit the kill-switch at any time.

A four-step setup: configure the wallet and policies in the dashboard, fund it, connect the MCP to the agent, then operate.

1. Configure

You create the wallet from the Keyban Dashboard and configure its policies — server-side, never visible to the agent. The smart account contract is provisioned at the agent's first MCP call. The Agent Passport is optional: once you publish your organisation's did.json (Keyban generates it during onboarding), every Agent Wallet inherits a Passport automatically.

2. Fund

You fund each Agent Wallet from any of the following sources:

• External wallet — send stablecoins or any supported token to the Agent Wallet smart account address, from Kraken, Gnosis Safe, or any wallet you already control.
• Built-in on-ramp — top up with a credit card directly from the dashboard.
• Treasury — if you maintain a Keyban treasury (warm multisig wallet), move funds from it to the Agent Wallet through a treasury transfer co-signed by your human signers.

The treasury hop is optional. Its main purpose is multi-person operational governance — funding decisions co-signed by several people in your organisation (typically a CTO, a finance lead, and an operations lead) instead of one account holder acting alone. For a single-operator setup, funding the Agent Wallet directly from an external wallet or the on-ramp is the simplest path.

3. Connect

From the dashboard, you copy the MCP configuration snippet into the agent's runtime (Claude Code, MCP-compatible orchestrators, custom Python or TypeScript runners). The first call sets up the wallet's signing capability — a one-time handshake that takes seconds.

4. Operate

The agent pays under policy. The dashboard surfaces every payment in real-time, with consumption against each budget, alerting on velocity breaches, and a list of intents pending human approval. If anything looks wrong, an instant kill-switch on the wallet stops every further payment — the smart account refuses any further co-signature request — until you re-enable it.

Operator controls

Concern	What you decide
How much the agent can ever spend	Per-day, per-week, per-month budgets, plus hard caps
When a human has to confirm	Threshold above which the dashboard requires manual approval before the payment goes through
What the agent can pay for	Optional allow-lists — by rail, by recipient category, by x402 endpoint domain
When to react	Email alerts on velocity and quota breaches
Emergency stop	Instant kill-switch on the wallet from the dashboard

The agent (LLM) cannot widen any of these levers per call. They are operator-side controls, applied server-side on every intent.

Where to go next

• Security architecture for Wallet for Agents — the deep dive on TSS, smart account, Policy Engine, relayer, and fiat rail security.
• x402.org — the protocol behind the machine-to-machine crypto path.
• Embedded Wallet (for end-users, not agents) — Keyban's wallet primitive for human customers.