Listen to this Post
Introduction: Security Testing Is Entering a More Realistic Era
Cyberattacks rarely happen as a neat sequence of isolated vulnerabilities. Real attackers look for connections. A leaked password can lead to a workstation, that workstation can expose another credential, and a seemingly insignificant privilege can eventually become the key to a critical server.
That reality is forcing security teams to rethink how they validate their defences.
Filigran has introduced a major new capability in OpenAEV v3 called Attack Chaining, designed to simulate exactly this kind of adaptive behaviour. Instead of asking whether a single security control can stop a particular technique, the platform attempts to determine whether several weaknesses can be connected into a realistic path toward compromise.
The timing is significant. Modern organisations are dealing with increasingly complex environments, cloud infrastructure, identity systems, SaaS platforms, AI applications and increasingly automated adversaries. At the same time, security teams are under pressure to distinguish theoretical vulnerabilities from weaknesses that could actually be chained together.
OpenAEV v3 is Filigran’s answer to part of that problem.
Its new approach combines attack simulation, dynamic decision-making, visual attack-path mapping and AI agents to create a more flexible form of adversarial testing. The goal is not simply to generate another list of vulnerabilities. It is to show defenders how those weaknesses could work together.
The Biggest Change: From Vulnerabilities to Attack Paths
Traditional security validation often examines individual controls separately.
Can the EDR detect this malware behaviour?
Can the email gateway block this phishing message?
Can a privileged account be prevented from accessing a particular system?
Can a firewall stop a connection to a restricted service?
Those questions remain important. But they can also create a dangerous blind spot.
An organisation might successfully defend against dozens of individual techniques while still leaving a viable route to its most valuable systems.
Attackers do not necessarily care whether one vulnerability is considered “critical” on its own. They care about what that vulnerability allows them to do next.
That is the fundamental idea behind Attack Chaining.
A Small Weakness Can Become a Serious Compromise
Imagine a simulated attacker discovers a valid credential.
On its own, that credential might not appear catastrophic.
But suppose the credential works against another internal machine.
That machine exposes a service.
The service reveals additional information.
That information allows privilege escalation.
The elevated permissions provide access to another environment.
Eventually, the attacker reaches a sensitive database.
None of those individual steps necessarily represents the entire attack.
The danger lies in the chain.
OpenAEV v3 is designed to model that chain dynamically rather than treating each action as an isolated test.
OpenAEV v3 Makes the Simulation Adaptive
One of the most important aspects of the new functionality is that the simulated attack can respond to what it discovers.
In a traditional fixed scenario, defenders may define a sequence such as:
Send phishing email.
Execute payload.
Establish access.
Attempt privilege escalation.
Reach a target.
Attack Chaining introduces greater flexibility.
If the simulated attacker discovers a credential, that discovery can influence the next step.
If a permission is available, it can become part of the following action.
If a network port is open, the simulation can investigate whether it creates another route.
If a security control blocks one path, the simulation can potentially explore another permitted route.
This makes the exercise more representative of an attacker who is continuously learning from the environment.
The Difference Between Testing and Understanding Risk
There is an important distinction between proving that a vulnerability exists and demonstrating that it matters.
A vulnerability scanner might tell an organisation that a particular weakness exists.
A penetration test might demonstrate that a specific technique works.
Attack-path validation asks a broader question:
What happens if this weakness is combined with everything else the attacker can discover?
That question is increasingly important as enterprise environments become interconnected.
Identity systems communicate with cloud services. Cloud services connect to applications. Applications connect to databases. Employees interact with external services. Developers use third-party packages. AI agents increasingly interact with internal systems.
The attack surface is no longer a collection of independent doors.
It is a network of connected doors.
Filigran’s Research Highlights the Problem
Filigran says its recent State of Threat Management report illustrates why this type of validation is becoming increasingly important.
According to the company, 97% of surveyed organisations struggle to determine whether their exposures are actually exploitable.
The report also found that 84% said attacks frequently exploit risks that were already known but had not been prioritised.
Another important finding was that 88% of respondents still rely to some extent on manual processes for offensive attack simulation.
Those figures point toward a familiar security problem.
Organisations can have enormous quantities of security data without necessarily understanding which combination of weaknesses creates the greatest danger.
Security Teams Do Not Need More Noise
Modern security operations already generate enormous amounts of information.
Vulnerability scanners produce findings.
SIEM platforms generate alerts.
Endpoint systems report suspicious activity.
Cloud security tools identify configuration problems.
Identity platforms highlight unusual behaviour.
Threat-intelligence systems provide indicators.
The challenge is increasingly about connecting the dots.
Attack chaining attempts to turn isolated findings into something more meaningful: a narrative of compromise.
Instead of saying that five weaknesses exist, the platform can potentially show how those weaknesses could interact.
That distinction can dramatically change remediation priorities.
Finding the Chokepoint Can Matter More Than Fixing Everything
Not every vulnerability needs to be treated equally.
Suppose an attack chain contains six different weaknesses but depends on one particular privilege escalation opportunity.
Fixing the privilege escalation issue might break the entire chain.
That could be more valuable than spending weeks addressing several lower-impact findings that do not materially change the attack path.
This is where the concept of chokepoints becomes especially interesting.
OpenAEV v3 allows defenders to see where an attack path depends on specific controls, permissions or weaknesses.
The objective becomes more strategic:
Which remediation will eliminate the greatest amount of attacker freedom?
A Live Graph Shows the Attack Unfolding
OpenAEV v3 introduces a live attack-path graph that visualises the simulation as it progresses.
Each hop can be represented within the graph.
Branches can reveal alternative routes.
Findings can provide context.
Defensive controls can show where progress stopped.
For security teams, this could make adversarial testing considerably easier to understand.
Instead of receiving a static report at the end of an exercise, analysts can observe how the simulated attacker moves through the environment.
That visual representation can also help security leaders communicate technical risk to executives.
A sentence saying “multiple medium-severity vulnerabilities can be chained” may not immediately resonate.
A visual path showing:
Internet → Employee → Workstation → Credential → Internal Server → Privileged Account → Critical Database
is much harder to ignore.
AI Agents Become Part of the Red Team
Perhaps the most ambitious component of the release is the integration of AI agents into attack simulation.
OpenAEV can operate manually, autonomously through AI agents, or through a hybrid approach.
In operator-led mode, human security professionals determine the attack logic and control execution.
In agent-led mode, the operator can provide an objective and defined scope in natural language.
The AI agent can then construct and adapt the attack chain according to the results it encounters.
This represents a significant shift in how red-team exercises could be conducted.
From Fixed Scripts to AI-Guided Objectives
The difference can be illustrated simply.
A traditional instruction might effectively resemble:
Test whether this specific attack technique can compromise the endpoint.
An agent-based objective could instead be:
Within the approved environment, determine whether an attacker can reach the specified critical asset using available attack paths.
The second objective gives the system more freedom to reason about intermediate steps.
That freedom can make simulations more realistic.
But it also creates new safety requirements.
Scope Controls Become Critical
AI-driven offensive security is powerful precisely because AI systems can make decisions dynamically.
That same flexibility introduces risk if boundaries are poorly defined.
Filigran says
Those controls are essential.
An autonomous red-team system should never be treated like an unrestricted attacker.
The organisation must define where the agent can operate, what assets it can interact with, which actions are allowed and what constitutes a hard boundary.
Logging is equally important because defenders need to understand not only what happened, but also why the simulation took a particular route.
AI Can Also Generate Social Engineering Exercises
The
Filigran says the system can include activities such as generating phishing emails and landing pages as part of controlled social-engineering exercises.
This is important because real attacks often combine technical exploitation with human manipulation.
An attacker might begin with an email.
A compromised account could then provide access to internal systems.
Those systems might expose additional credentials.
The credentials could lead to another account.
The chain can continue.
Attack Chaining therefore has the potential to model the interaction between human and technical weaknesses rather than treating them as separate security disciplines.
The Rise of Agentic Cybersecurity
Filigran’s direction is also consistent with a broader movement across cybersecurity: the transition from automation based on predefined workflows toward agentic security systems.
Traditional automation says:
“If condition A occurs, execute action B.”
Agentic systems attempt to operate with a goal in mind and determine which actions are appropriate along the way.
That distinction matters enormously for adversarial security testing.
Attackers do not normally follow perfectly predictable scripts.
They adapt.
They experiment.
They abandon dead ends.
They search for alternative routes.
They exploit whatever new information they obtain.
Security validation needs to become more adaptive if it is going to reproduce that behaviour convincingly.
XTM One Expands the Bigger Strategy
The Attack Chaining release also fits into
The company previously introduced XTM One, which brings AI orchestration across OpenCTI and OpenAEV.
The objective is to connect threat intelligence, attack scenario generation, validation and remediation guidance into a broader workflow.
That creates an interesting possibility.
Threat intelligence could inform what scenarios should be tested.
Attack simulation could determine whether those scenarios are actually viable.
The resulting findings could then influence remediation.
The cycle could become increasingly automated.
OpenAEV Is Also Expanding Into AI Security Testing
Attack Chaining is not the only major addition in OpenAEV v3.
The release also introduces AI red-teaming injectors designed to test LLM-powered agents and chatbots.
This is particularly relevant as companies increasingly deploy AI systems that can interact with data, applications, APIs and internal infrastructure.
Traditional security controls such as EDR, SIEM and email security remain essential.
But AI systems introduce additional attack surfaces.
Prompt manipulation, unsafe tool usage, excessive permissions, data exposure and agent autonomy can all create new security challenges.
Testing these systems with adversarial simulations is becoming increasingly important.
The Adversarial Exposure Command Center
OpenAEV v3 also introduces a redesigned dashboard called the Adversarial Exposure Command Center.
The idea is to bring multiple dimensions of security validation into a single interface.
Security teams can view security posture, simulation results and detection coverage together.
That consolidation is valuable because attack validation can otherwise become fragmented across multiple tools.
The more effectively defenders can connect exposure data with actual attack outcomes, the easier it becomes to make risk-based decisions.
A New Adversarial Exposure Score
The platform also introduces an Adversarial Exposure Score intended to help organisations track validation results across different exposure sources.
Metrics like this can be useful when they represent meaningful security outcomes rather than becoming another vanity number.
The strongest use case is likely to be trend analysis.
If an organisation repeatedly validates its environment, it should be able to see whether attack paths are becoming harder to complete.
A useful score should therefore answer a practical question:
Are our defences actually improving?
Why This Matters in the Age of AI-Powered Attackers
The security industry is entering a strange new phase.
AI can help defenders analyse enormous quantities of information.
But the same technology can also help attackers automate reconnaissance, generate social-engineering content, analyse code and accelerate decision-making.
The advantage may increasingly go to the side that can make decisions faster.
That is why adaptive security validation matters.
A security team that only tests yesterday’s attack patterns may have excellent historical visibility while remaining vulnerable to tomorrow’s attack path.
Deep Analysis
What Attack Chaining Really Changes
The deeper significance of OpenAEV v3 is not simply that Filigran added another feature.
It represents a shift from technique-centric security validation toward objective-centric validation.
Instead of asking whether a specific exploit works, teams can ask whether a defined objective can be achieved within a controlled environment.
That is closer to how sophisticated adversaries actually operate.
A Simplified Attack-Chain Model
A conceptual attack path might look like this:
Initial Access
↓
Compromised Identity
↓
Internal Discovery
↓
Credential Exposure
↓
Privilege Escalation
↓
Lateral Movement
↓
Critical Asset
The important point is that each stage creates new information.
That information influences the next decision.
Example: Mapping an Internal Attack Surface
Security teams can use ordinary defensive tools to inspect their environment before launching controlled simulations.
For example:
Identify listening services on an approved Linux test host ss -tulpn
Review local users
cut -d: -f1 /etc/passwd
Review current identity and privileges
id sudo -l
These commands are useful for defenders conducting authorised assessments because they help establish the environment’s exposure.
The actual attack simulation should remain restricted to systems and accounts explicitly included in the engagement scope.
Network Visibility Matters
A defender can also establish which systems communicate with one another.
For example:
Display the routing table ip route
Inspect active network connections
ss -tunap
Test connectivity to an approved internal host
ping -c 4 192.0.2.10
In a controlled lab, these observations can help security teams understand whether an apparently isolated system has paths to other assets.
The Important Question Is Not “Can It Be Exploited?”
A better question is:
“What can an attacker reach after exploiting it?”
That distinction is enormous.
A low-impact vulnerability on an isolated development machine may have limited practical consequences.
The same weakness on a system containing reusable credentials could become much more important.
Attack chaining exposes that difference.
Chaining Changes Vulnerability Prioritisation
Traditional prioritisation often revolves around severity scores.
Attack-path prioritisation adds another dimension:
exploitability plus connectivity plus privilege plus business impact.
A vulnerability that provides access to nothing valuable may deserve less immediate attention than a moderate weakness that acts as a bridge toward a critical asset.
That does not mean severity ratings become irrelevant.
It means they become one input among several.
The Human Analyst Still Matters
AI agents can accelerate testing, but that does not eliminate the need for experienced security professionals.
Humans remain responsible for defining objectives.
Humans understand business context.
Humans determine acceptable risk.
Humans interpret unusual behaviour.
Humans decide what remediation is appropriate.
The most effective model is therefore unlikely to be “AI replaces the red team.”
It is more likely to be:
AI expands what the red team can test.
Logging Could Become One of the Most Valuable Features
When autonomous agents make security decisions, traceability becomes essential.
A useful audit trail should allow defenders to reconstruct:
Objective
↓
Observation
↓
Decision
↓
Action
↓
Result
↓
Next Decision
That chain of evidence is critical for validating whether an AI-driven simulation actually behaved within the intended boundaries.
It can also reveal why a particular security control failed.
Attack Graphs Can Improve Executive Communication
Security teams frequently struggle to translate technical findings into business risk.
Attack graphs can help bridge that gap.
Executives may not need to understand every technical detail behind a vulnerability.
They do need to understand that:
one unresolved weakness could provide a route from an employee endpoint to a business-critical system.
That is an easier risk story to communicate.
The Real Value Could Be in Finding the Cheapest Fix
Suppose an attack path contains ten steps.
Security teams might instinctively attempt to fix all ten.
But perhaps only one step is essential.
Remove that step and the entire chain collapses.
That is the strategic promise of attack-path analysis.
The goal is not necessarily to fix everything immediately.
The goal is to identify the intervention that produces the greatest reduction in attacker capability.
AI Red Teaming Will Become Increasingly Important
The addition of AI red-teaming capabilities is especially timely.
Organisations are deploying AI assistants that can access documents, databases, APIs and business systems.
An AI application with excessive permissions can become a security problem even if the underlying infrastructure is perfectly patched.
Security teams therefore need to test not only the model but also:
Its permissions.
Its tools.
Its connected data.
Its authentication.
Its output handling.
Its ability to follow untrusted instructions.
Its behaviour under adversarial input.
Its interaction with external systems.
AI security cannot be reduced to model accuracy.
It is increasingly an infrastructure-security problem too.
Agentic Attack Simulation Raises the Stakes
There is an important irony here.
Defenders are building autonomous agents to simulate attackers because attackers are increasingly using automation themselves.
That creates a technological feedback loop.
Attackers automate discovery.
Defenders automate validation.
Attackers adapt their techniques.
Defenders build adaptive simulations.
The result could be a security industry where continuous adversarial testing becomes normal rather than something organisations perform once or twice a year.
Continuous Validation Could Replace Periodic Testing
The traditional penetration-test model is often periodic.
A test happens.
A report is produced.
Vulnerabilities are fixed.
Months pass.
The environment changes.
The report becomes outdated.
Attack chaining combined with automation could enable a more continuous model.
Every major infrastructure change could potentially trigger a new validation scenario.
That would make security testing more closely aligned with modern DevOps and cloud environments.
The Challenge Is Avoiding False Confidence
There is also a major limitation.
No simulation can reproduce every possible attacker.
An AI agent may find a path that humans missed.
But it can also miss a path that a highly skilled attacker would discover.
Therefore, automated attack validation should not be interpreted as proof that an environment is secure.
A successful simulation is evidence of risk.
A failed simulation is evidence about that specific scenario under those specific conditions.
That distinction must remain clear.
Scope Is the Foundation of Safe Automation
The more autonomy a security platform receives, the more important scope becomes.
Production systems must be carefully separated from testing environments where appropriate.
Credentials must be controlled.
High-impact actions need safeguards.
Destructive techniques should be explicitly restricted.
Every action should be attributable.
And the organisation should be able to stop the simulation immediately.
AI-powered offensive security is only useful when its operational boundaries are stronger than its capabilities.
OpenAEV’s Direction Reflects a Larger Industry Shift
Filigran’s strategy is part of a broader transformation in cybersecurity.
Security tools are moving from passive observation toward active validation.
They are increasingly being asked not only:
“What is vulnerable?”
but also:
“Can this vulnerability actually be used?”
and then:
“What happens if it is combined with everything else?”
That third question is where attack chaining becomes particularly powerful.
The Future of Security Validation May Be Path-Based
The industry has spent years building increasingly sophisticated systems for discovering vulnerabilities.
The next phase may focus more heavily on relationships.
Which identity connects to which system?
Which system exposes which privilege?
Which weakness unlocks which capability?
Which defensive control breaks the chain?
Which remediation eliminates the greatest amount of risk?
Those are fundamentally graph problems.
And attack-path visualisation provides a natural way to represent them.
What Security Leaders Should Watch
Organisations evaluating AI-driven security validation should pay particular attention to several areas.
First, scope enforcement.
Second, auditability.
Third, attack-path transparency.
Fourth, integration with existing security controls.
Fifth, the quality of remediation recommendations.
Sixth, the ability to reproduce findings.
The best platform will not simply demonstrate that an attack worked.
It will explain why it worked and what defenders should change.
The Most Important Metric May Be Attacker Distance
One useful concept emerging from attack-path thinking is “attacker distance.”
How many meaningful barriers separate an external attacker from a critical asset?
A strong security architecture increases that distance.
A weak architecture creates shortcuts.
Attack chaining gives organisations a way to experimentally measure those shortcuts.
That can be much more informative than counting vulnerabilities alone.
Why OpenAEV v3 Is Significant
OpenAEV v3 arrives at a time when security teams are under pressure to do more with fewer resources.
Automation can help.
AI can help.
But neither is valuable without context.
The real promise of Attack Chaining is that it combines automation with context by examining how one discovery can influence the next stage of an attack.
That moves security validation closer to the dynamic nature of real-world intrusions.
What Undercode Say:
The Security Industry Has Been Counting the Wrong Things
For years, organisations have measured security maturity through vulnerability counts, patch percentages and alert volumes.
Those metrics are useful.
But they do not always explain how an attacker can actually win.
A network can contain thousands of vulnerabilities without presenting a practical route to its most important systems.
Conversely, a handful of relatively ordinary weaknesses can become dangerous when connected.
That is why attack chaining deserves attention.
Attack Paths Are More Important Than Isolated Findings
The most valuable output from a security test may not be a list of vulnerabilities.
It may be a map showing how those vulnerabilities interact.
That map can change remediation priorities.
It can also expose architectural problems that individual scanners cannot see.
AI Makes This Approach More Powerful
Human red teams are exceptionally valuable, but they are expensive and cannot continuously explore every possible path.
AI agents could potentially examine far more combinations.
That does not make AI superior to human expertise.
It makes AI a force multiplier.
The Hybrid Model Looks Most Promising
We believe the strongest implementation will combine human direction with machine exploration.
Humans define the rules.
AI searches the possibilities.
Humans validate the findings.
Security teams then determine the appropriate response.
That model balances automation with accountability.
Attack Chaining Could Change Vulnerability Management
Imagine a vulnerability-management programme that does not simply rank weaknesses by CVSS.
Instead, it asks:
What systems can this weakness reach?
What credentials can it expose?
What privileges can it provide?
What other vulnerabilities can be combined with it?
Which critical assets become reachable?
That would create a much more realistic risk-prioritisation model.
The Chokepoint Concept Is Particularly Valuable
Security teams rarely have unlimited remediation resources.
Finding the single weakness that breaks an entire attack chain can provide enormous value.
It allows defenders to focus effort where it produces the greatest defensive return.
That is a much more mature approach than trying to treat every finding equally.
AI Security Testing Is Becoming Impossible to Ignore
The inclusion of LLM and agent red-teaming capabilities is perhaps just as important as Attack Chaining itself.
AI systems are becoming connected to real business processes.
Some can access sensitive information.
Others can execute tools.
Some can interact with external services.
That means AI applications must increasingly be treated as part of the attack surface.
Security Teams Need to Test the Whole System
Testing only the model is not enough.
The surrounding permissions may be vulnerable.
The tools may be vulnerable.
The APIs may be vulnerable.
The authentication layer may be vulnerable.
The data pipeline may be vulnerable.
The
The security boundary therefore needs to include the entire AI application stack.
The Biggest Risk Is Blind Trust in Automation
AI-driven security tools should never become a black box.
If an agent says it discovered a path, defenders should be able to understand the evidence.
If it stops, analysts should understand why.
If it makes a decision, the decision should be logged.
Transparency is not an optional feature for autonomous security.
It is a requirement.
Attack Simulation Could Become Continuous
The most exciting long-term possibility is continuous adversarial validation.
Infrastructure changes every day.
Applications are deployed continuously.
Permissions change.
Employees join and leave.
Cloud configurations evolve.
AI services are added.
Security testing must eventually move at a similar speed.
Security Will Become More Experimental
Instead of asking whether a policy theoretically protects an organisation, teams can increasingly test it.
Instead of assuming a control works, they can challenge it.
Instead of assuming vulnerabilities are harmless, they can examine how they interact.
This is a healthier security philosophy.
The Battle Is Moving From Detection to Prevention
Detection remains critical.
But the strongest security programmes increasingly want to understand what happens before an attacker reaches a critical asset.
Attack chaining provides a framework for exploring those pre-compromise pathways.
That makes it valuable even when no actual breach has occurred.
AI Versus AI Will Not Be the Whole Story
It is tempting to describe the future as autonomous attackers versus autonomous defenders.
The reality will probably be more complicated.
Human judgement, organisational policy, architecture and governance will remain essential.
AI will simply increase the speed and scale at which both sides operate.
The Winning Security Teams Will Understand Relationships
The next generation of security professionals may spend less time asking:
“What vulnerabilities do we have?”
and more time asking:
“How do our vulnerabilities connect?”
That is a subtle but profound shift.
OpenAEV Is Betting on That Shift
Filigran’s OpenAEV v3 is built around the idea that attack simulation should resemble actual adversarial behaviour more closely.
Attackers adapt.
The platform adapts.
Attackers chain weaknesses.
The platform chains findings.
Attackers search for paths to valuable assets.
The platform visualises those paths.
That alignment is what makes the release interesting.
There Is Still a Long Road Ahead
No product can solve enterprise security by itself.
Attack simulation does not replace patching.
AI does not replace security architecture.
Attack graphs do not replace experienced analysts.
But together, these capabilities can make security decisions more evidence-driven.
The Most Valuable Outcome Is a Broken Attack Path
Ultimately, the best result from an adversarial simulation is not a frightening report.
It is a changed environment.
A permission is removed.
A credential is protected.
A network path is segmented.
A detection rule is improved.
An AI agent receives fewer privileges.
A critical attack chain disappears.
That is what security validation should accomplish.
OpenAEV’s Bigger Message
The central message behind OpenAEV v3 is simple:
Security cannot be measured only by what attackers fail to exploit individually. It must also be measured by whether attackers can combine weaknesses into a path toward something valuable.
That is a much harder problem.
It is also a much more realistic one.
✅ Attack Chaining Is Part of OpenAEV v3
The supplied article states that Filigran introduced Attack Chaining with OpenAEV v3, allowing simulated attack steps to influence subsequent actions.
This accurately describes the central capability presented in the source material.
The concept is specifically focused on dynamically connecting findings such as credentials, permissions and exposed services.
✅ AI-Agent Operation Is Included
The article states that Attack Chaining can be operated manually, autonomously through AI agents, or through a hybrid approach.
It also says users can provide an objective and scope in natural language for agent-led simulations.
This is consistent with the capabilities described in the supplied source.
✅ OpenAEV v3 Includes AI Security Testing
The article correctly identifies AI red-teaming injectors as part of the release.
These capabilities are intended to allow organisations to test LLM-powered agents and chatbots alongside more traditional security controls.
That reflects the broader movement toward treating AI systems as part of the modern attack surface.
⚠️ AI Does Not Guarantee Real-World Attacker Equivalence
Even sophisticated autonomous attack simulation cannot guarantee that every real attacker path will be discovered.
Attackers can behave unpredictably, exploit undocumented weaknesses and combine human intelligence with technical capabilities.
Therefore, OpenAEV simulations should be treated as evidence-based validation rather than absolute proof that an environment is secure.
⚠️ Security Metrics Need Context
The reported percentages from
They are useful indicators of industry sentiment, but they should not automatically be interpreted as universal measurements of every organisation.
The underlying sample, methodology and question wording matter when evaluating such statistics.
Prediction
(+1) Attack Chaining Will Become a Major Direction in Security Validation
The security industry is likely to move increasingly toward attack-path validation as organisations realise that isolated vulnerability scores do not fully represent practical risk.
AI agents will probably make this approach more scalable by continuously exploring combinations of weaknesses under controlled conditions.
Over time, security teams may increasingly prioritise vulnerabilities based on the attack paths they enable rather than their individual severity alone.
(+1) AI Red Teaming Will Expand Beyond Traditional Infrastructure
As AI agents gain access to enterprise data, APIs and business applications, organisations will increasingly need to test AI systems as complete applications rather than treating language models as isolated components.
Security platforms that can test both traditional infrastructure and AI-powered systems through a common validation framework could become increasingly valuable.
(+1) Continuous Adversarial Validation Could Become Normal
The long-term direction is likely to be continuous testing rather than occasional penetration tests.
Cloud changes, identity changes, application deployments and AI integrations can constantly alter an organisation’s attack surface.
Automated attack-path validation could help security teams discover when those changes unintentionally create new routes toward critical assets.
(-1) Poorly Controlled Autonomous Testing Could Create New Risks
The more freedom AI agents receive, the more important operational safeguards become.
An improperly scoped autonomous security agent could potentially disrupt systems, access unintended resources or generate misleading conclusions.
For that reason, strong scope enforcement, logging, approval controls and emergency termination mechanisms will remain essential as agentic security becomes more powerful.
▶️ Related Video (82% Match):
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: www.itsecurityguru.org
Extra Source Hub (Possible Sources for article):
https://stackoverflow.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
