Introducing /cards: Give your AI agent a bank account and virtual cards

Today we're launching /cards — the primitive that gives an AI Employee real purchasing power. Virtual cards on the Visa network, a real Column-backed bank account, per-Employee spend policy, and mandatory transaction logging the agent can't skip. The result: your agent can actually buy things, and you can prove every charge.

The problem: agents need money, but money has KYC

A non-trivial autonomous business needs to spend. Cloud bills, software licenses, inbound leads, ads, contractor payments. The status quo here is bleak:

• A shared corporate card the agent uses — every transaction is your transaction, auditing is a nightmare, and one runaway prompt drains your float.
• A wallet abstraction (Plaid, Wise, crypto on-ramp) — closed loop, declined at most merchants, and no real bank account behind it.
• DIY Stripe Issuing — works for cards but you're now building a bank ledger, identity binding, and spend controls from scratch. Six months of work.

The reason it stays hard is that real money has real KYC. You can't just hand a card to "the agent" — somebody has to be the cardholder of record, and that somebody has to have passed identity verification. Every existing primitive fails on one of those two requirements.

Until now. With /cards, the cardholder is a /kyc-verified Employee, the issuing entity is the /llc-formed Company, and the card is a runtime object an agent can actually use.

How /cards works

The workflow is three steps:

1. Create — naive cards create --name "Marketing Card" --spending-limit 10000 returns a checkout_url for funding. Naïve creates the card on Stripe Issuing with the specified spending limit.
2. Fund & Issue — open the checkout_url to complete payment. Then run naive cards check-payment <card_id> to issue the card. Once active, naive cards details <card_id> returns the full PAN, CVC, and expiry.
3. Log — after every purchase, call naive cards log-transaction <card_id> --amount <cents> --merchant-name "..." --description "...". This creates an auditable paper trail for every transaction.

This is the Company → Employee → Primitive model in its strictest form: the Company holds the bank rails, the Employee holds the card, and /cards is the primitive that binds them.

Two ways to issue a card: prompt or code

1. Natural language

naive cards create \
  --name "Marketing Card" \
  --spending-limit 50000

The CLI creates the card, returns a checkout_url for funding, and prints next steps including naive cards check-payment to issue the card after payment.

2. Code

const res = await fetch("https://api.usenaive.ai/v1/cards", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.NAIVE_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    name: "Marketing Card",
    spending_limit_cents: 50000,
    provider: "stripe_issuing",
  }),
});
const { card, checkout_url } = await res.json();
// checkout_url — open to fund the card
// card.id — use with check-payment after funding

After funding, call POST /v1/cards/:id/check-payment to issue the card. Once active, GET /v1/cards/:id/details returns the full PAN, CVC, and expiry — use the credentials at any Visa-accepting merchant.

Spend controls and per-Employee limits

Every card has a policy object the runtime enforces at swipe time:

{
  monthlyLimit: 50000,           // cents
  dailyLimit: 10000,
  perTransactionLimit: 5000,
  allowedMccs: ["5734", "5818"], // optional allowlist
  blockedMccs: ["7995"],         // explicit blocks (gambling, etc.)
  velocity: {
    maxPerHour: 5,
    maxPerDay: 20,
  },
  geoFences: ["US"],
}

A swipe outside these bounds is declined at the network — there's no way for the agent to "try again harder." This is the safety surface that makes /cards deployable in production: even a misaligned agent can't drain the account.

Mandatory transaction logging

Every purchase the Employee makes must be followed by log_card_transaction:

naive cards log-transaction <card_id> \
  --amount 4800 \
  --merchant-name "Linear, Inc." \
  --description "Q2 engineering subscription, approved by ops loop"

If the Employee doesn't log the transaction within the configured window (default 24 hours), the card is auto-frozen and a webhook fires. This is the runtime guarantee that makes spend audits actually work — you can't have an agent that purchases without leaving a paper trail.

Real bank accounts, not closed-loop wallets

Behind every Company is a Column-backed FDIC-insured bank account that supports ACH, wires, and card settlement. Money moves like real money:

• Funded via ACH from your operating account.
• Outbound ACH and wires for paying contractors and partners.
• Card spend settles to the same account.
• Statements available as Document objects on the Company — the agent can read them.

This is why /cards works for actual businesses, not just demos. The bank account is the Company's, the card is the Employee's, and the ledger is yours to query.

What you can build with /cards

Run a per-Employee budget for an autonomous content brand — Issue a $200/month card to the writer Employee, a $1k/month card to the distributor Employee, and a $50/month card to the researcher Employee. Each operates independently inside their bounds.

Pay vendors from a real bank account, not a wallet — Schedule recurring ACH payments for cloud bills, contractor invoices, or affiliate payouts. Compose with /credentials to keep vendor portal logins and with /email to receive invoices.

Sandbox a high-risk experiment with a hard cap — Issue a $50 one-time card to a new Employee testing a new tool. The card auto-expires after the spend; the experiment can't bleed into your runway.

Issue cards bound to a real human cardholder of record — Pair /cards with /kyc so cards aren't refused at high-risk merchants — every card has a verified principal, the same way Stripe Issuing requires for human-operated platforms.

Build agent-native expense management — Use the structured log_card_transaction data as the source of truth for monthly P&L, runway, and category-level burn rate.

Get started

• Read the docs: usenaive.ai/docs/guides/payments
• Quickstart: usenaive.ai/docs/getting-started/quickstart
• Background reading: Stripe Issuing (the underlying card rails) and Column (the underlying bank).
• Join the community on Discord