Introducing /cards: give your AI agent virtual cards with hard limits

An agent that can research, email, and file paperwork still hits a wall the moment it needs to pay for something. Naïve is the autonomous company infrastructure that gives agents real-world capabilities, and /cards is the primitive for spend: create a virtual card, fund it through checkout, cap it with a spending limit, assign it to the agents allowed to use it, and log every purchase. Your agent can actually buy things — and you can prove every charge.

Two card types

/cards offers two providers, and you pick per card:

• Prepaid gift card (prepaid_gift) — a prepaid Visa, $150 maximum, no cardholder required. This is the default and the fastest way to give an agent a small, hard-capped balance.
• Managed virtual card (managed_virtual) — a Visa or Mastercard with no spending cap, which requires a one-time cardholder to be created for the company for identity compliance.

If you omit the provider, you get a prepaid gift card. Reach for a managed virtual card when you need a higher limit or a reusable card credential.

How /cards works

The flow is a funded checkout, then issuance:

1. Create — naive cards create --name "Marketing" --spending-limit 10000 returns a checkout_url. The spending limit is in cents (minimum $1.00).
2. Fund & issue — open the checkout_url to pay (the session expires after 30 minutes), then naive cards check-payment <card_id> issues the card.
3. Reveal — once active, naive cards details <card_id> returns the full number and CVC for a managed virtual card, or a redeem code and PIN for a prepaid gift card.

This is the Company → Employee → Primitive model applied to money: the Company funds and owns the card, an Employee (agent) is assigned to it, and /cards is the primitive that binds spend to that agent.

Cardholder setup for managed virtual cards

Before creating managed virtual cards, create a cardholder once per company — this registers the identity information required for compliance. Prepaid gift cards skip this entirely.

naive cards create-cardholder \
  --first-name John --last-name Doe \
  --billing-line1 "123 Main St" --billing-city "San Francisco" \
  --billing-state CA --billing-postal-code 94105 \
  --dob-day 15 --dob-month 6 --dob-year 1990
 
naive cards create --name "Marketing" --spending-limit 10000 --provider managed_virtual
naive cards check-payment <card-id>

Fund the limit, top up when needed

A card can only ever spend what you have funded. The spending limit is set at creation and funded through checkout; to raise it, top-up returns a fresh checkout URL for the added amount.

naive cards top-up <card-id> --amount 5000

Because funding is explicit and up front, a misaligned agent can't spend past the balance you loaded — the cap is the money itself, not a policy an agent might talk its way around.

Assign cards to specific agents

Control which agents can spend by assigning cards explicitly:

# Assign an agent to a card
naive cards assign <card-id> --agent-id <agent-id>
 
# List who can spend on the card
naive cards assignments <card-id>
 
# Remove access
naive cards unassign <card-id> <agent-id>

Keep a clean audit trail

Record spend by logging transactions:

naive cards log-transaction <card-id> \
  --amount 2500 \
  --merchant-name "AWS" \
  --description "Cloud hosting payment"

Managed virtual cards also capture transactions automatically through payment webhooks, so manual logging is mainly for prepaid gift cards or offline purchases. List everything with naive cards transactions <card-id> for month-end reconciliation.

What you can build

Give each agent a hard-capped budget — Issue a prepaid gift card per agent so a researcher, a writer, and a distributor each spend inside their own funded limit, with no shared float to drain.

Run reusable spend on a managed card — For recurring cloud and SaaS bills, create one managed virtual card, assign it to the operations agent, and top it up as needed.

Isolate spend per tenant — In a multi-tenant app, give each customer's agents their own card and assignments, so spend and audit stay cleanly separated by tenant.

Reconcile from structured logs — Use the transaction log as the source of truth for burn rate and category-level spend, instead of reverse-engineering charges after the fact.

Use-case guides

End-to-end tutorials that use /cards in production:

• Corporate travel desk — per-trip virtual cards with approval gates
• Event bookings — venue deposits, tickets, and vendor payments
• Subscription spend — recurring SaaS billing per tenant

Get started

Drop this starter prompt into any coding agent to wire up Naïve:

Read https://usenaive.ai/skill.md and use it to set up Naïve in my project.

• Read the docs: usenaive.ai/docs/getting-started/cards
• Quickstart: usenaive.ai/docs/getting-started/quickstart
• Pair it with /kyc and /formation
• Join the community on Discord