Module 8 · 7 min read
Professional Practice: Scoping, Measurement and Reporting
Rules of engagement for testing a live system, how to make an attack success rate interpretable, and the artefact set that makes a finding actionable.
The difference between an exercise that changes a system and one that produces an anecdote is almost entirely procedural. Testing a production assistant with live tool access means operating inside a system that can send messages, move money, change records and touch real people's data. The rules of engagement are not bureaucracy: they are the reason the exercise is lawful, safe and useful, and they are the first thing a competent client asks for.
- Get authority in writingA named authorising officer with actual authority over the systems in scope, agreed test windows, and the legal position on any third-party service the testing will touch.
- Draw the scope around the system, not the modelInclude the surrounding application, the tools, retrieval sources and data flows. Most exploitable risk lives there, so a model-only scope inverts good scoping and produces findings nobody can act on.
- Decide what must not happenAgree which actions are irreversible and either exclude them or confine them to a designated test tenant. Agree the accounts, tenants and tool actions in scope before anyone starts.
- Set the rules for real dataState explicitly how real personal data encountered during testing is handled: not retained, not removed from the environment, and reported rather than collected.
- Set the stop conditionA named contact who can halt the exercise immediately, and the circumstances that require a halt, agreed before the first request is sent.
- Arrange deconflictionDecide whether the defending team is informed. Either way, ensure somebody can distinguish exercise traffic from a real incident on demand, and that the testers can produce written authorisation.
- Instrument as you goLog prompts, responses, versions, decoding settings, accounts and request identifiers during the exercise. Reconstructing this afterwards is the single most common reason a good finding dies.
- Classify the report, do not gut itWorking payloads belong in the report. Control its handling and distribution instead of suppressing content that defenders need.
Check yourself
A client asks that the defending team not be told the exercise is happening. Which arrangement is still mandatory?
Unannounced exercises are legitimate and often valuable, precisely because they test detection. What is not optional is that somebody senior knows, can stop the exercise, and can distinguish a genuine incident from the test, so the organisation does not spend a night responding to its own testers. Avoiding anything that might trigger an alert would defeat the purpose of the exercise entirely.
Making an attack success rate interpretable
A success rate is uninterpretable without three things: its denominator, its attempt budget, and its success criterion. The denominator can be attempts, unique attack goals, or sessions, and these differ by large factors on the same underlying data. The attempt budget matters because best-of-ten over goals and per-attempt over prompts can differ by an order of magnitude on the identical exercise: ten attempts at each of a hundred goals, scored best-of-ten, will produce a far higher headline than the same thousand attempts scored individually. And the criterion matters because whether an output counts as a success is a judgement, whether made by a person or a model, and that judgement has its own error rate.
An interpretable success rate
- The denominator is stated: attempts, unique attack goals, or sessions.
- The attempt budget per goal is given, and whether the figure is per-attempt or best-of-n.
- The judge or success criterion is described, with an estimate of its own error rate.
- Generator, seed pool and judge are held fixed across any runs being compared.
- Results are reported per target version, with run-to-run variance.
A number nobody can use
- A single percentage with no denominator.
- The highest success rate observed across repeated runs of one configuration, presented as the headline.
- Results aggregated across target model versions to smooth out variance.
- Success decided by a judge that was itself upgraded between runs.
- A trend claim where the generator and seed pool changed alongside the target.
Reporting a finding that survives contact with engineering
A red team finding reads: the assistant disclosed restricted internal salary data when asked cleverly. Engineering cannot reproduce it and closes the ticket. They are right to. A finding against a stochastic system is a claim that a particular input state produces a particular outcome at some rate, and without the state and the rate there is nothing to verify, nothing to fix and nothing to regression-test.
- The exact prompt sequence, verbatim, including any retrieved or injected content that was in context.
- Model version and system prompt version, since either can change the outcome completely.
- Decoding settings: temperature, sampling parameters, and the seed where one is available.
- The account, tenant, role and permissions used, and the tool configuration reachable from that context.
- Request identifiers and timestamps, so the finding can be tied to server-side logs.
- Success rate over repeated runs, which distinguishes a reliable exploit from a lucky sample.
- A precise statement of what constitutes success, so a fix can be tested against it.
Two habits raise the quality of a report further. Include a negative control where you can: show the attack failing against a patched build, a different configuration or a restricted account, which tells the defender what actually mattered. And write the finding so that the fix is testable, meaning the success criterion is stated precisely enough that someone can add it to a regression suite. The measure of a red team is not how many findings it produced. It is how many of them were still being tested against six months later.