OPEN CARDS · RULE SPEC v0.1
PROGRAMMABLE CARDS · YOU WRITE THE RULES
Every purchase answers to a rule you wrote.
Set up a card and write the rules it has to satisfy before a purchase goes through — whether an AI agent, a script, or you are the one spending. No business account, no underwriting, just a key. Fourteen declarative rule kinds, plus your own via webhook; every decision comes back explained rule by rule and kept on record.
REACTIVE · TAP THE CARD TO FLIP IT
THE RECORD — MISSION CONTROL
One place for every agent’s money.
Every agent gets its own card and budget. Every purchase runs through the rules and lands in one live log, with the reason attached. One dashboard, one kill switch, whether you’re running one agent or a hundred.
Stop one, or stop all.
Pause an agent or freeze the whole fleet in a single API call. It takes effect on the next authorization, not the next statement.
One agent can't touch another.
Each agent has its own card and envelope. A compromised or runaway agent is contained to its own budget — the rest keep working.
THE RULE SPEC
Fourteen rule kinds. The consumer tools stop at caps and locks.
Written as JSON against a published spec — no code for you to host or operate. Every kind is live in the engine and evaluated on every declared intent, with the reason attached to every decision. The consumer tools stop at spending limits, merchant or category locks, and a pause button; the infra players ship auth-time controls to program operators and leave the intent-level policy for you to build. Here it’s the product — and webhook_check lets you add your own rule the spec doesn’t cover.
THE DATA, END TO END
Follow one purchase through the Rule Spec.
This is the whole exchange for a $12.50 pizza order: what the agent sends, what the rules say, and what moves. Every payload below is the real API shape.
POST /intents
Authorization: Bearer ak_live_9f2a71c4_… # this agent's own revocable key
{
"card": "crd_9f2a71", # a handle, not a card number
"merchant": "Tony's Pizzeria",
"category": "food",
"amount_cents": 1250,
"reason": "friday team lunch"
}{ "kind": "merchant_lock", "config": { "allow": ["pizzeria", "doordash"] } }
{ "kind": "amount_ceiling", "config": { "max_cents": 3000 } }
{ "kind": "spend_cap", "config": { "max_total_cents": 20000, "window": "day" } }
{ "kind": "cooldown", "config": { "cooldown_sec": 300 } }
{ "kind": "approval_threshold", "config": { "above_cents": 2500 } }
+ a $200/day food envelope, deny-by-default→ 200 "status": "approved"
✓ merchant_lock 'Tony's Pizzeria' matches 'pizzeria'
✓ amount_ceiling $12.50 within $30.00 max
✓ spend_cap $12.50 of $200.00 day cap
✓ cooldown 412s since last purchase (≥300s)
✓ approval_threshold $12.50 at or under $25.00# the same agent, five minutes later, tries $41.20 at Delta:
→ 200 "status": "denied"
✗ merchant_lock 'Delta Air Lines' is not on the allow-list
✗ amount_ceiling $41.20 exceeds $30.00 max
# nothing is funded, nothing moves — see step 4The card idles at $0. On approval — once our BIN connection is live — APPEN loads exactly $12.50 onto it through the issuing partner, and checkout clears against that balance. The declined Delta charge was never funded, so there is nothing for it to clear against. The control plane enforces by controlling the money supply itself, purchase by purchase.
WHO TALKS TO WHOM
Three parties. Seven exchanges. One log.
Write the rules. The agent holds a card handle and its own revocable key, declares purchases, and reads explained decisions.
Decides every purchase against your rules, keeps the reason on record, moves exactly the approved amount, reconciles. Never stores a card number.
Bank-sponsored, Mastercard network. Holds the real card, runs KYC, clears network authorizations, reports transactions.
THE CARD NUMBER TRAVELS ON EXACTLY ZERO OF THESE SEVEN EXCHANGES.
PROOF · THE TERMINAL
$ appen: mission control without a browser.
The fleet, the rulebook, and the live authorization log in one terminal screen, running against the same API your agents use. Declare a purchase from the keyboard and read the per-rule verdict on the spot. Ships with your invite.
PROOF · THE API
Every card is one API call away.
APPEN is the control plane your agent’s card is programmed against. Commission a card, attach a rulebook, and connect over REST or MCP. When the agent wants to spend, it asks, and gets back a decision and its reasons, never the raw number.
- — One key per agent, revocable in one call
- — Rule evaluation returned on every authorization
- — The card number is never in the response
POST /v1/intents
{
"card": "crd_9f2a71",
"merchant": "Grainger Industrial",
"amount_cents": 124000
}
→ 200 OK
{
"decision": "approved",
"checked": ["merchant", "category", "ceiling", "velocity"],
"card_number_returned": false
}BY CONSTRUCTION · THE HANDLE
Your agent can spend it.
It can never see it.
The agent holds a handle, crd_9f2a71, and permission to request purchases. It never receives the card number, the CVV, or the expiry. APPEN holds the real credential and executes the payment, so a compromised or leaky model has nothing to leak.
THREE FUNDING PATTERNS · ONE RULE SPEC
One rulebook, three funding patterns.
Every pattern runs through the same engine: merchant, category, velocity, amount, and time-window rules you set per agent, enforced in the authorization window. Pick the funding model; the rules travel with it.
Intent gate
The agent declares what it wants to buy. APPEN checks it against your rules and approves, declines, or partially approves, before the card is ever charged.
Virtual card
APPEN issues a card scoped to a single agent, with its own envelope and merchant rules. Every swipe clears against the rulebook once our BIN connection turns on.
Auth hold
A refundable hold on an attached card proves the agent is acting for a real cardholder. No money moves until you release it.
WHO IT’S FOR
One agent for you. Or a fleet for your company.
It’s the same primitive at both ends: a weekend hack or a production system. You commission a card, write the rules, and connect the agent. The card does the rest.
The app that gets you pizza
Build a little agent that knows your order. Give it a card capped at $30 a meal and locked to food delivery. Say you're hungry and it buys, without asking twice and without ever holding your real number.
The agent that scales your infra
Point an agent at your cloud. Give it a debit card capped at $5k a month and locked to your vendors. When traffic spikes it provisions what it needs on AWS and tears it down after, every purchase logged with the reason.
WHY APPEN
Your credit card is the wrong tool.
Handing an AI agent your personal card means you have delegated the keys to your bank account without delegating any of the controls a real spender expects.
PLAIN ANSWERS
What is an agent spend firewall?
An agent spend firewall is a policy layer between an AI agent and a payment card: the agent declares what it wants to buy, and the layer evaluates the request against pre-authorized, user-directed rules and returns approved, denied, or parked for human approval, with the reason attached. APPEN is that layer, built as Open Cards — programmable cards where you write the rules, whether the spender is an AI agent, a script, or you; agents are the sharpest case. Every purchase is judged against a published Rule Spec (fourteen rule kinds plus webhook_check, your own rule) before any credential or dollar exists, and every decision is explained rule by rule and kept on record. You author the policy; the card carries it; the agent can't route around it.
Can I give an AI agent a credit card?+
You can paste a raw card number into a prompt, but that card carries no policy: the agent can spend anything, anywhere, and you find out afterward. The APPEN Card carries the policy with it. You write the rules, the engine evaluates every purchase server-side, and the agent never sees the card number. The rule engine is live today on declared purchase intents; card issuance is opening by invite as our BIN connection with a bank-sponsored issuing partner goes live.
How do I limit what an AI agent can buy?+
You write rules as JSON against a published Rule Spec: 14 rule kinds in five families, plus webhook_check — your own rule. Merchant rules (allow-lists, deny-lists, category codes), amount rules (per-purchase ceilings, rolling spend caps, per-merchant caps), cadence rules (cooldowns, frequency, lifetime uses, duplicate-charge guards), and time rules (allowed hours), plus human-gate rules and budget envelopes with rollover. Every purchase intent is checked against every rule, and any human gate can park a purchase for your explicit approval.
Is APPEN open source?+
No — and it doesn't need to be. The code is proprietary; what's open is access. The docs and the Rule Spec are public: anyone can read them and build against them, self-serve, without a sales call — the way Stripe's and Lithic's docs are wide open while their code stays closed. “Open” at APPEN means open to read and open to use — an open API, an open MCP server, and a versioned, public rule spec anyone can write their own rules against — not an open codebase.
Can my AI agent move real money today?+
Not yet, and we won't pretend otherwise. Live today: the rule engine (14 kinds + webhook_check), agent keys, the intent gate, explained and persisted decisions, REST, MCP, CLI, and a hands-on demo. Designed and not yet live: money movement, just-in-time funding, and card issuance, which open as our bank-sponsored issuing partner connects. The status band on the page says exactly where that line is.
Does the AI agent see the card number?+
No. The agent holds a card handle (crd_…) and a last-four. The full card number never appears in any API response the agent can reach; it sits outside the data model available to agent keys entirely. The agent can spend the card. It can never see it.
Is APPEN a bank?+
No. APPEN is a card product of Blind Billing LLC, a software company in St. Louis, Missouri. Cards are issued through a bank-sponsored issuing partnership on the Mastercard network. APPEN's role is the control plane: it evaluates the pre-authorized, user-directed rules you wrote on every purchase decision and keeps the record of each one.
What happens when an AI agent's purchase breaks a rule?+
The intent comes back denied or pending_approval, with a per-rule trace showing which rule failed and why (for example: amount $45.00 exceeds $30.00 max). Human gates park a purchase in an approval queue, and approving it re-runs every other rule, so approval is never a bypass.
WHERE WE ARE, PRECISELY
- — Rule engine — all 14 kinds + webhook_check, on every intent
- — Agent keys, handles — never card numbers
- — Approval queue, REST + MCP, CLI + TUI
- — Hands-on demo you can drive
- — Issued cards spending real money
- — The same rules executing inside the network authorization step
- — Via our issuing partner (bank-sponsored, Mastercard)
- — Card issuance for early businesses
- — Self-serve API access for individual builders
PRECISE HONESTY IS THE TRUST ARTIFACT. CLAIMS DATED 2026-07.
STAY IN THE LOOP
One email when money movement goes live.
Request a key to build against the Rule Spec today; leave your email and we will send one message when card issuance and real spend open. No newsletter, no follow-on marketing.
If you have a specific use case to discuss, the access form has more detail.