For years, cybersecurity teams have relied on vulnerability scanning and periodic penetration testing to identify weaknesses before attackers can exploit them. But real-world cyberattacks rarely follow a predictable path. Rather than exploiting a single vulnerability, attackers often combine stolen credentials, misconfigurations and seemingly minor security gaps to work their way through an organisation’s systems and reach critical assets.
As cyberattacks become more sophisticated, AI is adding another layer of complexity. Attackers can now use AI to accelerate reconnaissance, identify weaknesses and adapt their techniques as an attack unfolds. Yet many organisations are still relying on point-in-time security assessments, leaving a growing gap between how attackers operate and how businesses test their defences. Research from Filigran found that 97% of security professionals struggle to determine whether identified exposures are actually exploitable, highlighting the limitations of treating vulnerabilities in isolation.
The IT Security Guru spoke to Pierre-Loic Kuhn, Senior Product Marketing Manager at Filigran, about the growing importance of attack chaining, why vulnerability severity doesn’t always reflect real-world risk, how autonomous AI agents are transforming penetration testing and red teaming, and why human oversight remains essential as organisations move towards continuous security validation.
Q: Cybersecurity teams have spent years testing individual vulnerabilities and attack techniques. Why is that becoming less representative of how real attacks happen?
Because in real life, attackers don’t just run one attack and stop there. They have an objective, and they’ll keep trying different entry points, techniques and tools until something works. Think of a burglar breaking into your house: If the front door is locked, they don’t call it a day. They pick the lock, try the back door, check for an open window… and once they’re inside, they look for the spare keys, work out how to move without setting off the alarm, figure out where the safe is and how to crack it open. Cyberattacks work the same way,an attacker gets initial access through a phishing email, a stolen credential, or an unpatched web server. Then they escalate privileges, move laterally, set up persistence and head for the crown jewels. Each step uses whatever the last one turned up.
So testing one CVE or one ATT&CK technique on its own is like checking that the front door is locked and saying the house is secure. That’s useful, but it doesn’t tell you whether someone can get from the garden to the safe. The real risk is usually in how the steps chain together and in the gaps between your controls. That’s the shift to adversarial exposure validation. You stop asking “are we vulnerable?” and start asking “if a real attacker comes at us the way they actually operate, do our defences stop them?”
Q: What exactly is an attack chain, and why should security leaders care about the path an attacker can take rather than individual vulnerabilities in isolation?
An attack chain is the sequence of steps an attacker takes to get from an initial foothold to their objective. In reality, a breach rarely hinges on one catastrophic vulnerability. Rather, attackers combine weaknesses, credentials, misconfigurations, and legitimate functionality to move through an environment until they reach something valuable. Each individual step might look relatively innocuous when viewed alone, but together they can create a viable route to compromise.
That is why security teams need to understand attack paths as well as individual exposures. A collection of vulnerabilities rated “medium” or other lower-severity weaknesses ,can combine to create a critical path to a sensitive system. Looking at that chain changes the remediation conversation because instead of going through a list of vulnerabilities, teams can identify where breaking one “chokepoint” could prevent an attacker progressing any further. For security leaders, that’s how prioritisation turns into real risk reduction.
This is particularly important when security teams already have more vulnerabilities and alerts than they can realistically address. For example, Filigran’s State of Threat Management research found that 84% of organisations face attacks exploiting risks that were already known but had not been prioritised. The objective should therefore be to establish which exposures can genuinely be used against you, how they connect and which ones matter most.
Q: Can a series of relatively low or medium-risk weaknesses combine to create a much more serious attack path? How should that change the way organisations prioritise remediation?
Absolutely, that’s actually very often how breaches happen. Severity scores like CVSS are useful indicators, but they cannot tell you everything about how a vulnerability behaves within a particular environment. A weakness that looks relatively unimportant in isolation can become much more significant if it provides access to another system, exposes a credential or enables an attacker to progress towards a critical asset. For example, a low-rated information leak that reveals a service account password can be the first step on a direct route to a sensitive file server.
This is one reason organisations struggle with prioritisation. Filigran’s research found that 97% of security professionals experience difficulty determining whether exposures are actually exploitable. If teams simply work their way through vulnerabilities according to severity, they risk spending valuable time fixing issues that are technically serious but difficult to exploit while leaving a viable, albeit lower severity, attack path open elsewhere.
Security teams should therefore be thinking about attack path management alongside vulnerability management, and prioritise based on what’s exploitable, what’s reachable and what sits at the end of the path, not on the score alone. The point is to start from the attackers point of view: “If they started here, what could they do next?” Continuous validation can provide the evidence needed to answer that and help teams identify the chokepoints in a chain where remediation will have the greatest effect down the line.
Q: Filigran’s research found that 97% of organisations struggle to determine whether their exposures are actually exploitable. Why is there still such a gap between identifying a vulnerability and understanding whether it represents a genuine risk?
Because finding a vulnerability and proving it can be exploited are two very different jobs. Scanners are good at the first one. They match software versions against known CVEs and give you a severity score, but what they can’t tell you is the context. Is that system actually reachable? Would your EDR or WAF block the exploit? Is a compensating control already in place? What could an attacker reach from there? Answering those questions has usually meant a pentest or a red team exercise, which is slow and expensive and happens once or twice a year, while new CVEs land every week. So teams end up with long lists of theoretical risk and very little evidence about which items an attacker could really use. Closing that gap means testing exposures the way an attacker would, and doing it continuously, not just counting them.
Q: How is AI changing the way attackers discover, combine and exploit weaknesses, and are defensive security teams keeping pace?
In short, AI is changing attacks in two ways: it makes each step faster, and makes the whole chain more adaptive.
AI compresses the time and effort required to perform tasks that previously demanded significant manual work. Reconnaissance, vulnerability discovery, phishing, code generation and analysis can all be accelerated. More importantly for attack chaining, AI systems can potentially interpret the result of one action and use it to determine what to try next – which is exactly how a human operator would behave. That changes the speed and adaptability of offensive activity. Rather than following a completely predetermined script, an AI-enabled attacker can potentially discover an unexpected opening and alter course mid-attack. It’s essentially a double-edged sword: the same class of technology that helps defenders identify vulnerabilities and secure systems can also shorten the time attackers need to discover weaknesses, adapt techniques and scale their activity.
Defenders need comparable speed during validation, but most are still lagging – while attacks adapt in hours, most security testing still happens a few times a year. But closing that gap does not mean simply adding AI to every security process. The goal is to connect threat intelligence, exposure data and validation so that teams can move more quickly from information to decision and from decision to action. Automation is most valuable when it removes repetitive work and allows human expertise to concentrate on judgement, investigation, prioritization, and remediation.
Q: Are we reaching the point where annual or periodic penetration testing is simply too slow for modern environments?
Traditional penetration testing remains extremely valuable, particularly because skilled human testers bring creativity, experience and intuition that automated systems cannot easily replace. They can also test physical security to test for tangible vulnerabilities – something even the most advanced AI cannot replicate (at least in the foreseeable future).
The problem is the point-in-time nature of these exercises. Cloud environments, identities, applications, endpoints, and configurations can change continuously, meaning the environment tested several months ago – or even just yesterday – may be very different from the one an attacker sees today.
That is why periodic testing increasingly needs to be complemented by continuous validation. Filigran’s research found that security teams still rely heavily on manual processes, including 88% that use manual processes to some degree for offensive attack simulation. The same research found only 38% use threat intelligence within a continuous, fully automated validation process.
Automation allows organisations to repeatedly test known attack techniques and paths as their environment changes. Human red teams and pentesters can then spend more of their time on complex scenarios, novel techniques and the kinds of creative thinking where their expertise delivers the greatest value. It is a misconception that concepts like “automated pentesting” and “Continuous Automated Red Teaming (CART)” will replace offensive teams; rather, they exist to scale their function to face the modern threat landscape.
Q: What role should autonomous AI agents play in penetration testing and red teaming, and where should humans remain in control?
Autonomous agents have an interesting role because they can make security testing more adaptive. Instead of executing a fixed sequence of actions, an agent can work towards an objective, assess what happened after each step and determine the most appropriate next action. That begins to resemble the way a real attacker behaves.
The value is scale and the ability to turn threat intelligence into practical security decisions. Security teams cannot manually investigate and test every possible combination of vulnerabilities, identities, configurations and controls. Filigran’s unified XTM Platform brings together threat intelligence, exposure validation and risk reduction through agentic continuous threat exposure management (CTEM). AI agents work across this process, sharing context to help teams identify relevant threats, test which exposures are exploitable, validate defences and prioritise action. This reduces manual hand-offs and gives analysts a connected workflow for understanding where they are exposed and how to reduce that risk.
Human control remains essential, however. People should define the objective, scope, permitted actions and escalation boundaries. Autonomous security testing should expand what practitioners can investigate, while keeping its actions visible and accountable to the people responsible for the environment.
OpenAEV Attack Chaining lets offensive teams decide how much they want to automate: build and run every step with full manual control, or hand the entire process – from scenario generation to execution – to agents completely. Or, keep a human in the loop anywhere in between.
Q: Does autonomous security testing introduce risks of its own? What guardrails need to be in place?
Of course. Giving an AI system the ability to take actions inside a live environment requires considerably more thought than asking a model to summarise an alert. Testing could affect production systems, interact with sensitive assets or produce unexpected outcomes if its scope is poorly defined.
So guardrails have to be designed into autonomous testing from the outset. Organisations need clear boundaries around which assets can be targeted, what actions are permitted and how far a test is allowed to progress. They also need visibility into what the system is doing and why, alongside comprehensive auditability and the ability for a human operator to intervene. Every action should be logged and audited, and anything the test leaves behind must be cleaned up, in the same discipline a human offensive tester would have.
But to be clear, we’re not releasing AI agents to roam freely in a network. The agents orchestrate and make decisions from the platform – every action still runs through the same controlled executors, inside a closely defined scope. It’s a nuance there to keep in mind.
There is also a broader lesson here for agentic security. Automation without context or control can simply automate poor decisions faster. Organisations must strive to maintain some level of control as they adopt AI. In security, autonomy needs to come with transparency, defined limits and human accountability.
Q: If testing reveals several possible routes to an organisation’s critical systems, how should security teams decide what to fix first?
This is where attack chaining can become particularly useful. The most important finding is often not the vulnerability with the highest severity score. It may be the control, credential, permission or exposure that sits at a chokepoint shared by several viable attack paths.
If fixing one issue breaks multiple paths to a critical asset, that remediation may deliver substantially greater risk reduction than addressing several unrelated vulnerabilities. Security teams can therefore move away from treating remediation as a growing queue of individual findings and, more aptly, towards understanding which interventions have the greatest defensive impact.
In OpenAEV, “Chokepoints” are automatically flagged in your tested attack path, which you can drill down into to see how the path ran through it and why it matters. Fix the chokepoint and you break the path from that point on – a single fix can cut off many attack paths down the line.
Threat intelligence should also inform that decision. Knowing which adversaries are relevant to the organisation, the techniques they are currently using and which assets matter most provides context for deciding which paths deserve attention first. A CTEM approach tackles this by bringing structured threat context into scoping, discovery and prioritisation, then using validation to establish exploitability and control effectiveness.
Ultimately, the useful question for a CISO is moving from “how many vulnerabilities did we close?” to “which realistic routes to our most important assets have we actually removed?”
