AI penetration testing · authorized · evidenced

Know what's exploitable. And what was never tested.

Ten specialist agents test your authorized estate in parallel — web, API, network, Active Directory, cloud, SAP, mobile, LLM applications, source and supply chain, and dark-web exposure. A separate validator then kills any finding it cannot reproduce, and per-asset coverage makes every untested surface explicit.

Real tools, human control at the risk boundary. Everything runs inside a contained scanner against a scope you authorize. Credential spray, NTLM relay, DCSync — anything that could lock an account or take a service down — is staged for your operator, never auto-fired.

What a run gives you How it proves a finding

117 attack skills82 detectors10 huntersone contained toolchain

acme-external wave 0

crit

high

med

low

info

agents

shipped 0 killed 0 staged 0 runs 14

Illustrative run · synthetic target, scripted timeline

The premise

Most "AI security" output is a scanner with a language model stapled to it.

That combination is very good at producing volume and very bad at producing truth — a confident paragraph attached to a 200 response, a severity picked to look impressive, and no answer at all to the question that actually matters, which is what never got looked at. Three commitments separate this from that.

A 200 is not an impact

A finding does not count until someone has fired the exploit and read the result back independently. Candidates go to a validator whose explicit job is to disprove them and argue the severity down. Missing-header classes stay informational unless a working chain is demonstrated. You stop paying people to triage a machine's optimism.

No finding ≠ not vulnerable

An empty result has two causes that look identical in a report: the check ran and found nothing, or the check never ran. Coverage is graded against the detector registry and a human-judgment checklist, and anything applicable that didn't execute is either forced to run or recorded as not-assessed. A gap is a colour on a matrix, not an absence you have to notice.

Autonomy stops where lockout starts

Credential spray, NTLM relay, DCSync, any write or persistence — those carry account-lockout and production-incident risk, so the fleet stages them instead of firing them. Each arrives with its precondition, what it proves if it lands, and the exact command, for a human to run inside the agreed window.

The fleet

Ten specialists. One wave.

Recon maps the estate, then every specialist that applies to it starts at the same time.

Wave 0 recon exposure

Wave 1 — in parallel

webinjection · access control · logic · smuggling · SSRF
apiBOLA · BFLA · mass assignment · OAuth/SAML · MFA bypass
networkedge appliances · VPNs · databases · middleware · hypervisors
active directoryKerberoasting · AD CS · delegation · coercion · DCSync
cloudIAM escalation · public storage · metadata pivots · k8s · IaC
sap & erpRFC gateway · message server · default creds · PLM
mobileexported components · deep links · secrets · bundled CVEs
ai & llmprompt injection · RAG poisoning · tool misuse · guardrails
code & supply chaintaint · authn · crypto · dependency confusion · typosquats
exposureinfostealer logs · breach corpora · pastes · verified JS secrets

Then validate coverage

Execution

It runs the tools. It doesn't imagine their output.

The agents don't reason about what a scanner would probably say — they invoke the real offensive toolchain inside a reviewed container and read the actual output back. Every invocation goes through one wrapper that enforces scope, egress, rate limits and evidence capture, so nothing reaches a host that isn't in the agreed list.

Detection signatures refresh on a daily schedule — template sets, exploit and vulnerability databases, the software-composition database. A stale signature set is a blind spot that reports as clean, so freshness is graded against upstream rather than by age.

Discovery

subfinderamasshttpx nmapgaukatana

Exploitation

nucleisqlmapffuf dalfoxcommixmetasploit

Identity

bloodhoundimpacketcertipy netexechashcat

Secrets & supply chain

trufflehoggitleaksosv-scanner trivygrypesyft

The evidence gate

Prove it, or it doesn't ship.

Between the hunters and the report sits an adversarial reviewer that reproduces each candidate and tries to take it apart. It sets severity; nothing upstream or downstream gets to re-rate it. A theoretical bug is downgraded or killed outright, and the kill is recorded with the observation that decided it — so a sceptical reader can audit the rejections, not just the acceptances.

That is the difference between a report you forward and a report you have to re-test. The severity counts mean something because the things that would have inflated them were removed on purpose, by a process that shows its work.

required: a working exploit plus an independent read-back — the effect observed through a second channel, not inferred from a status code
downgraded: anything theoretical, unreachable, or dependent on a precondition nobody demonstrated
killed: false positives, with the reason kept and browsable rather than silently dropped
severity: set once, by the validator, against the ladder — not negotiated by the agent that found it

findings stay one consolidated, de-duplicated set across every run against the target

Two outcomes

The same gate produces both of these.

One candidate survived and one did not. Read them together — the rejection is the harder thing to show, and the reason it is worth showing is that most candidates end up on the right-hand side.

shipped high

Cross-tenant object read on /v2/orders/{id}

Evidence: Authenticated as tenant B, requested an order id belonging to tenant A. Response returned tenant A's line items and billing address.
Read-back: Confirmed through a second channel — the same record was retrieved via the tenant-A export endpoint and matched byte-for-byte. Not inferred from a 200.
Impact: Any authenticated tenant can enumerate other tenants' orders. Sequential ids make enumeration trivial.
Remediation: Enforce tenant scoping in the data-access layer, not the controller. Reject on ownership mismatch before serialisation.
Validator's note: "Reproduced twice from a clean session. Severity held at high, not critical: read-only, no write path demonstrated, no privilege escalation."

killed was: critical

Reported RCE via template injection on /search

Claim: Scanner flagged a template-injection signature; the hunter's candidate proposed remote code execution.
What was tried: Arithmetic payload reflected unevaluated. Sleep payload produced no measurable delay across 20 samples. Out-of-band callback never fired.
Why it failed: The reflection is HTML-escaped output, not template evaluation. The signature matched on a brace pattern in a user-supplied string.
Outcome: Killed, not downgraded — there is no weaker true version of this finding.
Validator's note: "A critical severity on an unproven RCE is how a report loses its reader. No evaluation, no execution, no finding."

Illustrative records against a synthetic target. Every kill stays in the corpus with its reason, so the rejections are auditable alongside the acceptances.

Assurance

You are told what wasn't tested.

This is the part an auditor asks for, and the part a finding count cannot answer. Coverage is graded per asset against the detector registry: what finished, what ran partially, what needs a human, what is genuinely not applicable — and, in its own colour, what was never assessed at all.

A completeness gate runs before the report and forces anything applicable but skipped to execute, or records it explicitly. So "we found nothing on that host" and "we never looked at that host" can never arrive looking the same, which is how a clean-looking assessment quietly becomes a false assurance.

Where it sits

A finding count is not an assurance statement.

Most tools in this space answer "what did you find?". The harder question — the one an audit committee asks — is "what does this cover, and what does it leave open?"

How Vantage compares with vulnerability scanning, a point-in-time pentest, and breach-and-attack simulation
	Vulnerability scanning	Point-in-time pentest	Breach & attack simulation	Vantage
Evidence standard	Signature match	Tester's judgement	Simulated technique	Reproduced exploit with independent read-back
False positives	Yours to triage	Low, but not itemised	N/A — no real target	Killed before delivery, with the reason kept
Coverage reported	What it scanned	Narrative scope note	Techniques attempted	Per asset, including not assessed
Breadth in one pass	One class at a time	Bounded by people	Control-focused	Ten specialisms in parallel
Cadence	Continuous	Annual or quarterly	Continuous	Repeatable, one consolidated corpus
Risky actions	Not attempted	Human-run	Safely simulated	Staged for your operator, never auto-fired

Methodology

Fifteen phases. One gate they all pass through.

These are the phase names your operators see in the console, not a marketing abstraction of them.

Pre-flightauthorize
Reconmap
Breadthsweep
Edge bypassreach
Artifact intelenrich
Depthexploit
Auth closurecover
Discoveryexpand
Captureevidence
Visual triageconfirm
Validateprove
Coveragegrade
Finalizeconsolidate
Debrieflearn
Reportdeliver

the evidence gate — nothing reaches Report without it CTEM Scoping → Discovery → Prioritisation → Validation → Mobilisation · PTES · NIST SP 800-115 · CVSS · KEV · EPSS

Authorization

Nothing starts without written authorization.

Scope is resolved per engagement and fails closed — if it cannot resolve, the authorized host count is zero and nothing runs. Exclusions beat every wildcard above them. A preflight check blocks an active launch outright unless a valid, engagement- matched authorization with an open, timezone-aware testing window is in place.

Mass exfiltration, destructive payloads, denial of service at scale, and any indiscriminate or unauthorized targeting are refused categorically — not gated, not stageable. The staged worklist to the right is the other half: real capability, deliberately held back for a person.

Validate harvested service ticket offline high if confirmed

precondition: domain user context; testing window open; ticket already captured
risk: none online — cracking is offline; no authentication attempts leave the host
owner: operator runbook — not auto-fired

# run inside the agreed change window
hashcat -m 13100 tickets.txt wordlist.txt \
  --status --status-timer=30

Copy only. The platform never executes a staged command.

The console

And you can watch the whole thing happen.

A run is not a black box that returns a PDF a week later. The operator console rebuilds the engagement live from the artifacts the agents write: severity counters that tick as findings land, an agent board filling in wave by wave, and an activity log carrying the validator's reasoning as it decides. Every counter is a door — click a severity for the findings behind it, click killed for the rejections and their reasons, click runs for every previous assessment of the same target.

Operations

livemission controlrunstool activityefforthosts

Inventory

assetsknowledge graphtechnologiesapi surfaceauth surface

Findings

findingschains

Assurance

coverageendpoint coveragevalidators

What you get

A run ends with four things.

Not a transcript, and not a wall of scanner output for someone else to sort out.

Validated findings

Reproduced, severity-calibrated, de-duplicated across the estate. Each carries its evidence, impact, reproduction steps, remediation, and the observation that convinced the validator it was real.

A coverage statement

What was assessed, how deeply, and what wasn't. The part that turns "we found three criticals" into something an auditor or a board can actually interpret.

An operator worklist

The high-risk steps, staged rather than fired — each with its precondition, what it would prove, and the exact command to run in your change window.

The deliverable

A severity-coloured report built from the validated corpus, with external references only — CVE, CWE, KEV, vendor advisory — and no internal tooling vocabulary carried into a client-facing document.

Before you authorize a run

The questions evaluators actually ask.

Including the two we answer in writing rather than on a marketing page.

What can Vantage test?

Ten specialist agents cover web applications, APIs, networks, Active Directory, cloud environments, SAP and ERP systems, mobile applications, LLM and AI applications, source and supply-chain risk, and dark-web or leaked-secret exposure. Testing is limited to the estate your authorization covers.

How do you prove a finding is real?

A separate adversarial validator has to reproduce the exploit and independently read back its effect. A scanner alert, a successful request, or a claimed impact is not enough on its own. If the validator cannot establish both the exploit and its effect, the candidate does not survive.

What happens to candidates that fail validation?

They are downgraded or killed, and the observation that decided it is kept. You can read the rejections, not just the acceptances. Failed candidates never inflate the finding count.

How do you avoid causing an outage or locking out our users?

Anything that could is staged rather than fired. Credential spray, NTLM relay and DCSync are examples: each arrives with its precondition, what it would prove, and the exact command, and a human runs it under your change control. Nothing in the worklist executes itself.

How is scope enforced?

An engagement needs written authorization, an explicit scope with exclusions, and an open testing window. Exclusions beat any broader wildcard. Scope resolution fails closed — if it cannot resolve, the authorized host count is zero and nothing runs.

What do we actually receive?

A consolidated set of validated findings, a per-asset coverage statement, an operator worklist for the human-only steps, and a severity-coloured report. Repeated runs feed one de-duplicated corpus rather than a new pile each time.

Where does the scanner run, and how is our data handled?

Offensive tools run in a contained scanner. The hosting model, processing location, tenant isolation, encryption, evidence retention and deletion, administrative access and any subprocessors are answered in writing during scoping — you should have the actual architecture in front of you before granting access, not a badge on a web page.

What does it cost, and how long does it take?

Both are quoted in writing against the authorized scope. An assessment's size depends on your estate, so a list price here would be a guess dressed up as a number.

Getting started

Scoping comes before scanning.

Nothing runs until three things exist. They are short documents, not a procurement cycle — and the assessment is bounded by them, not by what the fleet is capable of.

Written authorization From whoever owns the assets, naming who is permitted to test them.
A scope, with exclusions Domains, ranges and accounts that are in — and the ones that are explicitly out. Exclusions beat any broader wildcard, and scope resolution fails closed.
A testing window When active testing may run, plus a contact and an escalation path for the duration.

Bring those and the fleet handles the rest — then tells you plainly where it did not reach.

Read the FAQ first How a finding is proved