Gate a real charge in test mode.
Sandbox keys in five minutes, no card, running the same policy engine as live mode. Live tiers from $49/mo.
The control layer ยท Versus card limits
Where it holds
Spend controls on a card or a virtual account are real enforcement, not advice. The issuer declines the charge whether or not your code is healthy, whether or not the agent cooperates, and for a single ceiling that is genuinely enough.
It is also the thing standing between you and an agent that bypasses everything else. Kordio holds no funds and declines nothing at the rail, so if something skips the check entirely, the card is what is left. That is a reason to keep it, not to replace it.
Every decision is recorded in an append-only audit trail, linked by trace id, on every tier. See what comes back
Blind spots
Each one is under the limit and each one is approved, correctly. Nothing at the rail is counting how many times this agent has already made this same purchase today.
Model calls, enrichment APIs, search credits, freight quotes. The card cannot decline what never reaches it, and on many agent operations that is the larger number.
One orchestrator spawns twenty sub-agents on the same card. Each inherits the full per-transaction limit, because a card has no notion of a budget being shared and drawn down.
Afterwards you have a merchant, an amount, and a timestamp. Which agent, under whose authority, against which rule, with what headroom left, is not something the rail ever knew.
In front of the rail
{
"action_type": "payment.create",
"resource": "supplier.example.com",
"cost_cents": 42000,
"currency": "USD",
"session_id": "ses_01HXKJZM2"
}{
"decision": "denied",
"rule": "rate_limit.supplier_repeat",
"remaining_cents": 0,
"trace_id": "trc_01HXKJZM2Q"
}An action type is a dotted string like payment.create or tool.invoke, and an agent's caps, windows, rate limits and allowlists apply across all of them together. Spend on the model bill consumes headroom for the supplier payment, because it is one budget rather than two systems that never speak.
Anything over a threshold is held for a person instead of declined outright, and every allowed decision comes back signed, so whoever executes verifies the authority rather than trusting the agent.
See a full decision →Running both
What comes up next
No. Kordio holds no funds and issues nothing. Your cards keep working exactly as they do now, and the check runs before the charge is made.
Good, keep it. It is the floor under everything. What it cannot see is the same charge repeated, or the paid API call that is not a card transaction at all.
Closer, and still per rail. One card per agent does not know what that agent spent on model calls, and a new card per task is its own operational problem.
The card limit is what stops it, which is why you keep both. Kordio governs the paths you route through it, so the executor should require a signature.