What an adversarial test report should look like

When a customer’s security team asks for proof that your AI agent holds up, a scan report doesn’t answer them. A scanner tells you what a tool matched. The reviewer wants to know what a person tried, and what happened.

Here is what one finding in an adversarial test report should hold, so you know what to ask for, from us or from anyone else.

The finding

What we found. One plain paragraph a security reviewer can follow without a call. It’s a description of what happened, not a tool’s output pasted into a PDF.

The fix. What to change, in terms your engineers can act on. “Improve input validation” is a category. A fix names the place and the change.

The effort. Roughly how long the fix takes, so it can be planned instead of argued about.

A framework crosswalk. Which known risk it maps to, so the reviewer can file it where their own process expects it.

The honest parts

A report that only lists findings is selling you something. A real one also says:

What was not tested. Scope has edges, and the report should name them, so nobody reads silence as a clean result.

That results are point in time. An AI system doesn’t answer the same way twice. A finding that didn’t reproduce today hasn’t been fixed, and a clean pass isn’t a guarantee.

Tests you keep. The same attack should run again after every change, so a fix stays fixed when the prompt or the model changes.

See one

There’s a sample finding on our assessment page, built from the template, not from a client. If a report you’re handed can’t hold up next to it, ask why.