Lion Cipher Lab

Govern an agent fleet with budgets and circuit breakers — hard-stop a 3am runaway loop and measure what the stop costs you

• AI Security
• Intermediate
• ~90 min
• Free · no account required

Why it matters

At 03:14 one of your alert-triage agents gets a tool result it does not understand, re-plans, gets the same result, re-plans again, and keeps doing that. Nothing is broken enough to page anyone. No exception is thrown. The task simply never ends. At 09:00 somebody opens the billing console. This is the single most common way an agent fleet hurts a team, and it has nothing to do with security: there is no attacker, no prompt injection, no hostile input. There is a bug, a loop, and an absence of any number that says stop. On the fleet in this lab, one buggy task burned 18.5 million tokens, 423…

What you'll learn

• building a BUDGET LEDGER with three independent meters (tokens, wall-clock seconds, tool calls) at three scopes (per-task, per-agent-role-per-day, per-fleet-per-day) and enforcing all nine as HARD STOPS rather than warnings you read in the morning
• measuring DETECTION LATENCY per meter — which one trips first on your failure, and exactly how much money is already gone when it does — instead of assuming that a limit which exists is a limit that works
• proving the single most common budget bug in production: a token meter checked once per task never fires against a runaway, because a runaway is by definition a task that does not finish (measured here as the difference between $0.11 and $78.67)
• sizing budgets from the workload's own measured p95 per role instead of one flat number, and quantifying the legitimate work a too-tight budget kills mid-flight — the tokens you paid for and threw away, because a hard stop with no checkpoint keeps nothing
• writing a real CIRCUIT BREAKER with all three states (closed / open / half-open), a documented trip condition, a recovery probe and an exponential cooldown — then measuring the cooldown overshoot, when the breaker keeps protecting a dependency that recovered 390 seconds ago
• scoping a breaker correctly: measuring the AVAILABILITY COST of your own safety control when one bad dependency trips the whole fleet and alert triage stops for everyone (100 alerts delayed past ten minutes, versus zero with a per-dependency breaker)
• admission control as an engineering discipline: refusing a task at step zero when it provably cannot fit, and measuring the work-lost difference against killing the same task halfway through
• the judgment to know what hard limits CANNOT catch — the slow leak that stays under every threshold forever — and building the rate-of-change monitor that catches it five nights earlier

Steps in this lab

1. The frame: nobody is attacking you, and that is the whole point
2. Open a terminal, check Python, make a scratch folder
3. Build the fleet — and read the paragraph about stubs before you paste anything
4. Night one, ungoverned: what one buggy task costs while everyone is asleep
5. The budget ledger: three meters, three scopes, nine hard stops
6. Night two, governed — and the flat budget that quietly shredded five real jobs
7. Detection latency: which meter trips first, and the check that never runs at all
8. Admission control: the cheapest kill is the one at step zero
9. The circuit breaker, with all three real states
10. The outage: three scopes for the same breaker, and the availability cost of your own safety control
11. The tradeoff curve: tighten the budget and you start executing your own work
12. The runaway your hard limits structurally cannot catch
13. When NOT to build this — and why a hard stop, not a warning or a rate limit
14. The way a pro does it

Open the full interactive lab →