Lion Cipher Lab

Put four agents and a human analyst on ONE shared incident case file, measure the writes that silently vanish, fix it twice - with compare-and-swap and then with a merge policy that knows what each field means - and price both fixes

• AI Security
• Advanced
• ~110 min
• Free · no account required

Why it matters

The moment you put more than one agent on one job, you have to decide where the shared truth lives, and the most natural answer - one case file everybody reads and writes - is also the one that fails quietly. This lab makes that failure concrete on a real cyber job: an enrichment agent, a timeline agent, a scoping agent and a human analyst, all building ONE incident case file during a live investigation. Stage one is the version everybody writes first: read the file, edit your copy, write it back. It loses 31 of the 47 contributions the four writers made on the walkthrough seed and a mean of…

What you'll learn

• defining a BLACKBOARD precisely - one shared mutable record that several agents read from and write to, instead of passing messages to each other - and building one in pure Python that four writers and a human analyst genuinely fight over
• writing a SEEDED INTERLEAVING SCHEDULER so a concurrency lesson is reproducible: the same seed gives the same 62-event trace on any machine, which is the only way a lab about race conditions can print numbers you are able to check
• measuring a LOST UPDATE instead of describing one - 31 of 47 contributions gone from the finished case file on the walkthrough seed, and a mean of 29.3 across 200 interleavings, with not one of the 200 keeping all 47
• testing a case file for INTERNAL CONSISTENCY with invariants that need no answer key, and finding a file that names four hosts in its timeline while listing none of them as in scope
• implementing OPTIMISTIC CONCURRENCY CONTROL with a version number and a compare-and-swap, taking lost updates to zero across all 200 interleavings, and then pricing it honestly at 2.19x the write attempts and 2.36x the wall clock
• measuring the RETRY STORM on both of its knobs and finding that the number of concurrent writers is the one that matters - 2.38 to 5.37 attempts per operation going from four writers to twelve - while making the agents slower barely moves it at all
• building a merge policy that is aware of the TYPE OF EACH FIELD: grow-only sets for evidence and hosts, a counter stored as a set of tagged increments, min and max registers for timestamps, last-writer-wins registers for the scalars where that is genuinely correct, and an explicit escalate-to-human class for the field where it is not
• proving with numbers that an analyst's manual severity downgrade is silently overwritten 591 times across 200 runs under plain last-writer-wins, and that neither compare-and-swap nor a single-writer queue fixes it, because it is not a concurrency bug
• knowing the cost of a grow-only set - it cannot retract - and choosing between a G-set, a two-phase set and an observed-remove set on the merits, with the incident-response consequence of each spelled out
• the judgment to say when a blackboard is the right shape, when message passing or a single writer is better, and when the honest answer is that your team should not be sharing that field at all

Steps in this lab

1. The words first: blackboard, lost update, invariant, compare-and-swap, CRDT, grow-only set, last-writer-wins - and why the concurrency here is simulated
2. Open a terminal and make a scratch folder (all three operating systems)
3. The cyber job: one incident, four writers, and exactly what each of them intends to write
4. The blackboard, the seeded scheduler, and the scorer - the one module everything else imports
5. Prove the interleaving is reproducible, then watch a lost update happen
6. Stage 1: naive read-modify-write, and the case file that argues with itself
7. Why 'internally inconsistent' is a worse outcome than 'incomplete'
8. Stage 2: give every record a version, compare-and-swap on every write, retry on conflict
9. The retry storm: what optimistic concurrency costs when the bet stops paying, including the sweep that surprised me
10. Stage 3: stop arbitrating writes. Merge them, by the type of the field
11. The failure that matters: a human downgraded the incident and a machine overwrote her
12. The bill for stage 3: a grow-only set can never take anything back
13. The headline: five architectures, the same 31 operations, all 200 interleavings - including the baseline nobody runs
14. When you would reach for a blackboard, when for message passing, when for a single writer - and when for none of them
15. What this lab does NOT prove, and how to swap the simulation for real threads
16. The way a pro does it differently

Open the full interactive lab →