AI red teaming vs traditional red teaming

AI red teaming versus traditional red teaming: which to commission first

If your organization already runs AI features in production, the first decision is which risk surface your next red team exercise should target. Choose AI red teaming when the risk sits in model behavior, misuse or harmful outputs: a customer-facing assistant that can be steered into disclosing restricted content, generating unsafe advice, or producing outputs that breach your policies. Choose traditional red teaming when the risk sits in networks, identities, people and detection: an attacker who gets a service account, reaches the model's hosting environment, and tests whether your security operations team notices. Many AI-heavy estates need both, because a model that behaves well in isolation can still be a path into systems it has access to.

The advantage of AI red teaming matters most before release. NIST AI 600-1, the generative AI profile of the NIST AI Risk Management Framework, describes four types of AI red-teaming (general public, expert, a combination of the two, and human and AI teams) and focuses its guidance on pre-deployment testing, although it notes that red teaming can also happen after a system is public. Confirm with your own AI governance owner which of these team types you need, and whether your release gate already requires evidence from them. The traditional advantage matters when AI systems run on your existing estate: a model endpoint reached through an identity provider, a retrieval store on an internal network, or tool calls that write to business systems. There, the questions are whether the attacker can move laterally and whether your logging catches it, which is the territory NIST SP 800-53 control CA-8 and its enhancement CA-8(2) describe for red team exercises against mission functions.

A combined exercise makes sense when an AI system's failure mode crosses both boundaries, such as a model that can call tools with broad privileges. In that case, scope one engagement with two sets of success criteria: behavioral findings from the AI team, and whether the traditional team can reach the tool's credentials and whether detections fire. Ask any provider to name the technique catalogs they plan against, since MITRE ATLAS v2026.09 covers AI-specific tactics and MITRE ATT&CK v20 covers enterprise attacks, and to explain how they will validate detections afterward. Confirm the team skills, rules of engagement and reporting format in writing before testing starts.

How the two approaches compare on goal, target and success criteria

This table compares AI red teaming and traditional red teaming across goal, target, scope, technique catalog, team, success criteria, environment, timing and regulatory anchors. Read each row as a question to put to a provider or internal lead before choosing scope. The main takeaway is that the two exercises answer different questions, so an AI-heavy organization usually needs both rather than a substitute for either.

Dimension	AI red teaming	Traditional red teaming
Primary goal	Find harmful, misusable or unexpected model and application behavior before release	Test whether an attacker can reach mission or business objectives through technology and social engineering
Target	A specific model or AI system, including prompts, guardrails, tools and training or fine-tuning data	The organization's networks, people, applications and detection and response capability
Scope boundary	Defined by the system's intended use, misuse cases and harm categories agreed with the business	Defined by in-scope assets, rules of engagement and objectives, often as a flag or goal to reach
Technique catalog	MITRE ATLAS, with 16 tactics and 120 techniques in the v2026.09 release, plus harm taxonomies from NIST AI 600-1	MITRE ATT&CK Enterprise, with 15 tactics in v20, plus established penetration testing methodologies
Team make-up	Specialists in machine learning, prompt-based attacks and domain harms, with expert or non-specialist testers as NIST AI 600-1 describes	Operators skilled in network, application and social engineering attacks, with a planning and reporting function
Success criteria	Documented harmful outputs, bypassed safeguards or unsafe actions, judged against agreed harm definitions	Objectives reached and detections measured. TIBER-EU tests produce no pass or fail result
Testing environment	Often pre-deployment access to the model or application, including staging, evaluation endpoints and tool connections	Production-like or production environments with real controls, subject to rules of engagement
Typical timing	Before release and when models, prompts or tools change, per NIST AI 600-1's focus on pre-deployment testing	Scheduled exercises, with CIS Controls v8.1 expecting internal and external tests at least annually
Regulatory anchors	NIST AI 600-1 for generative AI red teaming; confirm which AI obligations apply under the EU AI Act	NIST SP 800-53 CA-8(2) for red team exercises; DORA Article 26 for threat-led testing of covered entities

How MITRE ATLAS and ATT&CK shape the test plan

The two catalogs set different attack plans. MITRE ATLAS v2026.09 catalogs 16 tactics and 120 techniques aimed at AI systems, while MITRE ATT&CK v20 lists 15 Enterprise tactics for attacks on enterprise IT. In practice, an AI red team builds its plan around ATLAS techniques such as model evasion, data poisoning and prompt-level manipulation, and a traditional red team builds its plan around ATT&CK tactics such as initial access, privilege escalation and lateral movement. Ask your testing provider which catalog version the plan cites, and whether the team will map each planned step to a technique ID before testing starts, so the report can be traced back to the catalog.

What a tester records also differs. An ATLAS-based record should capture the model or AI service under test, the input channel, the behavior observed and the harm assessed, alongside the technique ID. An ATT&CK-based record usually captures the host, account, path and detection outcome. ATLAS added techniques such as Misconfigured or Publicly Exposed AI Services (AML.T0132), which matters because many AI findings are ordinary infrastructure failures, such as an exposed inference endpoint or an overly permissive storage bucket behind a model. Those findings belong in the test plan even though they sit outside what a prompt-based test would find.

The catalogs overlap wherever AI services run on conventional infrastructure. A model server, vector store or agent runtime still has identities, network paths and cloud roles that ATT&CK describes well, so one engagement may need both mappings for the same finding. Decide in advance which catalog owns each finding category, and confirm the mapping choices with your testing provider, including how duplicate or dual-mapped findings will appear in the report and whether the detection team can tell which technique IDs its alerts should cover.

What each approach finds and what it misses

Each approach surfaces a different class of weakness. AI red teaming tests what a model says and does under adversarial input, while traditional red teaming tests how an attacker moves through people, identities and detection. The cards below show where each one finds issues and where the other one is blind.

Harmful or policy-breaking output

AI red teaming probes whether a model produces disallowed content, unsafe advice or responses that break the operator's policy under pressure. Testers judge harm in the text itself, often with human reviewers who understand the business context. Traditional red teams rarely score model output at all, because a network intrusion produces a shell or a stolen record rather than a harmful answer. Check whether your AI test plan defines harm categories and who decides when an output counts as a failure.

Prompt-driven misuse of tools

When a model can call tools or read documents, crafted inputs can steer it into actions the user never intended, such as querying data outside its role. AI red teaming finds these by varying prompts and observing tool calls. Traditional tests usually cover the tool's API or its network path, not whether the model can be talked into calling it. Confirm which tools the model can reach, which identity those calls carry, and whether logs record the prompt that triggered each call.

Lateral movement across networks

Traditional red teaming chains access across hosts, segments and cloud accounts to reach a stated objective, such as a core system or sensitive data store. AI red teaming seldom exercises this path, because the model is usually only one component. An AI-heavy environment still has servers, containers and service accounts that an attacker can reach. Check that the scope of your exercise includes the hosts that run inference, vector stores and orchestration, not only the model endpoint.

Weak identity and access controls

Red teams test whether stolen or weak credentials, over-broad roles, and gaps in MFA or privileged access let an attacker escalate. AI tests may check whether a model respects user permissions, but they rarely reach the identity provider, token issuance or privileged role design. For agents acting under delegated identity, this gap matters: an agent can hold more access than its user. Ask whether the exercise covers the identity provider and service accounts the AI components use.

Social engineering success

Traditional exercises measure whether staff can be persuaded to click, disclose or approve access, using phishing, pretexting or vishing. AI-generated lures can raise the quality of these attacks, yet most AI red teaming judges only the model's responses, not how people react to them. Check whether your exercise includes people-focused scenarios and whether help desk or approval workflows are part of the target.

Detection and response gaps

Red teams measure whether the security operations team notices an intrusion and responds in time, and whether detections cover the techniques the testers used. AI red teaming rarely reaches the SOC, so prompt attacks that succeed may leave no alert. Ask whether model inputs, outputs and tool calls are logged to a place the SOC monitors, and whether a purple team exercise checks those detections against the same techniques.

Who runs each test and how success is judged

AI red teaming puts people, and sometimes AI tools, against a model or AI system to find harmful, misleading or misusable behavior. NIST AI 600-1 describes four team types: general public, expert, a combination of the two, and human and AI teams, where generative AI works with specialist or non-specialist people. The choice changes what gets found. General public testers often surface everyday misuse that trained testers would not think to try, while domain experts craft context-specific attacks and judge subtle harm.

Team composition: Ask whether the team includes domain experts, such as clinicians for a health assistant or credit analysts for a lending tool, alongside testers who understand adversarial prompting.
Human and AI mixes: Confirm which parts of attack generation are automated and which are judged by people, because the team model determines who is accountable for each finding.
Harm judgment: Ask how harm is defined for your use case, who decides whether an output is harmful, and whether those criteria are written down before testing starts.
Timing: NIST AI 600-1 notes that red teaming can happen before or after public release and focuses its guidance on pre-deployment work, so confirm when testing falls relative to your release.
Evidence: Require reproducible prompts, model versions and the exact configuration tested, so a fix can be retested under the same conditions.

Success here is rarely a simple pass or fail. Agree in the statement of work what counts as a finding, how severity is set and what a retest looks like. Ask the provider to show a sample finding with its harm rating before you sign.

What you receive from each engagement

This table compares the deliverables an AI red teaming engagement and a traditional red team engagement typically produce, row by row. Read each row as a question to put to a provider in writing, since the exact formats, depth and timing vary by scope and should be agreed before work starts.

Deliverable	AI red teaming	Traditional red teaming
Scope and rules of engagement	Written scope covering the model, application, data sources, tools and harm categories in play. The NIST SP 800-115 rules of engagement template in Appendix B applies.	Written scope covering target systems, people, physical sites and permitted techniques. The same NIST SP 800-115 Appendix B template applies.
Attack narratives mapped to a catalog	Step-by-step narratives mapped to MITRE ATLAS technique IDs, such as AML.T0132 for misconfigured or publicly exposed AI services.	Step-by-step narratives mapped to MITRE ATT&CK Enterprise tactics and techniques, so detection teams can trace each step.
Finding records	Each record names the prompt or input sequence, model or system version, observed output and reproduction steps. Ask whether the provider logs the exact configuration tested.	Each record names the affected asset, exploited weakness, evidence captured, impact and remediation advice. Ask for a severity method the client has already agreed.
Harm assessments for outputs	Written judgment of harm severity and affected groups for each unsafe output, a deliverable with no direct equivalent in network testing. Ask who judged the harm and whether a second reviewer checked it.	Usually not produced. Business impact is assessed in the findings, not as a separate harm review.
Detection gap report	Shows which adversarial inputs or misuse patterns were not caught by safety filters, logs or monitoring around the model. Confirm whether the provider inspects your guardrail or logging layer.	Shows which attacker actions the security operations team saw, missed or misclassified. CIS Safeguard 18.4 expects validation of detections against the techniques testers used.
Retest evidence	Re-run of the same adversarial sets against the fixed model or guardrails, with results compared to the original run. Ask whether retests use the same prompts and seeds.	Re-test of exploited paths after remediation, with evidence that each finding is closed or still open. Ask for the retest window in writing.
Debrief sessions	Walkthrough of successful attacks with the model, product and safety owners, covering what the model did and why it matters for release decisions.	Debrief with system owners and the security operations team, covering the attack path, timeline and detection points. Ask who attends from each side.
Reporting audience	Separate summaries for product and risk owners and technical notes for ML engineers, so the findings feed the AI risk register.	Executive summary for leadership and technical detail for system owners, with the attack narrative as the core artifact.

When compliance frameworks call for each approach

Compliance frameworks rarely ask for AI red teaming by name, so the first decision is whether your obligations point to traditional adversarial testing, AI-specific testing, or both. NIST SP 800-53 Rev. 5 control CA-8 (Penetration Testing) includes enhancements for an independent penetration testing team and for red team exercises, and the SP 800-53B baselines select CA-8 and CA-8(1) only in the high baseline. CA-8(2) describes traditional red team exercises as simulated attempts to compromise mission and business functions through technology-based and social engineering attacks. None of these enhancements describes testing model behavior, so a system bound by the high baseline needs a traditional exercise scope written in the control, with AI-specific scope added separately if the agency or contract requires it.

In the EU financial sector, the requirements are more prescriptive. DORA Article 26 requires threat-led penetration testing at least every 3 years for entities their competent authority identifies. TIBER-EU, as set out in the ECB's January 2025 framework, requires at least 12 weeks of active testing and mandatory purple teaming, and its red team tests use flags tied to the confidentiality, integrity or availability of in-scope systems. An AI feature inside a TIBER-EU scope must be justified against those flags, so confirm with your authority and test provider whether a model or agent counts as an in-scope system and how its flags are written.

The EU AI Act and any AI-specific supervisory expectations should be confirmed with your legal counsel and the relevant regulator, because the obligations depend on your role and the use case, and this page does not interpret them. Ask for written answers on what evidence is expected, who must perform the testing, and whether pre-deployment testing must be documented. DeployOpen prepares systems, controls and evidence for compliance assessments, including test plans and records, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so agree with them in advance which artifacts they will accept.

What drives the cost and effort of each approach

Cost and effort in AI red teaming and traditional red teaming are driven by different people, different targets and different repeat cycles. The cards below separate the fees, the estate size and the test cadence so you can compare written quotes on the same basis.

Who is paid for each phase

Scoping, attack execution, harm review, reporting and retest are separate pieces of work, and they are often staffed by different people. In an AI engagement, harm review usually needs reviewers who can judge outputs against your policies, while a traditional engagement spends more on operators who can move through networks and identities. Ask the provider to break the quote into these phases so you can see which ones you are paying for.

Number and access modes of AI systems

Each model, chat front end, retrieval pipeline, plug-in and agent is a separate target with its own inputs, outputs and failure modes. Testing a system through a public interface, through an authenticated API and with tool access are different efforts. Ask how many systems are in scope, which access modes each one needs and whether test accounts with production-equivalent permissions will be provided.

Size of the network and identity estate

Traditional red teaming scales with hosts, segments, directory objects, cloud accounts and the number of trust relationships an attacker could chain. A larger estate means more ground to cover and more time spent on lateral movement. Ask for the number of in-scope address ranges, domains, cloud subscriptions and identity providers, and whether any of them will be tested as part of the AI system itself.

Attack and harm test catalogs

AI red teaming draws on technique catalogs such as MITRE ATLAS, while traditional work draws on ATT&CK. The number of techniques you ask a team to cover, and whether they must be evidenced one by one, changes the hours required. Ask which catalog and version the test will map to, how many scenarios are planned and how harm categories will be scored.

One-time tests and recurring work

A single assessment has a fixed start and end, but AI systems change when models, prompts, retrieval sources or tools change. Those changes trigger retests and new harm reviews, which recur. Traditional estates change too, though often on a slower schedule. Ask which costs are one-time, which are per release or per change, and whether a retainer covers repeat testing at a defined cadence.

Long-form exercises and their minimum durations

Regulator-led schemes set floors on duration and effort that no quote can shorten. TIBER-EU requires at least 12 weeks of active testing and mandatory purple teaming, and the ECB states these tests produce no pass or fail result. If your organization is subject to such a scheme, ask how the framework minimum is reflected in the timeline, the team size and the purple teaming hours, and check the framework text directly.

What buyers ask before they commission AI or traditional red teaming

Does a traditional red team test AI models?

Not usually, at least not as its core job. A traditional red team targets an organization's networks, people, applications and detection capability, following the kind of adversary exercise described in NIST SP 800-53 control CA-8 enhancement 2, which simulates attempts to compromise mission and business functions through technology-based and social engineering attacks. An AI red team probes a model's behavior, misuse and harms. If your AI system sits inside the estate, the two overlap at the integration points, such as the data pipeline, the identity the model runs under and the tools it can call. Ask the provider in writing which of those layers are in scope and which are excluded.

How long does each kind of red teaming take, and what drives the duration?

Duration depends on scope more than on the testing method itself. For traditional work, the main drivers are the number of in-scope systems, whether the exercise is threat-led, how many objectives the team must reach, and how much time the defenders need to be tested against. For AI work, the drivers are the number of model versions and modalities, the number of misuse categories agreed for testing, whether tools or agents are involved, and how many human reviewers judge outputs. Under TIBER-EU, a threat-led test runs for at least 12 weeks of active testing, which shows how regulated schemes set a floor. Request a timeline broken into preparation, active testing and reporting in the written scope.

What does the work need from our own staff?

Both approaches need named owners on your side, and the load is heavier than most buyers expect. Traditional red teaming usually needs a sponsor who can approve rules of engagement, a technical contact for the systems in scope, and a small group who know the detection stack, so the exercise can be measured. AI red teaming needs people who can define the harms that matter for your use case, supply test data and system prompts, provide access to model endpoints or staging environments, and review flagged outputs. NIST SP 800-115 provides a rules of engagement template in Appendix B that is a useful starting point for both. Confirm in writing who signs off on each step and how quickly they must respond.

Can our internal team run this testing alone?

An internal team can run useful tests, but independence and skill coverage are the usual gaps. Internal staff know the environment well, which helps with repeat testing and regression checks, yet they may struggle to challenge their own design assumptions. Regulated frameworks often expect independence: CIS Controls v8.1 Safeguard 18.2 and 18.5 ask for penetration tests at least annually, and PCI SSC guidance describes penetration testing as essentially manual work, not a tool run. For AI, a team needs skills in prompt-level attacks, harm judgment and evaluation design. Many organizations combine internal routine testing with an external exercise for the periodic deep test. Confirm what skills the internal team has and what independence the auditor will accept.

Which approach does a regulator expect?

It depends on your sector and jurisdiction, and regulators rarely name AI red teaming as a fixed requirement. For financial entities in the EU, DORA Article 25 lists penetration testing and scenario-based tests among the required kinds of testing, and Article 26 requires threat-led penetration testing at least every 3 years for entities identified by their competent authority. TIBER-EU sets out the threat-led framework, and the ECB states its tests produce no pass or fail result. For AI systems, NIST AI 600-1 focuses guidance on pre-deployment red teaming. Ask your regulator or auditor which tests they expect and whether AI testing falls under an existing requirement or a separate one.

How often should we repeat each type of testing?

Repeat traditional testing on a schedule and after material change, and repeat AI testing at each significant model, prompt, tool or data change. NIST SP 800-115 suggests regularly scheduled scanning interspersed with periodic penetration testing. CIS Safeguard 18.4 asks that security measures be validated after each test so detections cover the techniques testers used. For AI, a model update, a new retrieval source or a new tool can change behavior, so a release gate is a common trigger. Frequency should follow your risk, your regulator's expectations and how fast your systems change. Put the trigger events and the minimum cadence into the engagement terms.

How should we read and act on the results?

Read results against the objectives that were agreed in advance, not against a pass or fail count. Traditional red team reports should show which objectives the team reached, which detections fired, and which did not. TIBER-EU requires at least one flag per in-scope system, so results often describe which flags were captured and how. AI reports should state the harm categories tested, the severity judgments, the reproduction steps and the model version tested, because results from one version may not hold for the next. Ask for findings mapped to a shared taxonomy, such as MITRE ATLAS for AI techniques and MITRE ATT&CK for enterprise techniques, and feed each finding into your risk register with an owner and a retest date.

How DeployOpen scopes and runs AI and traditional red team work

DeployOpen plans, runs and documents both kinds of adversarial work inside your own infrastructure, with the AI model or system and the enterprise environment treated as separate, clearly bounded targets. Each engagement starts from a written scope that says which behaviors, networks, people and detections are in play before any testing begins.

How we scope

Written scope names the AI system, its model endpoints, data sources and tools, and the harm categories being tested.
Traditional red team scope names target systems, attack objectives, social engineering limits and the detection teams involved.
Rules of engagement cover production access, safety limits for model testing and escalation contacts, following the structure of NIST SP 800-115.

How we build

Test plans map AI attempts to MITRE ATLAS techniques and enterprise attempts to MITRE ATT&CK tactics, so coverage is traceable.
Human testers craft context-specific attacks for AI systems, and automated tooling is added where the scope calls for breadth.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and quoted from that written scope.

How we hand over

Reports separate model behavior findings, such as harmful output or unsafe tool use, from network and identity findings.
Each finding records reproduction steps, affected components and the detection gaps the testers exploited, for remediation planning.
Documentation includes evidence packages that your auditors or governance teams can review, though DeployOpen does not issue audit reports or certifications.

How we support

Retesting after fixes confirms that model guardrails and detections respond to the techniques the testers used.
Ongoing support, upgrades and continuous testing are available as retainers, so AI systems that change often can be retested on a schedule.
Confirm with us at scoping which retest windows, model version changes and handover formats your governance team requires.