GLOSSARY
Red team
A red team examines a system through deliberate counterexamples and attack scenarios. Its purpose is to expose weaknesses that routine functional testing may miss. Useful evidence requires a clear scope, realistic cases and sufficiently independent assessment.
Challenge boundaries in the customer workflow
A negotiation application could be tested for disclosure of one party's private notes in the other party's output. Another case might use a document that tries to induce an unauthorised action. These tests focus on concrete adverse consequences.
Findings help prioritise engineering effort by potential harm. Each finding therefore needs a description of its scope, prerequisites and affected data or actions. The organisation must also be able to respond: who decides on remediation, and which uses remain restricted until it is complete?
Turn a finding into evidence
After a correction, repeat the original case and add related variations. Using a second model alone does not establish independent review. Prompt injection and tenant isolation require different test designs. Passing cases demonstrate improvement within the examined scope. Unknown attack paths and later system changes remain relevant, so the report should make its coverage and limitations explicit.