This article walks the methodologies that distinguish productive AI red teams from performative ones, the cadence that delivers ongoing value, and the playbook patterns that convert findings into engineering action.
Methodologies for AI red teams
AI red teaming is an emerging discipline in 2026, with active methodology development across academic, industry, and regulatory communities. Three methodological strands have converged on the practical patterns mature programs use.
Threat-driven scenario testing. The red team begins with the threat model from Article 1 and selects scenarios to exercise. For each scenario, the team defines a success criterion (the attack succeeded if the model produced the target output, leaked the target information, or executed the target action), a constraint set (the attack used only the access a realistic adversary would have), and an evidence requirement (the attack is documented with sufficient fidelity that the engineering team can reproduce it). The pattern produces findings traceable to threat-model entries and supports the closed-loop maturation the COMPEL discipline requires.
Capability-based exploration. The red team explores the model’s behaviour beyond the documented threat model, looking for capability surprises — behaviours the model exhibits that the development team did not document, design for, or anticipate. The pattern is most valuable for frontier capability models (large generative models, agent systems with tool access) where the development team’s understanding of the model’s behaviour is necessarily incomplete. The output of capability exploration informs subsequent updates to the threat model.
Automated and tool-augmented testing. The red team uses automated attack tooling — Adversarial Robustness Toolbox, CleverHans, PromptInject, Garak, the commercial AI red-team platforms tracked in the Gartner AI TRiSM Hype Cycle https://www.gartner.com/en/articles/gartner-top-strategic-technology-trends-for-2024 — to scale the exploration beyond what manual testing can cover. Automation is most valuable for the well-understood attack classes (gradient-based adversarial examples against image classifiers, signature-based prompt injection against LLMs); manual testing remains essential for the attack classes where creativity and contextual reasoning matter (multi-step social engineering of agent systems, novel prompt-injection patterns).
The MITRE ATLAS knowledge base https://atlas.mitre.org/ is the authoritative public catalog of AI attack techniques and the natural starting point for red-team scenario construction; the catalog provides the equivalent of the MITRE ATT&CK framework for AI-specific tactics, techniques, and procedures. The OWASP Top 10 for Large Language Model Applications https://owasp.org/www-project-top-10-for-large-language-model-applications/ provides the LLM-specific attack catalog. The NIST AI Risk Management Framework Cybersecurity profile https://www.nist.gov/itl/ai-risk-management-framework prescribes red teaming as a managed practice for AI systems and the Generative AI Profile extends the prescription specifically to generative systems. NIST SP 800-218A https://csrc.nist.gov/pubs/sp/800/218/a/final names red teaming as a required Secure Software Development Framework practice for generative AI systems.
The European Union’s AI Act, Article 15 https://artificialintelligenceact.eu/article/15/, implies adversarial testing as a means of demonstrating the robustness and cybersecurity properties high-risk systems are required to achieve. ISO/IEC 42001:2023 Annex A.7 https://www.iso.org/standard/81230.html requires AI Management System operators to evaluate AI systems against adversarial threats — a requirement red teaming directly satisfies.
Cadence: how often, and tied to what
Red-team cadence is the operational decision that distinguishes programs that scale from programs that consume one-time budget and disappear. The pattern that works for production AI systems uses three layered cadences.
Pre-release red team. Every major release of a production AI system passes through a red-team review before promotion. The scope is calibrated to the system’s risk class — a low-risk classifier may pass through automated testing only; a high-risk LLM application receives manual exploration as well. The pre-release gate ensures that no system reaches production with red-team findings open, and the timing ties the red-team work to the release cycle the engineering team is already running.
Periodic deep red team. On a quarterly or semi-annual cadence, the highest-stakes production systems receive a deeper red-team engagement that explores beyond the scenarios the pre-release review covered. The deep engagement is the venue for capability exploration and for the manual creative work that scales poorly into release-gate timing. The output feeds the threat model from Article 1 and updates the scenario set for subsequent pre-release reviews.
Event-triggered red team. When something changes that materially shifts the threat model — a new capability is added to the system, a new class of attack is published in the academic literature, an industry incident demonstrates a new vector — the red team performs a targeted engagement against the affected systems. The event-triggered pattern keeps the program responsive to a moving threat landscape rather than running on calendar autopilot.
Cadence is paired with scope discipline. Each red-team engagement has a written charter that names the systems in scope, the attack classes to be exercised, the access the team is granted, the evidence to be produced, and the report deadline. The charter is the contract between the red team and the engineering team and prevents the scope creep, finding-overflow, and report-fatigue that kill red-team programs without one.
Playbooks: from finding to action
A red-team finding has no value until an engineering team has remediated it. The playbook is the discipline that converts findings into action.
The reference playbook has six steps.
Triage. Each finding is classified by severity (critical, high, medium, low), by exploitation difficulty, by blast radius, and by remediation complexity. Triage produces the prioritized backlog and the timeline expectation for each finding.
Reproduction. The engineering team independently reproduces each critical and high finding using the evidence the red team supplied. Reproduction confirms the finding is real, surfaces any missing context, and ensures the engineering team understands the failure mode well enough to fix it.
Remediation design. For each confirmed finding, the engineering team designs the fix — typically a control from the rest of Module 1.8 (input validation, output filtering, network policy tightening, model retraining with adversarial examples, credential rotation). The design includes a test that demonstrates the fix is effective.
Implementation and verification. The fix ships and the red team (or an independent verifier) re-tests to confirm the finding is closed. Findings are not considered closed on the engineering team’s word alone.
Threat model update. The threat model from Article 1 is updated to reflect the finding, the fix, and any residual risk. The update ensures that future red-team engagements and future architecture decisions inherit the lesson.
Post-engagement retrospective. The red team and the engineering team together review the engagement: what attack classes proved most effective, which controls failed, which controls held, what should change in the program. The retrospective output feeds the playbook itself, the cadence schedule, and the broader Domain D13 maturity assessment.
The playbook is the operational expression of the principle that red teaming is a continuous-improvement loop, not a periodic audit.
Maturity Indicators
Foundational. The organization has not red-teamed any of its production AI systems. The word “red team” is associated with traditional cybersecurity and has not been applied to ML systems. Adversarial testing, where it occurs at all, is informal exploration by the development team itself.
Applied. At least one production AI system has been red-teamed, typically by a small internal effort or by an external engagement. The findings have been documented and at least the highest-severity items have been remediated. The team has assessed which other systems should be in scope for future red-team work.
Advanced. A pre-release red-team gate is in place for production AI systems. Periodic deep engagements are scheduled for the highest-stakes systems. The team uses both manual exploration and automated tooling. The playbook converts findings to closed remediations on a tracked schedule. The threat model from Article 1 is updated by red-team findings.
Strategic. Red teaming is a continuous discipline integrated with the release cycle, the threat-model lifecycle, and the incident-response practice (Article 14). The organization runs event-triggered engagements on industry-significant changes. External red teams are commissioned periodically for independent perspective. The organization contributes to MITRE ATLAS, the OWASP LLM Top 10, or equivalent public bodies of knowledge. The red-team program is itself audited on a regular schedule.
Practical Application
A team that has not red-teamed any of its AI systems should commission one focused engagement this quarter. The engagement targets the single highest-risk production AI system, runs for one to two weeks, and uses a combination of manual exploration and automated tooling against the attack classes the threat model identifies as highest priority. The engagement is performed by an internal effort with at least one team member who has red-team experience, by an external specialist firm, or by both in collaboration.
The engagement produces a written report with prioritized findings, a triage and remediation plan, and a recommendation for the cadence going forward. The report is reviewed by the engineering team, the security team, and the governance body together. The pattern establishes the organizational muscle memory for red teaming, surfaces the immediate findings, and produces the artefacts on which a continuous program is built.
The first engagement will surface findings the team did not anticipate. That is the entire point. The maturity of the program is measured not by the absence of findings but by the speed and discipline with which findings are converted to closed remediations and inherited into the threat model.
© FlowRidge.io — COMPEL AI Transformation Methodology. All rights reserved.