Spend broken down per agent and per model, so a runaway is attributable rather than a line on an invoice.
PLATFORM / CONTAINMENT
Contain runaway agent behaviour before it becomes an incident.
An agent that loops, runs past its window, or reaches somewhere it should not is stopped at the mediated enforcement point — before the call goes out, not reported after it landed. Four limits enforce live today. Two more are configurable and say plainly why they do not yet enforce.
Four limits enforced before the action reaches the target system Two stated as available, with the reason A cap can never be stored as enforced
Four limits evaluate on the governed path. A breach denies the action rather than recording that it happened — the run stops before the call reaches the target system.
4 enforced2 configurablestopped before the action lands
ENFORCED BEFORE THE ACTION LANDS
Four limits that stop a run.
These evaluate on the governed path. A breach denies the action rather than recording it.
Limit
What it stops
State
Connector allow/deny
A run reaching a connector it is not permitted to touch is stopped at the action boundary.
Enforced
connectorBusiness hours
An action attempted outside the permitted window does not proceed.
Enforced
business_hoursIteration cap
A loop that will not terminate is stopped at a declared iteration count.
Enforced
max_iterationsWall-clock cap
A run exceeding its declared duration is stopped rather than left running.
Enforced
max_wall_clockAVAILABLE, NOT ENFORCED
Two limits you can configure, and the exact signal each one is missing.
Both are real controls with real evaluation. Neither enforces at the live enforcement point yet, and the product says why in the operator's own console rather than leaving it to be discovered.
Limit
What it does
State
Cost budget
A daily spend cap on a run, configurable today and evaluated in the guard.
Available
cost_budgetMaker-checker
A run requiring two people. Holds the action at the action boundary and fails closed — what it cannot yet prove is that the approver was a distinct human.
Available
maker_checkerCost budget. “The gateway enforcement point carries no per-action cost or token signal, so the daily cost cap cannot be enforced live.”
Maker-checker. This one does hold the action. A real attestation mechanism is wired: the gate resolves the current window's attestation tier and pauses any action below the required tier, failing closed on error. It stays Available rather than Enforced for a stricter reason — the approval path cannot yet prove the acting authenticated voter was distinct from the maker under delegation, because only the post-delegation approver is recorded. A maker holding a delegation could self-approve and be recorded as a distinct delegate.
THE OBSERVABILITY LAYER
Spend is watched even where it is not yet stopped.
Cost governance is real and shipped — as attribution, forecasting and anomaly detection. What it is not yet is a live per-call cap, and this page does not blur the two.
Thresholds with alerting, so the spend curve is visible before it is a finance conversation.
Projected spend from observed governed activity.
Spend that departs from its own baseline, with severity and status.
STATED PRECISELY
A cap cannot claim to be enforced.
Stated precisely Whether a limit is enforced is derived on read from three facts — that it is configured, that a mediated enforcement point is present, and that the cap enforces at that enforcement point.
It is never stored. A cap cannot be persisted as enforced and then drift out of truth, and a configured cap on a loop with no mediated enforcement point reports Available rather than implying protection that is not there.
Honesty note
Six limits exist; four enforce. Saying “six controls stop a runaway agent” would be the exact overclaim the code is built to prevent — a test in the guard asserts that any cap which does not enforce at the action boundary must carry an operator-facing reason explaining why, so an unenforced cap cannot ship silently. The cost reason above is quoted verbatim from that mechanism. The maker-checker explanation is not — the mechanism's own string is stale, and what is written here reflects the live attestation path and its documented delegation limitation instead.
Cost enforcement and strict maker-checker proof are tracked work. Until they land, a spend cap tells you what happened after the fact. A maker-checker cap does stop the action — it holds it, fail-closed — and what remains unproven is only the distinctness of the second human, which is why it is reported Available rather than Enforced.