The tool said success and did nothing: why every AI tool needs a negative control
Short answer
A tool that reports success has told you what it believes, not what happened. We have seen scanners, MCP tools and AI assertions return a clean result without doing the work. The fix is a negative control: a case where the tool must fail, run before you trust the pass.
We fear this failure most in AI-assisted testing, because it looks like good news: the dashboard is green and the summary says no findings.
Below are real cases from our own tools, and the habit that catches them.
Scanners that scanned nothing
Our AI Security Toolkit is a set of scanners and AI agents. On real scans it caught its own failures. Several custom checks never ran at all and were recorded as clean, because the check rejected an option and the runner saw no error. A secrets scanner reported success with zero findings because its output was never read. On a fixture with 6 planted secrets it found 0 before the fix and 6 after.
In other cases, security scanners reported success while scanning nothing because one interpreter they depended on was dead.
The fix in each case was the same idea: "did not run" is its own result, separate from "found nothing".
Tools that answered "Updated"
Across our own MCP servers, a tool answered "Updated" while dropping the fields. A re-read showed nothing had changed. A health check reported 0 dead links because it had stopped at its cap. A "real zero" was reported while 23 items existed, because a default filter hid them.
We cover these and the other failure classes in what breaks when AI agents use MCP servers.
AI assertions that could not fail
In our mobile test flows, AI assertions defaulted to optional, so a failed check still passed. A check that cannot fail is not a check. We now refuse to create a flow with such an assertion unless someone marks it advisory on purpose.
When the tool cannot tell, say so
The opposite failure is a tool that calls something clean because it could not look. Our login-link analyser met a link through a redirect host it did not recognise. It now marks that link as unproven, with a note to check by hand, and never as clean. We decided that more noise is acceptable and a falsely clean result is not.
Where we do rule something out, such as cross-tenant access on a client application, we use a negative control so that "not vulnerable" means something.
What a negative control is, and how to use it
A negative control is an input where the correct answer is "this must fail". If your tool passes it, the tool is not measuring what you think.
- For a scanner: plant a known problem, such as 6 secrets in a fixture, and check it finds all 6.
- For a write tool: read the record back and compare it with what you sent.
- For a count: seed more items than the cap and check the total.
- For an AI assertion: run it on a case you know is wrong and check that the step fails.
- For a "not vulnerable" result: prove the probe can return a different answer on something that is vulnerable.
Rule of thumb. A pass that has never been seen to fail is a claim, not evidence.
This is AI quality assurance
AI testing covers wrong answers, and it also covers tools and checks that cannot tell you they are wrong. An agent that trusts a green result will build on it. Putting a negative control next to every check is cheap, and it is the part we do first.
On a client's agent or tool, we start by asking what each success message would look like if the work had not been done.
Reporting less, but proving more
Honesty also cuts the other way. On a public vulnerable-by-design benchmark, the toolkit produced 27 findings and 6 attack chains where the other tools produced none. A chain is a claim that several small things add up to one real attack, and a claim like that needs more proof than a single finding.
That is why the toolkit has a verifier step that tries to disprove each finding before it reaches a report. A finding the verifier cannot knock down is stronger. One it can is removed, and a report with fewer, better-proven findings is easier for a team to act on.
Applying it to a chatbot or an agent
The same questions apply to any AI feature you run. If your chatbot answers "I have checked your order", what would be different if it had not? If your agent logs "task complete", what changed in the system? If an evaluation reports a high score, could the evaluation have returned a lower number on a model you know is bad?
If you cannot answer, the green result tells you little. The remedy is rarely complex. It is a deliberately failing case, run next to the real ones, every time.
Frequently asked questions
Do you trust your green results?
Tell us which AI tools and checks you rely on. In a complimentary call we will show how we would test them.
Book a complimentary call AI quality assurance
