Demand for red teaming of AI systems has risen markedly in recent months, and with it the number of offerings. On paper they look very similar: prompt injection, jailbreaks, data leakage, a report with recommendations. The differences only show in the result, and by then the budget has been spent. Whether a red teaming engagement delivers usable insight or a reassuring document without substance is largely decided before the first test. This article describes which commitments a robust mandate contains and how the quality of the result can be checked.
Scope determines value
The most common mistake lies in the scope. What gets commissioned is a test of the model, because the model is at the centre of the discussion. The risk, however, rarely lies in the model alone but in what the system can do with its outputs. An assistant that only returns text has a different damage potential than one that creates tickets, sends emails or writes to a business system. The scope should therefore follow the path an input takes to its effect: through the knowledge sources the system reads, the tools it calls and the permissions under which it acts.
An explicit threat model matters just as much. It defines who is considered an attacker, for example an external user, an internal employee with legitimate access or a third party who injects content into a knowledge source. It names the assets to be protected. Without this definition, testers test what they know best, and that is not necessarily what would be most expensive for the company.
Success criteria before the first test
A finding is only worth as much as the scale on which it is rated. If it has not been agreed in advance what counts as critical, the report contains dozens of entries in the same colour and nobody can decide where to start. What holds up is a severity scale oriented to business damage rather than technical elegance: leakage of confidential data, an unauthorised action in a business system, a false basis for a decision, reputational harm. This scale is set together with the business unit that carries the damage in a real incident.
The mandate also covers the test environment. Tests on a demo with sample data and without connected tools produce results that do not transfer to operations. Meaningful is a production-like environment with the same connections and permissions, but with test data. Where testing in production is unavoidable, stop and escalation rules must be agreed in advance, so that a successful attack in the test does not cause real damage.
How to recognise a usable report
A good report contains, for every finding, a reproducible attack path with precondition, sequence, impact and a concrete countermeasure. It assigns findings to the layer where they originate, model, system or agent, because that determines who has to fix them. And it states explicitly what was not tested. This coverage statement is often overlooked and yet decisive: a report without findings is good news only if it is clear which paths were actually tested.
For steering purposes, a version is also needed that can be used in the board and in the audit committee without technical translation. It answers three questions: what residual risk exists as of today, which measures are prioritised and by when they will be implemented, and which decisions management has to take, for example on restricting permissions or postponing a go-live. A report readable only by engineers never reaches the level that decides on the risk.
Without a retest, remediation remains a claim
A countermeasure is effective only when the original attack fails against it and no obvious variant gets through. That is exactly what the retest checks. It belongs in the original mandate rather than in a later proposal, because otherwise it gets dropped for budget reasons. With AI systems there is the added fact that behaviour can shift with every model update. A measure that works today has to be confirmed again after the next change.
The most durable part of an engagement is therefore the handover. Successful attacks are handed to the internal team as test cases and added to the regression tests that run before every release. This turns a one-off assessment into a repeatable control. Providers unwilling to hand over their test cases are selling a dependency rather than protection.
Conclusion and recommendation
The quality of red teaming is decided in the mandate. Before the next engagement we recommend three steps. First, list which actions the system under test can trigger and align the scope with them rather than with the model. Second, set a severity scale based on business damage, together with the business unit, before the first test runs. Third, agree retest and handover of test cases contractually, so that the engagement becomes a lasting control.
ECODYNAMICS runs AI Security and Red Teaming engagements in exactly this order. In the first week we define scope, threat model and success criteria with you, followed by tests on the model, system and agent layers, and from the sixth week we support the hardening and verify critical findings in a retest. You receive a prioritised report with reproducible attacks and a version for the board and the audit committee. If an agent at your organisation is about to go into production, get in touch.