How Do You Write an Adversarial Test Report for AI Agents That Actually Passes?

When a client's security team asks you to prove that your AI agent can withstand attacks, a scanner report simply won't cut it. A scanner can only tell you which rule a given tool matched, but what reviewers really want to know is: what did someone actually try, and what happened?

This isn't a dispute over format — it's a fundamental difference in how trust gets established. A scanning tool's output is a machine-to-machine conversation, whereas a security reviewer needs a person-to-person account. A qualified adversarial test report isn't judged by how many vulnerabilities it lists, but by whether it enables a security engineer who wasn't involved in the testing to independently understand, evaluate, and act.

What a Qualified Test Finding Should Contain

The basic unit of an adversarial test report is the "single finding." Each finding should allow a security reviewer to fully understand it without needing a follow-up phone call.

Finding Description: Explain What Happened in Plain Language

"What we found" needs to be a straightforward piece of prose describing what actually happened — not the tool's raw output pasted into a PDF as filler. Tool output can be attached in an appendix as evidence, but the main text must be a human-readable narrative of events: who tried what under what conditions, how the system responded, and why this constitutes a problem worth attention.

This distinction seems subtle but is actually critical. A scanner reports "SQL injection pattern detected," while an adversarial test finding should say: "By crafting user input containing malicious instructions, we successfully caused the agent to bypass the role restrictions in its system prompt and output information it should not have provided." The latter is something a security reviewer can take to their superiors.

Remediation Recommendation: Provide Actionable, Specific Solutions

Remediation recommendations can't stop at a category-level description like "strengthen input validation." A good remediation recommendation must specify the exact location and exact change: which processing step in which component, what kind of validation logic to add, or how to adjust the wording of a particular prompt template.

This requirement is especially important for remediating AI systems. Traditional software fixes often have clear technical solutions, whereas remediating an AI agent may involve prompt engineering, input filtering layers, output review mechanisms, and multiple other layers — vague advice leaves engineering teams with nowhere to start.

Effort Estimation: Make Remediation Plannable

Every finding should come with a rough effort estimate. This isn't for precise scheduling, but to make remediation something that can be planned rather than debated. When the security team and the engineering team disagree about "whether to fix this now," a clear effort estimate shifts the discussion from a clash of opinions back to the practical question of resource allocation.

Framework Mapping: Let Reviewers File It

Every finding should indicate which item in a known risk framework it corresponds to — for example, a specific entry in the OWASP LLM Top 10 or MITRE ATLAS. This isn't academic decoration; it's what enables the client's security reviewer to file and process the finding according to their own workflows and templates. Findings without framework mapping tend to get shelved in enterprise security processes.

OWASP LLM Top 10 is a list of the top ten risks published by the OWASP organization for large language model applications, covering typical threats such as prompt injection, insecure output handling, training data poisoning, and model denial of service. It's one of the most commonly cited baselines for enterprises assessing LLM system risk. MITRE ATLAS, by contrast, borrows from the thinking behind the ATT&CK framework in traditional cybersecurity and is specifically organized around attackers' tactics, techniques, and procedures targeting AI systems. Its entries are more granular and well-suited to describing specific attack methods. The two have slightly different positioning: OWASP LLM Top 10 leans toward risk classification and compliance benchmarking, while MITRE ATLAS leans toward attack behavior modeling. Mapping to both frameworks in a report lets reviewers from different backgrounds find what they need, and makes it easier for security teams to plug the findings into their existing vulnerability management and threat intelligence workflows.

What an Honest Report Also Needs to Say

A report that only lists findings is essentially selling you something. A truly valuable adversarial test report will also candidly state the following.

What Was Not Tested

Testing scope has boundaries, and the report should clearly mark where those boundaries are. "We tested prompt injection, jailbreaking, and tool misuse scenarios, but did not cover cascading failures in multi-agent collaboration scenarios" — a statement like this prevents readers from misreading "no findings" as "no problems." Silence does not equal clean, and this is the logical loophole most easily abused in security reports.

Results Are a Point-in-Time Snapshot

AI systems don't run deterministically like traditional software — the same input may produce different outputs today and tomorrow. A finding that wasn't reproduced in the report doesn't mean it's been fixed, and a single passed test doesn't constitute a permanent guarantee. This characteristic makes adversarial testing not a "do it and done" project, but an ongoing process.

What's called model behavior drift refers to the fact that even if the code and prompts haven't changed, after the underlying model is silently updated on the server side, or temperature parameters shift, or context length is adjusted, the output distribution for the same input may change. This non-determinism stems from the random sampling mechanism of model inference itself, as well as vendors' continuous iteration on model versions. For security testing, this means one pass doesn't equal long-term security, and one failure may coincidentally disappear in the next version. Therefore, an adversarial test report needs to clearly note the model version, timestamp, and key parameters corresponding to the test, so that subsequent retests have a comparable baseline — rather than treating a particular result as an inherent property of the system.

Test Cases That Need to Be Preserved

After every system change, the same attacks should be re-executed. This means an adversarial test report isn't just a one-time deliverable — it should also include a repeatable test case suite. When prompts are adjusted or model versions are updated, this suite can verify whether previous fixes are still effective — or whether they've quietly stopped working amid model behavior drift.

Reference Samples: Use Examples to Check Report Quality

The most direct way to judge whether an adversarial test report is qualified is to compare it against a standard sample. If a report is clearly inferior to the example in structural completeness, descriptive clarity, and actionability of recommendations, ask why.

For teams currently evaluating AI agent security, the key question isn't "did we do adversarial testing," but "can the report we received actually support security decisions." A qualified report should leave a security reviewer, after reading it, with a clear understanding of what problems were found, how severe they are, how to fix them, how long the fix will take, and what blind spots remain. If any one of these elements is missing, the report's credibility is diminished.

One-line Summary

An adversarial test report should support security decisions with human-readable findings, actionable remediation recommendations, and honest boundary disclosures.

Paragraph Summary

The article points out that when facing a client's security team, a scanner report cannot replace an adversarial test report, because reviewers need a person-to-person account rather than machine output. A qualified report uses the "single finding" as its basic unit, and each finding should include a plainly described event, specific and actionable remediation recommendations, an effort estimate, and corresponding risk framework mapping. Beyond that, an honest report must also state which scenarios were not tested, that results are only a point-in-time snapshot, and that repeatable test cases need to be preserved. The author emphasizes that adversarial testing is not a one-time project — after every system change, the same attacks should be re-run to verify whether fixes are still effective, and report quality should be checked against reference samples.