The control layer ยท Definition
Definition
The check runs in the path of the action and returns in time to stop it. Anything that tells you afterwards is a record, and a record binds nothing that already had the means to act.
A ceiling on one transaction is not a budget. Knowing that this agent has $340 left this month means keeping a running total across runs, sessions and sub-agents, outside the process being limited.
A paid tool call is spend. If the layer only understands card transactions, the largest line on an agent operation is invisible to it, and limits on one kind of spend do not constrain the other.
A decision only the agent carries is a claim. A signature over exactly what was permitted lets whoever executes check the authority without calling back and without trusting the caller.
Months afterwards, someone asks who approved a payment. The answer has to be a rule and a decision on record, not a code review from six weeks ago.
The shape of it
An agent, a session, an action type, a resource, and a cost. Described before it happens, not reported after.
Caps, windows, allowlists and approval thresholds evaluate together, and the first rule that decided is the one named in the answer.
An allowed decision comes back signed and short-lived, so the executor verifies the authority offline instead of taking the agent's word.
Not this
Position
A control layer only binds the paths you route through it. An executor that never asks Kordio and never verifies a signature is not governed by it, and no amount of policy changes that. This is worth knowing before you buy, from anyone.
The mitigation is the next sentence: put the check in front of the spend, in code the agent cannot skip, and have the executor require a signature. Once it does, an agent that skipped the check has nothing to present.
Every decision is recorded in an append-only audit trail, linked by trace id, on every tier. See what comes back
{
"decision": "allowed",
"rule": "cost_cap.vendor_payments",
"remaining_cents": 34000,
"cosignature": "eyJhbGciOiJFUzI1NiJ9..."
}Terms
No. Guardrails usually validate content: what a model says. A control layer decides actions, holds budget state across runs, and returns a decision an executor can verify.
No. Those report what was spent after the fact. A control layer answers before the action runs, and a denial means the spend never happened.
Probably not. A hard-coded cap in your own code is fine for one agent with one ceiling. The trigger is the second agent, or the first time someone asks who approved a payment.
It is not governed. A control layer binds the paths you route through it, which is why the executor should require a signature rather than trusting the caller.