Lion Cipher Lab
Detect a stuck agent's repeating tool-call loop with state fingerprints, without killing legitimate polling
- AI Security
- Advanced
- ~90 min
- Free · no account required
Why it matters
An AI agent that hunts threats or works incidents runs in a loop: think, call a tool, read the result, think again. Sometimes that loop gets stuck. It asks the SIEM the same question over and over. It flips between two tools forever. It keeps asking for page one of the results because its cursor keeps resetting. Each turn costs tokens, time and API quota, and while it spins it is not doing the investigation you needed. The usual safety net is a step budget - stop after 60 calls - and the fleet-governance lab shows how to meter and cap that spend. But a budget only stops a loop at the end,…
What you'll learn
- building 200 answer-keyed tool-call traces from a stub threat-hunting agent - 130 healthy runs that poll, page and sweep, and 70 stuck runs in four shapes: exact repeat, near-repeat, ping-pong cycle and slow drift
- writing a state FINGERPRINT for a tool call: canonical JSON of the arguments with volatile fields (timestamps, request ids, nonces) stripped, hashed with SHA-256
- detecting a loop online, one step at a time, with a sliding-window repeat counter and with cycle detection over fingerprints (a block of 1 to 4 calls repeated three times)
- making the fingerprint progress-aware by folding in a hash of the tool RESULT, which kept the catch rate at 60/70 and cut false trips on legitimate polling from 30/130 to 0/130
- scoring a loop detector on four numbers at once - loops caught, steps of latency, tokens wasted, healthy runs killed - instead of quoting a catch rate alone
- showing with numbers what fingerprints cannot catch (a slow drift whose arguments never repeat), adding a no-new-result backstop with a stated threshold, and measuring the false trips that over-normalizing a real argument causes
Steps in this lab
- The words first: agent loop, trace, stuck loop, fingerprint, volatile field, cycle - and the fact that the agent is a stub
- Open a terminal, check Python, make a scratch folder (Windows, macOS, Linux)
- One-step recap: what the fleet-governance lab already gives you, and what it cannot see
- Build 200 keyed traces: 130 healthy runs and 70 stuck ones
- Write the four detectors and watch the fingerprints on two tiny runs
- Measure: loops caught, latency, tokens wasted, and healthy runs killed
- Read it honestly: D2 kills healthy polling, and D3 does not fix everything
- The negatives with numbers: slow drift, a backstop that has its own price, and over-normalizing
- Why this, not that - and when NOT to use a loop detector
- The way a pro does it: per-tool rules, a soft trip first, and the trip as a logged event
- Ship it: wrap the detector around your own agent loop, then break the stub on purpose