AI-powered security testing is widening the gap between defenders

At a glance

What this is: This is FireCompass’s case that AI is changing offensive security from periodic testing to continuous, platform-led validation of exploitability.

Why it matters: It matters because security teams responsible for IAM, NHI, and broader cyber controls need evidence-driven validation, not just scan noise, to understand real exposure and reduce attacker dwell time.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read FireCompass's analysis of the Great AI Divide in security testing

Context

AI-powered security testing is creating a governance gap because traditional scan-and-alert workflows were built for periodic review, not continuous exploit validation. In a security context, the problem is not just finding more issues, but proving which ones an attacker can chain into meaningful impact. That distinction is especially relevant to IAM and NHI programmes, where exposed credentials, excessive privilege, and incomplete asset discovery often determine whether a path is exploitable.

FireCompass frames the divide as an operational split between organisations that are already using AI to continuously test attack surfaces and those still evaluating adoption. The broader lesson is that the security model itself is changing: coverage, repeatability, and proof of exploitability matter more than isolated findings. For practitioner teams, this is not a maturity slogan. It is a warning that point-in-time validation is becoming an incomplete control model.

Key questions

Q: How should security teams use AI-driven testing in the development lifecycle?

A: Security teams should place AI-driven testing inside normal development workflows so findings arrive before production, not after release. The useful pattern is continuous validation during design, build, and pre-release review, paired with human judgment for prioritisation. That reduces late-cycle noise and makes remediation cheaper because the code context is still fresh.

Q: Why is attack-path validation more useful than raw vulnerability counts?

A: Raw counts tell you how many issues exist, but not which ones an attacker can actually chain together. Attack-path validation shows whether a weakness reaches a critical asset, whether identity controls block escalation, and whether the issue is exploitable in context. That makes remediation decisions sharper and reduces noise-driven fatigue.

Q: What do security teams get wrong about runtime penetration testing?

A: They often focus on what the model can find and ignore what the model is allowed to do. Runtime offensive testing is an execution problem as much as a detection problem, so the real risk sits in permission scope, tool chaining, and whether human review happens before harmful action can proceed.

Q: Should organisations prioritise AI testing platforms over separate point tools?

A: When attack-path context matters, integrated platforms usually produce better operational decisions than disconnected tools. Separate products may each find issues, but they often lose the chain that explains impact. If your programme needs continuous coverage across discovery, validation, and red teaming, platform integration is usually the cleaner governance choice.

Technical breakdown

Why continuous attack-path validation is replacing scan-and-alert

Traditional vulnerability management produces lists of issues, but not necessarily evidence that an attacker can reach a crown-jewel asset. Continuous attack-path validation combines discovery, exploitation checks, and chaining logic to show how weaknesses interact across web, API, and network layers. In practice, the key technical shift is from finding-centric reporting to path-centric analysis, where the environment is assessed as a connected system rather than disconnected assets. That is why AI-assisted testing is attractive: it can keep revisiting assumptions as the environment changes, rather than waiting for the next quarterly cycle.

Practical implication: Prioritise testing that proves exploitability and attack paths, not just vulnerability counts.

How AI agents change offensive security workflow economics

AI agents can automate reconnaissance, triage, and repetitive validation steps at a scale that manual-only teams cannot match. The technical advantage is not magic autonomy, but orchestration across many small tasks with shared context and low false-positive churn. That changes the economics of testing: broader scope becomes feasible, and continuous coverage can replace sparse sampling. For governance teams, the important point is that automation does not remove the need for controls. It shifts the control point toward agent scope, auditability, and deterministic validation of results.

Practical implication: Treat AI testing agents as governed systems with constrained scope, logging, and reviewable output.

Why platform integration matters more than isolated security tools

When attack-surface discovery, penetration testing, and red teaming live in separate tools, findings are often disconnected from one another. A platform approach matters because attack chains depend on context preserved across stages, from initial discovery through exploitation to lateral movement. The architecture challenge is therefore data continuity, not just model capability. A system that can correlate recon output with validation results and red-team paths gives security leaders a truer picture of exposure than multiple standalone point tools with incompatible data models.

Practical implication: Favour integrated workflows that preserve context across discovery, validation, and red-team stages.

Threat narrative

Attacker objective: The attacker aims to turn broad discovery into a reliable path to deeper access, privilege expansion, or operational disruption.

1. Entry typically begins with automated reconnaissance across web, API, and network surfaces to identify exposed assets, weak authentication paths, or misconfigurations.
2. Escalation follows when validated findings are chained into exploit paths that reveal what an attacker can actually reach and whether privilege can be expanded.
3. Impact occurs when attackers move from isolated weaknesses to real access, lateral movement, or data exposure across connected systems.

NHI Mgmt Group analysis

AI-driven testing is becoming a control, not just a tool category. Once offensive testing can run continuously, the governance question changes from whether to test to what level of assurance is required between tests. That aligns with broader exposure management thinking in NIST CSF and MITRE ATT&CK, where control effectiveness depends on current evidence rather than annual validation. Practitioners should treat continuous testing as part of the security control set, not as an adjacent service.

Attack-path visibility is the named concept practitioners should care about here. The article’s real implication is that disconnected findings no longer describe risk well enough. Attack-path visibility means understanding how multiple weaknesses, identity exposures, and misconfigurations combine into a reachable compromise path. For IAM and NHI teams, that matters because credential exposure and privilege breadth are often only visible when systems are analysed in sequence, not in isolation. Practitioners should demand evidence of path context, not just issue volume.

AI changes the economics of exploitability proof more than it changes the existence of vulnerabilities. Vulnerabilities have always been present, but AI compresses the time needed to discover, validate, and operationalise them. That means security programmes anchored only in backlog reduction will underperform if they cannot prove what is exploitable now. The practitioner implication is to shift budget and attention toward continuous validation, attack-path analysis, and governance of automated security agents.

The divide is less about model capability than about operational design. Many teams will be able to access the same foundation models, but not all will build the orchestration, governance, and auditability needed to use them safely. That creates a durable programme gap. The organisations that design for repeatable outcomes, bounded autonomy, and shared context will get more value from AI security testing. Practitioners should assess whether their operating model can sustain that discipline.

For identity programmes, this is a warning that machine access and attack validation are converging. AI-led testing increasingly surfaces the same weak points that NHI and IAM teams struggle with in production: exposed secrets, overprivileged service accounts, and weak segmentation. The right response is not to treat offensive AI as separate from identity governance. Practitioners should align exposure testing with identity controls and privilege review cycles.

What this signals

Attack-path visibility will become a programme-level expectation, not a specialist output. As AI compresses discovery and validation cycles, security leaders will need continuous evidence that exposed assets, secrets, and identity pathways are not forming reachable compromise chains. Teams that already track identity-linked exposure will adapt faster than those still relying on quarterly snapshots.

The Great AI Divide will show up inside identity programmes first. When AI testing starts surfacing overprivileged service accounts, stale tokens, or weak segmentation between systems, IAM and NHI teams will be asked to prove control effectiveness more frequently. That will reward programmes that already connect identity lifecycle, attack-path analysis, and remediation workflows.

Continuous validation should be paired with governance references such as MITRE ATT&CK and CISA cyber threat advisories. The practical signal is that offensive testing and threat-informed defence are converging. Practitioners should prepare for more board questions about exploitability, not just exposure volume.

For practitioners

• Map continuous testing to real attack paths Replace or supplement periodic scans with workflows that validate whether findings can be chained into reachable paths toward critical assets, including identity and privilege pivots.
• Govern AI testing agents explicitly Define scope, allowable actions, logging, and review requirements for AI-powered offensive tools so automation stays within approved boundaries and produces auditable evidence.
• Correlate identity exposure with exploitability Join secrets, service account, and access review data to attack-path findings so teams can see whether exposed credentials or standing privilege create real escalation routes.
• Retire point-in-time confidence measures Stop using annual test completion as a proxy for resilience. Measure how often critical assets are revalidated, how quickly exploitable findings are confirmed, and whether coverage is continuous.

Key takeaways

• The core problem is not more findings, but proving which findings create real attack paths.
• AI is changing offensive security economics by making continuous validation and red teaming more achievable at scale.
• Identity, secrets, and privilege governance become more important when attack paths can be validated faster than manual teams can review them.

Key terms

• Clinical Attack-Path Visibility: Clinical attack-path visibility is the ability to trace how a cyber event moves into systems that affect patient care. It links security telemetry to clinical impact, helping teams understand whether an incident threatens records, workflows, medical devices, or care delivery itself.
• Exploitability proof: Exploitability proof is evidence that a vulnerability can or cannot be turned into a working attack in a specific environment. It goes beyond severity scores by testing real paths, privileges, configurations, and dependencies that determine whether an attacker can achieve impact.
• Continuous validation: Continuous validation is the practice of re-checking user, device, or session risk after login instead of trusting access indefinitely. It recognizes that identity assurance can drift during a session, especially when endpoint state or user context changes after authentication.
• Bounded Autonomy: Bounded autonomy means a system can act independently within defined limits, but cannot exceed those limits without human or policy control. In agentic governance, the boundary must be explicit, testable, and logged, because the real compliance question is where autonomous action stops.

What's in the full article

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

• How its agent workflow is structured across reconnaissance, validation, and red teaming
• What the platform claims about coverage across web, API, and network attack surfaces
• How it handles transparency, bounded autonomy, and repeatable outputs in testing workflows
• What the article says about cost structure and continuous testing economics

👉 The full FireCompass post covers the platform model, testing workflow, and governance choices behind its argument.

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. It helps practitioners connect identity controls to the broader security programme they are responsible for.