Adversarial exposure validation: what the category means, and the slice Arxiis covers

Adversarial exposure validation is an analyst category, not a product, and Arxiis covers one narrow slice of it. The slice is web applications and APIs inside a written scope, where we produce stored evidence that an attack worked. We do not validate security controls across an estate. This post sets out what the category says, how it differs from breach and attack simulation, and where our line sits.

What the definition says

The term comes from Gartner. Its public Peer Insights page defines AEV as "technologies that deliver consistent, continuous and automated evidence of the feasibility of an attack."

The same page says these tools run attack scenarios, then model or measure the outcome to show that an exposure exists and can be exploited. It says AEV is generally delivered as SaaS, with or without on-premises agents.

Gartner lists four outcomes the results can feed:

1. Confirming that a theoretical exposure is real.
2. Automating frequent testing of controls.
3. Improving preventive security posture.
4. Improving detection and response.

The full Market Guide sits behind Gartner's paywall. Everything here comes from the public definition and from vendor pages that cite it.

What the category replaced

Gartner's public page says AEV replaces three entries from its 2023 Hype Cycle for Security Operations: breach and attack simulation (BAS), automated penetration testing, and red teaming technology.

So AEV is a merged category. Products that used to sit under different labels now sit under one. That is useful for analysts tracking a market. For buyers it creates a problem: two products in the same category can do different jobs and produce different kinds of evidence.

Vendor pages also place AEV inside continuous threat exposure management (CTEM), as the validation stage of a five-stage cycle: scoping, discovery, prioritization, validation and mobilization. CTEM is a programme. AEV is the tooling for one stage of it.

We covered the "which job are you hiring for" question in Pentera alternatives. This post goes one level down, into what the definition's words should mean when you buy.

AEV vs BAS

BAS is the older and narrower idea. Picus, a BAS vendor, describes it as simulating attacks to measure and optimise security controls. The question BAS answers is whether your defences stopped or saw a known technique.

Automated penetration testing asks a different question. It tries to find and exploit real weaknesses in a defined target. The output is a list of exploitable findings, not a control score.

Both produce "evidence of the feasibility of an attack". The evidence is not the same artefact.

Neither column is better. They answer different questions, and a mature programme usually needs both.

Measured or modelled: the word that matters

The definition says these tools "model or measure" the outcome. That one word choice decides what you are buying.

A modelled result says an attack path is likely to work, based on what the tool knows about your environment. It is useful for prioritising. It is not proof, and an engineer cannot reproduce it.

A measured result says something was actually run against an agreed target and produced an observable outcome. It can be reproduced, and it can be audited.

When a vendor says "validated", ask which of the two they mean, for each finding. Ask to see the artefact behind one example. If the answer is a severity score and a description, the result was modelled. If the answer is a stored record of what was run, when, against which target and with what response, it was measured.

We wrote more about what that artefact should contain in Penetration testing evidence.

Where Arxiis sits, and where it does not

Arxiis is a human-supervised, autonomous offensive-security platform. A crew of LLM operator-agents runs an authorized penetration test of web applications and APIs end to end. Every command the crew runs is written to a tamper-evident, hash-chained execution ledger.

Against Gartner's four outcomes, our honest position is this:

1. Confirming that a theoretical exposure is real. Yes, for web applications and APIs inside a written scope. A finding is labelled proven only when its evidence binds to a real ledger record. Otherwise it is labelled needs review.
2. Automating frequent testing of controls. No. We do not replay techniques to score your defensive controls. That is BAS work.
3. Improving preventive posture. Indirectly. Fixing proven findings improves posture, but we do not measure posture.
4. Improving detection and response. No. We do not measure whether your SOC saw the test.

On XBOW-104 sweeps (19 October 2026), our cross-level solve rate is 56% raw and 44% confirmed. Our measured false-positive rate on those sweeps is 0%. We solve about 82% of common web bugs at the level-1 tier only. Hard chained and blind attacks sit at 0–42%, a known weak spot we are working to close.

So if your AEV question is "can anything in these apps actually be exploited, with proof I can hand an engineer", Arxiis answers part of it. If your question is "would our controls stop a known technique across the estate", you need a different tool.

Why scope belongs inside the definition

"Continuous and automated" can sound like a tool that runs wherever it likes. In an authorized test it must not.

Arxiis will not engage a non-local target without a written authorization file, a SCOPE plus rules of engagement. A scope guard checks every outbound request against that file. Escalation needs a human operator's approval. A budget and time watchdog stops the run at the limits you set and writes a partial, honest report.

Any AEV product you buy should be able to show the same things: where the scope is written, what enforces it, and what happens at the edge of it. Our guardrails post lists the questions to ask.

Combining tools in one programme

Because AEV merged three older categories, many buyers end up with more than one product inside it. That is fine if each one has a clear job.

A common split looks like this:

• Controls validation for detection and prevention coverage across the estate.
• Exploit validation for exposed web applications and APIs, with stored evidence per finding.
• Human-led testing for business logic, complex chains and anything that needs judgment.

Write down which tool owns which question. Overlap wastes budget. Gaps are worse, because each team assumes another tool covered it.

Questions to ask any AEV vendor

Use these in a demo or an RFP. They work whichever part of the category the product comes from.

1. Which of Gartner's four outcomes does your product deliver, measured rather than modelled?
2. For one finding, show me the stored artefact behind it. Can my engineer reproduce it from that alone?
3. What do you report when a result cannot be confirmed? Does it appear as a finding, a lower severity, or a separate label?
4. Where is the scope written, what enforces it, and what happens when a request falls outside it?
5. Which surfaces do you measure today, and which do you only model?
6. What do you not cover? Ask for the list, not the brochure.

Our RFP template turns these into scored questions.

Reading the category label honestly

Category labels help analysts compare markets. They do not tell you what a product does on Tuesday morning against your applications.

Treat "AEV vendor" as the start of the conversation. The useful facts are the job the product does, the surface it measures, and the artefact that comes out at the end. For Arxiis that is web applications and APIs, inside a written scope, with each proven finding bound to a ledger record and everything else labelled needs review.

Frequently asked questions

What is adversarial exposure validation (AEV)?

Adversarial exposure validation is a Gartner category. Gartner's public definition describes technologies that deliver consistent, continuous and automated evidence of the feasibility of an attack. It merged three earlier categories: breach and attack simulation, automated penetration testing and red teaming technology.

What is the difference between AEV and BAS?

BAS is one part of AEV. It replays known techniques to check whether your security controls stop or detect them. Pentest-style validation looks for real, exploitable weaknesses in a defined target and reports them as findings. Both now sit inside the AEV category, but they answer different questions.

Is Arxiis an AEV tool?

Arxiis covers one slice of what the category describes: confirming that exposures in web applications and APIs are real, inside a written scope, with each proven finding bound to a record in a tamper-evident ledger. It does not test security controls across an estate or measure detection and response. Arxiis is not claimed to be listed or rated by Gartner.

What does measured mean, compared with modelled?

A modelled result estimates that an attack path would work, based on what the tool knows about your environment. A measured result comes from something actually run against an agreed target, with a stored record of what was sent and what came back. Measured results can be reproduced and audited.

Do I need more than one AEV product?

Often, yes, because the category covers different jobs. Write down which product owns controls validation, which owns exploit validation for exposed applications, and where human-led testing fits, so there are no gaps between them.