Should organisations rely on CART instead of human red teams?

Why This Matters for Security Teams

Organisations are often tempted to treat CART as a replacement for human red teams because it is repeatable, cheaper to scale, and easier to run on a schedule. That framing is risky. CART is strongest at validating whether specific controls, detections, and response playbooks still work against known techniques, while red teams are better at discovering unexpected paths, control gaps, and business-impacting chains that do not fit neatly into a test library. The distinction matters because a tool that repeatedly proves coverage can still miss the one route that matters most.

For security leaders, the question is not whether automation is useful, but whether it is being used as a control verifier or mistaken for a full adversarial exercise. The NIST Cybersecurity Framework 2.0 reinforces the need for continuous improvement, governance, and outcome-driven assurance rather than checkbox testing. That is a better lens for CART: it can make testing more frequent, but it does not remove the need for human judgment, adversarial creativity, and contextual interpretation. In practice, many security teams discover the limits of CART only after an attacker has already taken a path no test case ever covered.

How It Works in Practice

CART, or continuous automated red teaming, usually works by replaying known attack behaviours across a controlled environment or production-like surface area. It tests whether detections fire, whether response workflows trigger, and whether defensive changes break expected attack chains. That makes it valuable for regression testing after policy changes, cloud hardening, identity control updates, or SIEM tuning.

Used well, CART helps teams answer operational questions such as: did the latest rule change reduce visibility, did the EDR policy still catch credential misuse, and did a new cloud control block the intended technique without causing false confidence elsewhere? Human red teams answer different questions. They explore ambiguity, stitch together weak signals, and adapt when an initial route fails. That is why CART and red teaming serve different assurance functions.

A practical operating model usually looks like this:

• CART runs frequently against a curated set of attack paths and control checks.
• Human red teams run less often but focus on novel chaining, business context, and objective-based adversary emulation.
• Findings from both feed the same remediation and validation loop.
• Detection engineering uses CART to prove that a fix actually works before it is considered closed.

Where identity is part of the attack surface, CART is especially useful for validating privileged access paths, credential misuse detection, and segmentation assumptions, but it still cannot fully model how a real adversary pivots across people, processes, and tooling. Guidance from the MITRE ATT&CK knowledge base is helpful here because it anchors testing in observable techniques rather than abstract threat narratives, and the CISA adversarial emulation planning approach remains useful for structuring human-led scenarios. These controls tend to break down in highly dynamic cloud and SaaS environments because attack paths and permissions change faster than automated test libraries are updated.

Common Variations and Edge Cases

Tighter automation often increases maintenance overhead, requiring organisations to balance test frequency against environment drift and false assurance. That tradeoff is most visible in hybrid estates, fast-moving CI/CD pipelines, and identity-heavy environments where entitlements, service accounts, and API permissions change daily. In those settings, CART can become noisy if test cases are not continuously curated.

There is also no universal standard for how much red teaming is “enough.” Current guidance suggests using CART for breadth and cadence, then reserving human-led exercises for depth, ambiguity, and high-impact scenarios. If the objective is validating a narrow control set, CART may be sufficient for that slice of assurance. If the objective is stress-testing resilience, decision-making, or lateral movement across complex business processes, human expertise remains essential.

Edge cases emerge when defenders overfit to known techniques. A mature CART program may show excellent coverage against routine credential abuse, but still miss an unconventional combination of identity misuse, cloud misconfiguration, and process weakness. The NIST Cybersecurity Framework 2.0 supports a layered assurance model rather than a single testing method, which is the right way to think about this choice. The practical rule is simple: automate the repeatable parts, and keep humans on the problems that require context, creativity, and judgment.

Related resources from NHI Mgmt Group

• When should organisations block an AI agent instead of letting teams use it?
• What do teams get wrong when they rely on human-in-the-loop controls for AI?
• What do teams get wrong when they rely on human approval for every agent action?
• What breaks when organisations rely on audit logs instead of runtime enforcement?