Autonomous AI pentesting expands the ability to automate investigations requiring context: permissions, relationships between users, business rules, and action sequences. The change matters because many vulnerabilities reveal their impact only when the test understands how an application works and how its parts connect.
Specialists could already discover these problems. The new opportunity is to perform part of this investigation autonomously and repeatedly, reducing dependence on manual analysis for every hypothesis. Effective coverage remains tied to access, scope, and operational evidence.
What does coverage mean in a pentest?
Coverage involves more than counting visited addresses. An application may have been accessed while a privileged role, critical integration, or business sequence remains untested. It is essential to know which contexts the test actually reached.
In practice, several questions arise: which assets were assessed? Which roles were used? Which application functions and states were explored? Which attack hypotheses were validated? When did this occur relative to the current version?
The Ares manifesto presents Vultus's vision for this evolution: treating applications as systems with users, permissions, APIs, integrations, and rules, connecting exposure to impact. This guides an investigation focused on attack paths.
From scheduled checks to adaptive hypotheses
Static analysis, dynamic analysis, and automated checks continue to help identify known conditions. Agent-led investigation adds the ability to interpret a response, form another hypothesis, and adapt the testing sequence.
For example, an error message may reveal a relationship between two functions. One role may see an operation but face a different restriction when completing it. Interpretation adds value when these signals guide a new question and the environment provides evidence to answer it.
To substantiate a finding, a test must distinguish observation from inference. The hypothesis may come from the agent; proof of improper access or behavior must come from the authorized target.
Permissions: the same function can produce different results
Consider a fictional portal with customers and internal operators. A user may have legitimate access to the document lookup function without being authorized to access every document it returns.
Testing this scenario requires distinct roles and knowledge of who should access each object. The OWASP category API1:2023, Broken Object Level Authorization, addresses this distinction between access to a function and authorization over an object.
An autonomous architecture can investigate these differences with appropriate test accounts. Without that access, assessment of the context is limited. Documenting this dependency makes coverage clearer to decision-makers.
Business workflows: a legitimate function can also be abused
Imagine another fictional example: a scheduling service that allows bookings without an appropriate per-user limit. The function may operate as expected on every request and still allow a sequence of actions to undermine commercial availability.
The OWASP API6:2023 category discusses unrestricted access to sensitive business flows. Its relevance depends on how the function is used and the impact on that organization.
This type of hypothesis requires business context and a controlled way to demonstrate the issue, using agreed limits and test data. The specialist helps define what behavior would be abusive and what evidence is sufficient to guide remediation.
Kill chains: the impact may lie in the combination
An initial exposure may reveal information enabling a second action. That action may gain further access. Connecting these steps demonstrates an attack path and helps locate the controls that should interrupt it.
In autonomous investigation, agents can use the results of one stage to guide subsequent hypotheses. It is important to maintain traceability across this sequence: initial conditions, actions taken, evidence obtained, and impact observed within scope.
The series ARES KILLCHAINS BREAKDOWN shows investigations performed by Ares. To understand the concept organizing these paths, also see what is a cyber kill chain.
How to make coverage verifiable
- Assets and functions: identify what was assessed and what remains pending.
- Roles and states: record access used and relevant conditions in the workflow.
- Hypotheses and evidence: distinguish validated behavior, suspicion, and testing limitations.
- Paths and impact: connect the stages and demonstrated consequence.
- Version and retesting: indicate when the assessment took place and what was confirmed after remediation.
No single percentage describes coverage for every application. The set of functions, roles, and integrations varies from one environment to another. Results should therefore be explained in terms of what the investigation reached and what still depends on context or access.
Combining autonomy and offensive experience
Ares combines a multi-agent adversarial architecture, a proprietary harness, and Vultus's Red Team expertise to investigate these paths. Agents support execution and recurrence; specialists guide objectives, limits, and impact interpretation.
This combination brings discovery closer to the application's regular change cycle. Understand how to organize continuous testing and explore Vultus autonomous AI pentesting.
