# Kordio

> Kordio is the control layer for AI agents that transact. Before an agent pays a vendor, buys on a marketplace, books a trip, or calls a paid tool, it asks Kordio, which evaluates that action against policy the customer wrote and answers in the same request: allowed, requires approval, or denied, naming the rule that decided and reporting the headroom left on every limit. Every allowed decision returns a short-lived signature so whoever executes the action can verify the authority offline rather than trusting the agent. Kordio holds no funds, no accounts, and none of the customer's credentials: it is a required signer, never a custodian. Kordio also runs a double-entry ledger: a separate, live product that keeps balanced books for agent and machine spend, with reconciliation, period close, financial reports and multi-currency support. The two are sold separately. Mirroring control-layer decisions into the ledger is not switched on yet. The control layer is in early access with published pricing and self-serve signup, metered on live authorized dollars a month, from a $0 test-mode sandbox through Build at $49/mo, Growth at $149/mo and Scale at $499/mo to Enterprise on quote, with prepaid volume packs as an alternative to a monthly tier.

## The control layer

- [What it does](https://kordio.io/#control): An action is a agent, a session, an action type, a resource, and a cost. `POST /v1/agent/actions` returns 201 allowed, 202 requires approval, or 403 denied, and requires an idempotency key. `POST /v1/agent/actions/simulate` runs the identical evaluation while reserving nothing and recording no intent.
- [Not just payments](https://kordio.io/#agentic): The same engine governs any action type, a dotted string such as `payment.create`, `order.place`, `booking.create` or `tool.invoke`, and it is tied to no payment rail: Kordio never executes the action, so nothing in the model assumes a card, a bank, a chain, or a marketplace on the other side. This is what makes it usable for agentic commerce generally rather than payments only. A agent's caps, spend windows, monthly ceilings, rate limits, and counterparty allowlists apply across all of them together, so spend on one consumes headroom for the other.
- [Features](https://kordio.io/#agentic): Agent identity (a scoped identity per agent workload, with per-action-type scopes), the policy engine, session budgets delegable to sub-agents, single-use spend tokens (bound to one amount ceiling, one counterparty, one expiry), simulate, human-in-the-loop approvals delivered over webhooks, provenance (a trace id and full decision context, append-only and replayable), and workspace roles that keep approving separate from writing policy. Single-use spend tokens are one feature of the layer, not a synonym for it.
- [The policy language](https://kordio.io/#policy): Policy is data, not deployed code. Typed rule kinds cover action allowlists, resource allowlists, cost caps, spend windows, monthly spend caps, rate limits, and approval thresholds. A `condition` rule is the open one: a boolean expression over the action combined with `all_of`, `any_of`, and `not`, matching on action type, resource, cost, currency, agent, session, or any metadata path, with an effect of deny, allow, or require approval. It validates on write rather than when an agent is waiting, always terminates, and diffs in review. Policies are blocklist by default and can be flipped to allowlist. Named modules are reusable rule sets imported by policies.
- [Cosigning](https://kordio.io/#cosign): An allowed decision returns a compact JWS over the agent, session, action, resource, amount, and currency, expiring in minutes. Verify it against `GET https://api.kordio.io/.well-known/jwks.json` with no call back to Kordio and no shared secret. ES256 on P-256, so any standard JWT library checks it in any language. `POST /v1/cosign/verify` is the stateful check that refuses an authorization already settled, so an authorization is good for a single execution. This makes Kordio a required signer without making it a custodian.
- [Ledger](https://kordio.io/ledger) (live, sold separately): a double-entry ledger API for agent and machine spend. Balanced postings, atomic multi-account moves, an append-only journal, reconciliation against processors, financial reports, period close, multi-currency across fiat, stablecoins and crypto, idempotent transactions and replayable webhooks. It is a standalone product with its own plans, not a feature of the control layer.

## Product

- [Homepage](https://kordio.io/): What Kordio is, how one decision works, the object model (agent, policy, session, decision), the policy language, cosigning, and how the ledger fits underneath.
- [Pricing](https://kordio.io/#pricing): Agent control layer, metered on live authorized dollars a month, never on a count of API calls or decisions, and a denial is not billed: Sandbox ($0, test mode only, 10 agents), Build ($49/mo, $100,000 included), Growth ($149/mo, $500,000 included), Scale ($499/mo, $2,000,000 included), Enterprise (custom, for volume past self-serve). Prepaid volume packs are an add-on rather than a tier: $50 adds $100,000 of authorized volume to any plan, good for 12 months. Agents and teammates are unlimited on every paid tier: volume is the only boundary. Build covers you to about $265,000 a month, Growth to about $1.4M, Scale above that. The implied rate falls from about 5 basis points at Build to 2.5 at Scale. Sandbox is test mode only: there is no free live allowance, and live authority needs a card. More volume can be bought at any time as a prepaid pack. A billing problem never blocks an authorization for a paying customer.
- [Pricing](https://kordio.io/pricing): Both ladders on one page. Agent spend control metered on live authorized dollars a month with denials never billed, from a $0 test-mode sandbox through Build at $49/mo, Growth at $149/mo and Scale at $499/mo to Enterprise on quote, with $50 prepaid packs adding $100,000 of authorized volume to any plan for 12 months. The ledger is priced separately on postings a month. Nothing is gated by tier: every policy kind, cosigning, approvals and the audit trail are in the free sandbox, and tiers buy volume rather than features.
- [Free tools](https://kordio.io/tools): Three client-side tools that are useful whether or not anyone buys anything.
- [Guides](https://kordio.io/guides): Durable technical guides rather than a blog, each one stating where its advice stops being true.
- [Developers](https://kordio.io/developers): Quickstart for both APIs, the policy language, and the guarantees engineers care about: idempotency keys accepted in header or body, dry runs on every write, errors that carry a hint naming the next step, request ids in the response body, and cosignatures any standard JWT library verifies offline.
- [Documentation](https://docs.kordio.io/): API reference for agents, policies, sessions, actions, payment intents, approvals, cosigning, and webhooks, plus the ledger API.
- [App / Sign up](https://app.kordio.io/): Create a free sandbox workspace, no card.

## Use cases

- [Refund and payout authority](https://kordio.io/use-cases/refund-and-payout-authority): The place teams start, and it needs no AI at all. Support tooling and marketplace operations release money every day with no human deciding each one, the ceiling is whatever the API allows, and nobody can answer afterwards who authorized a release. Action types are dotted strings such as `refund.issue` and `payout.release`, so no payment rail has to be adopted to gate them. Recommended first because the leakage number usually already exists in finance and has a named accountable owner.
- [AI agent spending limits](https://kordio.io/use-cases/ai-agent-spending-limits): One envelope across model calls, paid tools and real payments, held outside the agent so the agent cannot raise it, drawn down by every run and every sub-agent rather than each inheriting the full ceiling. Provider-level caps do not sum across providers, in-process checks ship inside the thing they constrain, and cost dashboards report rather than deny.
- [Build vs buy a financial ledger](https://kordio.io/build-vs-buy-ledger): An honest decision guide that states when building in-house is correct (one currency, one product, no auditor, discrepancies fixable by hand) and the five signals it has run out (balances held for another party, a second currency or rail, a balance asked for as of a date, a retry that paid twice, the author leaving). Names the eight things that cost more than the schema: balanced writes under concurrency, idempotency across retries, reconciliation against what actually cleared, point-in-time history, corrections as reversals rather than edits, per-currency balancing, period close, and the reports finance asks for.

## Free tools

All three run entirely client-side with no account, no email wall and no upload, which for financial data is the only acceptable answer.

- [Reconciliation drift checker](https://kordio.io/tools/reconciliation-drift-checker): Paste a processor export and your own records as CSV and it reports the breaks in your numbers, in your browser. Classifies three break types: a reference the processor has and you do not, one you have and they do not, and one both have with different amounts. States its own limit plainly, that it compares two flat lists on one key and cannot net many-to-one settlements, split payouts or period-boundary timing differences.
- [Agent spend policy generator](https://kordio.io/tools/agent-spend-policy-generator): Four questions produce a policy the API actually accepts, with the rule kinds spend_window, cost_cap, action_allowlist, resource_allowlist and approval_threshold, plus the curl to test it. Warns when the inputs contradict each other, for example an approval threshold at or above the per-action cap, which means nothing would ever reach a human because the cap refuses it first.
- [Ledger build-cost estimator](https://kordio.io/tools/ledger-build-cost-estimator): Engineering-months estimate for building a double-entry ledger, itemised across the eight parts harder than the schema, scaled by currencies, rails, whether balances are held for other parties, and whether you are audited. Says on the page that it is a judgement rather than a study, shows every base figure and multiplier so they can be disagreed with, and excludes running it.

## Guides

- [Moving from a balances column to a double-entry ledger](https://kordio.io/guides/migrate-to-a-double-entry-ledger): The safe path off a stored balance, in five phases with no big bang: funnel every writer through one function, dual-write while the old column stays authoritative, backfill behind a cutoff as one opening balance per account rather than replaying years of rows, run a drift-comparison job in production for a full close cycle, then flip the read and keep the old column one more cycle. Names the five disagreements a comparison job actually finds, including movements with no counterparty and the support tooling that writes balances directly.
- [How idempotency actually works in financial transactions](https://kordio.io/guides/idempotency-in-financial-transactions): Retries are the easy part. Defines the five cases that must be decided up front (same key same body first time, replay, same key different body, still in flight, new key identical body) and the five failure modes that all look like working code: keys generated per attempt rather than derived, keys with no lifetime, keys scoped globally instead of per account, and read-then-write uniqueness checks that let concurrent duplicates through. A key reused with a changed body must be a loud error, never a silent replay.
- [How to give an AI agent a spending limit it cannot raise](https://kordio.io/guides/ai-agent-spending-limit): Why provider caps do not sum across providers, an in-process check ships inside the thing it constrains, a card ceiling never sees the paid API call, and a cost dashboard reports after the money is gone. The five properties a real limit needs: held outside the agent, shared across the whole run, delegable without multiplying across sub-agents, spanning every action type against one ceiling, and producing evidence an executor can verify.

## Comparisons and definitions

- [What is an agent control layer](https://kordio.io/agent-control-layer): An agent control layer is a service that sits in front of an AI agent's actions and decides, before each one runs, whether that agent may take it. What one has to do (decide before rather than report after, hold budget state across runs outside the agent, govern any action type rather than payments only, return something an executor can verify, and name the rule months later), and what gets called a control layer and is not: content guardrails validate what a model says and hold no budget; spend dashboards report and alert rather than deny; agent identity settles who is calling, which is necessary and not sufficient. States the honest limit plainly: a control layer only binds the paths you route through it.
- [Versus card limits](https://kordio.io/agent-spend-controls-vs-card-limits): A virtual card limit stops one transaction that is too big, and it is real enforcement that holds even if your own systems are compromised. It does not see the same reasonable-looking charge repeated nineteen times, each individually under the limit; it never sees the paid API call that is not a card transaction at all; sub-agents each inherit the full per-transaction ceiling; and a decline code is not a reason. Kordio runs before the rail and applies caps, windows, rate limits and allowlists across payments and tool calls together. Keep both: the card is the floor, the control layer knows what the agent was doing.
- [Versus an if statement in your orchestrator](https://kordio.io/agent-controls-vs-your-orchestrator): `if amount > 500` in your orchestrator is real enforcement and the honest competitor to this product. For one agent, one ceiling and nobody asking who approved what, keep it. It also lives inside the thing it constrains, so whatever compromises the agent compromises the check, changing a limit needs a deploy, every new agent rewrites it, sub-agents inherit the full ceiling, and nothing outside can answer why. The value of moving it out is not that the logic is better, it is that the logic is somewhere the agent cannot reach.
- [AP2, ACP and MCP](https://kordio.io/agent-payment-protocols): AP2 and ACP standardize how an agent proves who it is at checkout, and MCP standardizes how an agent reaches a tool at all. Each scopes a single transaction on a single rail, and none of them holds a budget across runs spanning payments and tool calls together. They authenticate; Kordio authorizes, and runs first. Kordio does not implement these protocols today.

## Industries

These pages cover the ledger product by industry. The ledger is a live, standalone product with its own plans; the agent control layer is sold separately.

- [Fintech](https://kordio.io/industries/fintech): Ledger, reconciliation, and reporting for fintechs moving real money in production.
- [Payment service providers](https://kordio.io/industries/payment-service-providers): Reconcile against processors and settle balances with an auditable journal.
- [Trading & investments](https://kordio.io/industries/trading-investments): Multi-asset balances and period close for trading and investment platforms.
- [Web3 & crypto](https://kordio.io/industries/web3): On-chain and off-chain balances in one journal, token symbols as currencies.
- [Cross-border trade](https://kordio.io/industries/cross-border-trade): Multi-currency ledgering for cross-border money movement.

## Company

- [About](https://kordio.io/about): The team behind Kordio.
- [Privacy policy](https://kordio.io/privacy-policy)
- [Terms and conditions](https://kordio.io/terms-and-conditions)