A team that reads Lessons 3 and 4 and concludes their guardrails are probably fine has learned nothing actionable — 'probably fine' is not a claim anyone can check, deploy against, or catch a regression in six months from now when someone tweaks the system prompt. What actually moves a team from hoping to knowing is the same discipline every mature security practice depends on: a suite of concrete, runnable test cases that codify exactly which attacks the system is supposed to resist, run automatically, every time the system changes.
A prompt injection test suite is not fundamentally different from any other regression test suite — it has cases, each case has an input and an expected outcome, and a harness runs every case and reports which passed. What is specific to this domain is what counts as a case (a payload targeting a named injection technique from Lesson 3) and what counts as passing (the system did not leak the system prompt, did not take an unauthorized action, did not follow the embedded instruction) rather than a simple string match.
This is an exercise lesson: every code block below is something to actually run, in order, building toward a complete, working test harness by the end. Each new block extends what the previous one built, the same way a real test suite grows incrementally rather than arriving fully formed.
Analogy🏏Cricket
🏏 Think of it like cricket: A fast bowler does not walk into a Test match hoping his yorker works under pressure; the coaching staff has run him through a specific, repeatable session weeks earlier — twenty balls at a single stump, scored automatically by ball-tracking, with a clear pass threshold of hitting the target zone at least sixteen times before he is trusted with the responsibility in a live death-overs situation. That session is not a vague sense of readiness, it is a concrete, repeatable test with a named target, a scoring method, and a threshold, and it gets run again after any change to his action, a tweaked run-up, a recovering niggle, before anyone trusts the skill again. A bowler who only ever bowled yorkers in unscored, informal net sessions would have no way to know if a technical tweak quietly broke what used to work, until it failed in a match that actually mattered. Just as the single-stump drill turns 'his yorker is probably good' into a scored, repeatable, sixteen-out-of-twenty result, a prompt injection test suite turns 'our guardrails are probably fine' into a scored, repeatable pass count. Just as the drill gets rerun after any change to the bowler's action, the test suite gets rerun after any change to the system prompt or guardrail code. The insight is that a skill nobody has scored with a repeatable test is a skill nobody actually knows the reliability of.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.