Red teaming is structured adversarial testing where skilled operators try to achieve specific objectives against your organization, the way a real attacker would. In the AI era it has two meanings: using AI to red team faster, and red teaming the AI systems your organization builds or deploys. Both matter. This guide covers what CISOs need to know about each, and what governance your board should require.
- A penetration test checks whether specific assets are vulnerable. A red team engagement tests whether an attacker can reach a defined objective — data, access, disruption — across the full attack surface.
- "AI red teaming" means two different things: red teaming with AI (using AI agents to move faster and cover more surface) and red teaming of AI (testing models and agents for safety, security and misuse risks). CISOs need both.
- NIST publishes guidance on AI red teaming. The EU AI Act requires testing for high-risk AI systems and adversarial testing for general-purpose models with systemic risk.
- 83% of CISOs say more frequent offensive testing matters. Only 18% run it continuously today. 52% expect to within a year (a16z, October 2026).
- A red team report that reaches the board should include scope, rules of engagement, operator qualifications, findings with proof, and a clear chain from finding to business risk.
What is red teaming?
Structured adversarial testing against your organization, modeled on how a real attacker operates. A red team starts with an objective — reach the customer database, move laterally from a compromised vendor, exfiltrate source code — and uses whatever path works. That might cross network boundaries, abuse trust relationships, chain low-severity findings into a critical path, or exploit something the asset inventory doesn't even list.
The difference from a penetration test is scope and intent. A pentest is typically scoped to specific assets: test this application, scan this network range, check these APIs. A red team engagement is scoped to an objective, and the team chooses the path. The pentest answers "is this application vulnerable?" The red team answers "can someone get to X, and how?"
Both have value. A pentest gives you a finding list with remediation steps. A red team gives you a narrative: here is what an attacker would do, here is how far they would get, and here is where your defenses held or failed.
How has AI changed red teaming?
In two directions, and the distinction matters. When someone says "AI red teaming" in 2026, they could mean either of these:
Red teaming with AI
Using AI agents to automate parts of the offensive testing process. An AI agent can enumerate subdomains, test for known vulnerabilities, analyze code for secrets, and chain findings — continuously, across a scope that no human team could cover manually at the same speed.
This is what we do at Cylent. AI agents handle reconnaissance, discovery and initial validation at scale. An experienced human operator reviews every finding before it's reported, confirms exploitability, and makes the judgment calls that require context — is this a test environment or production? Is this credential active? Does this path reach real data?
The speed difference is real. What used to take a manual team weeks of reconnaissance now takes hours or less. The coverage difference is also real: an agent swarm tests the full external surface continuously, not a subset of it once a quarter.
But the human is not optional. An AI agent that reports a vulnerability without proving it's exploitable generates noise. An operator who validates the path and confirms the blast radius generates signal. That gate — the point where a human confirms it's real — is what separates a red team finding from a scanner alert.
Red teaming of AI
Testing the AI systems your organization builds or deploys for safety, security and misuse risks. This is a different discipline with its own methodology.
NIST's glossary defines AI red teaming as "a structured testing effort to find flaws and vulnerabilities in an AI system." The OWASP Top 10 for LLM Applications (2025 edition) catalogs the main risk categories: prompt injection, insecure output handling, training data poisoning, excessive agency, system prompt leakage and others.
If your organization deploys an AI assistant that has access to internal systems — Slack, wikis, code repositories, customer data — that assistant is an attack surface. It responds to prompts. It has access to data. It makes decisions about what to return. Testing whether it can be manipulated into revealing secrets, escalating privileges or taking unauthorized actions is red teaming of AI.
The EU AI Act requires testing of high-risk AI systems under Article 9(8). Article 55(1)(a) specifically requires providers of general-purpose AI models with systemic risk to conduct and document adversarial testing. The duties depend on the system and the provider's role.
Both directions apply to most organizations. You need AI-assisted red teaming to test your external surface at the speed the threat landscape demands. And you need red teaming of AI to test the models and agents you deploy internally. These are different engagements with different scopes, but the board should know about both.
How is a red team engagement different from a pentest?
Scope, objective and methodology. The table below captures the practical differences:
| Dimension | Penetration test | Red team engagement |
|---|---|---|
| Scope | Defined assets (an app, a network range, an API set) | An objective across any path |
| Duration | Days to weeks | Weeks to continuous |
| Goal | Find and list vulnerabilities in the scoped assets | Reach a defined objective; prove the path end to end |
| Methodology | Systematic testing against known vulnerability classes | Adversarial thinking — whatever works |
| Output | Finding list with severity and remediation | Attack narrative with proof, plus findings |
| Defender awareness | Usually coordinated with the security team | May be unannounced (with executive approval) |
| Value | "Here's what's vulnerable" | "Here's what an attacker can do" |
Neither replaces the other. A pentest is the right tool when you need to validate specific applications before release. A red team engagement is the right tool when you need to know what your overall security posture looks like from the outside.
Many organizations start with pentests and add red teaming as their program matures. The question is whether you only test what you know about, or whether you also test what you don't know you're exposing.
What should you look for in a red team service?
Five things, in order of importance:
- Operator experience. Who is doing the work? Red teaming is a judgment-intensive discipline. The person making the calls — which path to pursue, whether a finding is exploitable, how far to take a chain — needs deep offensive experience, not just a certification. Ask for operator profiles, not company logos.
- Scope definition. Does the engagement start from your company name, or from a list of IPs you provide? The best red team engagements start with nothing but a name and discover the attack surface independently. If you hand the team their scope, you're telling them where to look — and an attacker doesn't have that constraint.
- Proof of exploitability. Every finding should include the evidence: what the operator accessed, the exact path taken, and what an attacker would reach. A finding that says "this port is open" or "this CVE applies" without proving what it means in practice is a scanner output, not a red team finding.
- Continuous versus point-in-time. 96% of organizations change their IT environment at least quarterly (Pentera, 2025). A point-in-time engagement reflects the surface as it was during the test window. Continuous red teaming tests the surface as it changes, which is when most new exposures appear.
- Reporting that reaches the board. A red team report should translate findings into business risk. "We reached the customer database from the public internet through three chained findings" is a board-level statement. A CVSS table is not. The report should include scope, rules of engagement, operator qualifications, methodology, and a clear chain from each finding to business impact.
What governance should the board require?
Six elements. These come from what we see at organizations with mature offensive testing programs:
- Defined scope and objectives. What is being tested, and what does success look like for the red team? The board should know whether the scope covers only company-owned assets or extends to the supply chain, personal repositories, AI tools and cloud infrastructure.
- Rules of engagement. What is the red team permitted to do? Clear rules prevent damage while allowing realistic testing. The rules should specify: which systems are in scope, whether social engineering is included, what happens if critical infrastructure is reached, and how findings are escalated in real time.
- Operator approval. Every critical finding should pass through a human operator before reporting. For AI-assisted red teaming specifically: the board should require that an experienced operator validates every exploitability claim. An AI agent that says a system is compromisable is a hypothesis. An operator who proves it is a finding.
- Frequency and continuity. Annual testing satisfies most compliance frameworks. It does not satisfy the threat landscape. The board should ask: how often are we tested, does testing continue between engagements, and what happens when a new asset or service goes live between tests?
- Remediation tracking. A finding that isn't fixed is a finding that's still there. The board should require: retesting after remediation, a clear owner for each finding, and a timeline from finding to confirmed fix. More than 64% of credentials exposed in 2022 were still valid in 2026 (GitGuardian).
- AI-specific testing. If the organization deploys AI systems, the board should require adversarial testing of those systems specifically. This includes testing internal AI assistants for data leakage, testing customer-facing AI features for manipulation, and verifying that AI tools with access to internal systems don't surface sensitive data when prompted. NIST AI 600-1 and the EU AI Act provide frameworks. The OWASP LLM Top 10 provides a testable checklist.
FAQ
What is the difference between red teaming and penetration testing?
A penetration test checks specific assets for vulnerabilities. A red team engagement has an objective — reach the database, exfiltrate code, move from vendor to production — and takes whatever path works. The pentest finds vulnerabilities. The red team proves attack paths.
What does "AI red teaming" mean?
Two things: using AI agents to conduct red team engagements faster and more continuously (red teaming with AI), and testing AI models and agents for safety, security and misuse risks (red teaming of AI). Most organizations need both.
Is red teaming required by regulation?
For covered organizations, yes. PCI DSS requires periodic penetration testing. Under DORA, selected financial entities must conduct threat-led penetration testing at least every three years. The EU AI Act requires testing of high-risk AI systems and adversarial testing of general-purpose AI models with systemic risk. The specific duty depends on the organization and system.
How often should we run a red team engagement?
At minimum, annually. Ideally, continuously. 96% of organizations change their environment quarterly, and new services create 32% of new high or critical exposures (Unit 42). A point-in-time engagement can't catch what appears between test windows.
What should a red team report include?
Scope, rules of engagement, operator qualifications, methodology, findings with full proof of exploitability, attack narratives showing the path from entry to objective, and a translation of each finding to business risk. If the report doesn't show you the request and the response at every step, it's a summary, not proof.
The bottom line
Red teaming is not new. Using AI to do it faster is. Testing AI systems adversarially is. The organizations that will be most prepared are the ones that do both: test their external surface continuously with AI-assisted red teaming, and test their AI deployments with structured adversarial methods.
The board doesn't need to understand the methodology. It needs to know: what was tested, what was found, what was proven versus what was hypothetical, and what has been fixed. A good red team program gives the board that answer quarterly. A great one gives it continuously.
My question: if your organization deployed an AI assistant last quarter, has anyone tested what it returns when asked for internal credentials?
Sources
- NIST, AI 600-1: AI Risk Management Framework, Generative AI Profile (July 2024)
- OWASP, Top 10 for LLM Applications v2.0 (2025)
- NIST, Artificial intelligence red-teaming (glossary)
- EU, AI Act, Articles 9(8) and 55(1)(a)
- EU, DORA, Article 26 (2022)
- PCI Security Standards Council, PCI DSS v4.0 SAQ D for Merchants, Requirement 11.4.2
- Microsoft, AI Red Team Framework (2024)
- a16z, The New Security Agenda (October 2026, 100 CISOs at companies with 1,000+ employees)
- Pentera, The State of Pentesting 2025 (May 2025, 500 US CISOs, >3,000 employees)
- GitGuardian, State of Secrets Sprawl 2026 (2026)