Continuous automated red teaming exposes the annual red team gap

At a glance

What this is: This is FireCompass’s explanation of continuous automated red teaming, showing how it discovers, validates, and chains exploit paths across a changing external attack surface.

Why it matters: It matters to IAM, PAM, and NHI practitioners because leaked credentials, shadow apps, and identity abuse are central paths from discovery to lateral movement in modern environments.

By the numbers:

• Most DAST tools produce 40 to 70 percent false positives, creating triage noise instead of validated exposure insight.
• Annual testing typically covers about 20 percent of the attack surface, leaving the remaining 80 percent untested for most of the year.

👉 Read FireCompass's analysis of continuous automated red teaming and the annual red team gap

Context

Continuous automated red teaming addresses a governance gap that point-in-time testing cannot close: attack surfaces change faster than review cycles, and identity exposure often appears after scoping is complete. In practice, that means forgotten subdomains, leaked credentials, and newly shipped endpoints can sit outside the evidence base while security teams still rely on a prior report.

The identity angle is real because the article repeatedly ties exploitation to credential reuse, shadow assets, and pivot paths into production systems. That makes CART relevant not just to application security teams, but also to IAM and NHI owners who need proof that external exposure, authentication flows, and privileged access paths are being re-tested as the environment changes.

Key questions

Q: What breaks when red team testing is only done once a year?

A: Annual testing breaks down when the attack surface changes faster than the engagement cycle. New endpoints, shadow apps, and leaked credentials can appear after scoping but before remediation, which means the report quickly becomes stale. Security teams need continuous validation if they want evidence that reflects current exposure rather than last quarter’s environment.

Q: Why do leaked credentials matter so much in attack path testing?

A: Leaked credentials matter because they let an attacker move from discovery to authenticated abuse instead of stopping at a public-facing flaw. Once a credential is valid, the next risk is reuse across apps, privilege escalation, and lateral movement. That is why identity and attack-surface teams need to treat credential exposure as a path, not an isolated event.

Q: What are the signs that automated red teaming is not truly red teaming?

A: If a platform only finds vulnerabilities, but does not chain them into a multi-stage path, it is behaving like an advanced scanner rather than a red team. Another warning sign is the absence of working proof-of-concept exploitation or shadow asset discovery. Red-team value starts when the tool demonstrates how multiple weaknesses combine into real compromise.

Q: How should security teams govern autonomous pentesting agents safely?

A: Treat them like high-risk non-human identities with bounded authority. Define scope, payload limits, approval gates, and revocation paths before deployment. Then require immutable logging, reproducible evaluation, and periodic review of what the agent can reach so capability does not outrun governance.

Technical breakdown

How continuous attack surface discovery changes testing coverage

CART starts by discovering assets from the organisation name rather than a pre-approved inventory. That matters because shadow apps, forgotten subdomains, JavaScript-exposed APIs, and leaked credentials often exist outside the CMDB and outside the annual test scope. Continuous discovery means newly created endpoints can be queued for assessment as soon as they appear. The mechanism is closer to continuous exposure mapping than scheduled assessment, which is why it can keep pace with M&A sprawl and fast release cycles.

Practical implication: teams need a discovery source of truth that updates testing scope automatically instead of relying on a static asset list.

Why exploit validation is different from vulnerability scanning

The article distinguishes CART from DAST by insisting on working proof-of-concept exploitation, not just payload responses or CVSS scores. A real CART workflow validates whether a finding can actually be exploited, then records the exact reproduction steps and evidence. This reduces false positives and shifts triage from theoretical risk to demonstrated exposure. For identity-heavy environments, that matters because a reusable credential or broken auth flow can be more valuable to an attacker than a high-severity scan result.

Practical implication: require validated exploit evidence before prioritising remediation, especially where authentication and credential reuse are involved.

How attack chaining turns isolated findings into real breach paths

The red-team layer in CART links separate findings across apps, APIs, and identity systems into multi-stage attack paths. A leaked credential from one surface can be tested against another, then combined with broken access control or app-to-network reachability to reach internal infrastructure. This is the difference between finding vulnerabilities and proving operational compromise. The article explicitly maps this to the MITRE ATT&CK kill chain, which makes chaining an adversary emulation exercise rather than a reporting feature.

Practical implication: measure whether your testing platform can demonstrate credential reuse, privilege escalation, and lateral movement, not just single-asset flaws.

Threat narrative

Attacker objective: The attacker objective is to turn a small external foothold into a demonstrated multi-stage path into higher-value systems, especially through credential reuse and lateral movement.

1. Entry occurs when attackers obtain leaked credentials, discover exposed subdomains, or find forgotten apps outside the original asset list.
2. Escalation follows when those credentials are reused, authentication is bypassed, or a broken access control path lets the attacker pivot into a more privileged environment.
3. Impact comes from chaining the initial foothold into lateral movement toward production systems, including internal infrastructure or directory services.

NHI Mgmt Group analysis

Continuous exposure validation is replacing point-in-time assurance. Annual red team reports describe a moment in time, not an operational state. When applications, credentials, and attack paths change weekly, assurance has to become continuous or it becomes historical. The practical conclusion for security leaders is that exposure evidence should refresh with the environment, not with the audit calendar.

Credential exposure is the bridge between application security and identity security. FireCompass’s framing is significant because it treats leaked credentials and auth reuse as first-class attack paths, not side observations. That is exactly where IAM, PAM, and NHI governance intersect with external attack surface management. Organisations that separate these disciplines will keep missing the path from public exposure to privileged access.

Attack chaining is the named concept that security teams need to operationalise. Isolated findings are no longer enough when attackers can chain discovery, credential abuse, and lateral movement into one path. The relevant governance question is whether testing proves a multi-stage path, not whether a scanner found a defect. Practitioners should treat chain validation as the real output of red-team quality.

Autonomous testing only helps when guardrails are explicit. The article is right to highlight scope controls, logging, and human approval options, because autonomous security tooling without bounded execution creates its own risk. For teams adopting AI-driven testing, the issue is not whether automation exists, but whether every action is auditable and constrained. The conclusion is that autonomy must be governed like privileged access.

CART is a strong fit for compliance evidence, but only if the evidence is reproducible. Continuous logs are more useful than a one-off PDF when frameworks expect documented testing, but auditors still need clear scope, control, and repeatability. That makes CART most valuable when it produces traceable evidence aligned to testing and access governance, not when it is used as a marketing substitute for assurance.

What this signals

Continuous automated red teaming is becoming a practical control for organisations that cannot keep attack-surface inventories current. The governing issue is not whether testing exists, but whether discovery, exploitation, and chaining are tied to live change events so the evidence stays current. That is where external exposure management starts to overlap with identity governance, especially when leaked credentials and reused authentication flows are in play.

Exposure chain validation: the more useful metric is no longer the number of findings, but whether a testing workflow can prove a path from public exposure to privileged reach. Teams should align this with MITRE ATT&CK Enterprise Matrix and track whether identity-linked footholds can be chained into later-stage compromise.

For NHI and IAM teams, the practical signal is simple: if leaked secrets, service credentials, or reusable tokens are not being re-tested as part of the external attack surface, the programme is blind to one of the fastest routes from discovery to impact. That is a governance problem, not just a tooling gap.

For practitioners

• Rebuild testing scope around live discovery Use continuous asset discovery as the source of scope so newly exposed subdomains, APIs, and shadow apps are tested without waiting for the next annual cycle.
• Require proof-of-concept validation before triage Treat scan findings as hypotheses until the testing workflow produces working exploit evidence, reproduction steps, and a traceable chain of impact.
• Measure credential reuse paths explicitly Prioritise tests that prove whether exposed credentials can be reused across environments, authentication flows, or directory-linked systems.
• Audit guardrails before enabling autonomous runs Define exactly what the testing agent can touch, what requires approval, and how every action is logged before you allow production-aligned execution.

Key takeaways

• Annual red team results age quickly when new assets and credentials appear after scoping.
• The key value in CART is not automated scanning, but validated attack chaining across identities and systems.
• Governed autonomy, live discovery, and proof-of-concept exploitation are the controls that make continuous testing usable.

Key terms

• Automated red-teaming: Automated red-teaming is the use of adversarial test generation to find how an AI model or agent fails under pressure. It goes beyond manual review by systematically probing prompt injection, goal drift, unsafe outputs, and other repeatable behavioural weaknesses before production use.
• Attack Chain: An attack chain is a sequence of prompts, observations, and tool calls that moves an AI agent from a benign starting point to a harmful result. In agent security, the chain matters more than any single prompt because real risk often emerges only when actions accumulate across steps.
• Exploit Validation: The process of proving that a suspected vulnerability is actually exploitable by producing a working proof of concept. This is a high-value security task because it separates real exposure from noise and can be automated with sufficient model and workflow support.
• Shadow Asset: An internet-facing application, subdomain, API, or service that exists outside the organisation’s intended inventory or governance process. Shadow assets often become the easiest entry point because they are forgotten by defenders but still reachable by attackers.

What's in the full article

FireCompass's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step breakdown of the discover, pentest, and chain workflow across external assets and identity-linked paths
• Benchmark results and proof-of-concept validation examples that show how the platform measures exploitability
• Scope guardrails and execution modes for autonomous or expert-in-the-loop testing in production-aligned environments
• Compliance mapping detail for PCI DSS 4.0, SOC 2, and ISO 27001 audit evidence

👉 The full FireCompass post covers attack chaining, guardrails, and benchmark details in more depth.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners building stronger identity controls. It helps security teams connect access governance to real-world exposure and lifecycle risk.