A security finding needs a reproduction boundary.
A dramatic model output is not yet a verified finding. Reproduction needs exact conditions, independent evidence and a boundary that does not silently expand authorization.
Dr. Benjamin Harvey
Watch the 48-second visual essay
A dramatic result is not yet a finding
During an authorized assessment, a tester asks an AI agent to move a restricted file. The model describes a prohibited transfer and prints a confident success message. That output is worth investigating, but it does not establish what happened. Did a tool call leave the model? Did the host execute it? Did data cross a boundary, or did the model only narrate an action?
A screenshot cannot answer those questions. Neither can a report that omits the model version, tool configuration, policy state, privileges, input data and observation source. Without those conditions, another authorized reviewer cannot distinguish a repeatable weakness from a one-off generation, a stale configuration or a simulated effect.
For accountable testing, the unit of evidence is not the most alarming sentence. It is the smallest bounded packet that lets an authorized reviewer replay the conditions and independently observe the effect.
Reproduce inside the approved boundary
NIST Special Publication 800-115, published in 2008, recommends an assessment plan or rules-of-engagement document that identifies scope, authorized testers, permitted and prohibited activities, sensitive-data handling and incident procedures. Its central operational lesson still matters for AI testing: reproducibility does not create permission. A finding about one system, account or tool path is not authorization to probe another.
A practical reproduction boundary should record the exact system, model, tool and policy versions; the input and environmental conditions; the approved target; the tester's effective privileges; the expected and observed behavior; the evidence source; stop conditions; and what must remain untouched. Secrets and private data should be minimized or replaced with approved synthetic equivalents.
This is my synthesis for AI-enabled systems, not a claim that NIST 800-115 defines an AI-agent reporting standard. The document provides a foundation for planned, authorized assessment; the reproduction packet adapts that discipline to systems whose generated statements and external effects can diverge.
Preserve the effect—and the uncertainty
The report should separate three layers. First, record what the model generated. Second, record what an instrumented host, audit log or destination independently observed. Third, state the conclusion and its uncertainty. A generated claim of success, an attempted tool call and a verified external transfer are different findings.
A useful packet also records negative replays. If four authorized reruns do not reproduce the effect, that does not erase the original observation. It narrows the claim and points reviewers toward hidden state, timing, nondeterminism or evidence quality. The packet should preserve that uncertainty rather than upgrading an ambiguous event into a settled incident.
NIST's AI Risk Management Framework Core, released in 2023 and currently being updated, calls for documenting test sets, metrics and tools; evaluating systems under conditions similar to deployment; and documenting security and resilience evaluation. A bounded reproduction record makes those practices easier to inspect without confusing documentation with proof that the risk is resolved.
Evaluate the report as part of the control
A proposed study could compare narrative-only findings with bounded reproduction packets across the same consented test systems, synthetic data and reviewer resources. Each packet would include versioned conditions, scope, privileges, observation sources and stop rules. Reviewers would remain inside the original authorization.
Measure successful reproduction, false confirmations, duplicate findings, time to triage, time to verified repair, unsafe spillover beyond scope, reviewer burden and impact on legitimate tasks. Separately test whether a documented fix changes the running system. A clean ticket is not evidence of a repaired control.
This is an experiment design, not a measured result or a claim about a deployed product. Take the latest AI security finding in your queue and ask: can another authorized reviewer reproduce the observed effect, using the stated conditions, without widening access or guessing what the first tester did? If not, the next control improvement may be the report itself.