How it works
Creative judgment, bounded by hard verification
The interesting decisions in penetration testing — what to attack, what to chain together, whether a result is real — need judgment, and that is what a language model is good at. Whether an exploit actually worked is not a judgment call. So we split the two and let each do its own job.
The split
A stochastic brain on a deterministic harness
It is how a human red team already works: creative exploration, then rigorous confirmation.
The reasoning layer
A model-agnostic LLM generates hypotheses, chains exploits together, and triages what is real against what only looks real. It runs on whichever frontier or open model you are comfortable with. This is where variance is expected — and where it adds value.
The verification harness
Everything the model decides to do runs through fixed tooling that records what happened. The model proposes; the harness executes and observes. A claim that cannot be demonstrated does not become a finding.
The sandbox
A pentester's toolkit in a disposable box
Every scan spins up its own isolated container, preloaded with the same offensive stack a human tester reaches for. It is destroyed when the scan ends.
Intercepting proxy
Every request and response, replayable and modifiable.
Scripted browser
Multi-tab, real DOM — for flows a CLI cannot reach.
Persistent shells
State survives between steps, like a real terminal.
Python runtime
Where exploit code gets written and fired.
Recon & scanning
Port, service, and content discovery across the surface.
Static & taint analysis
Source-level reasoning in white-box engagements.
In white-box engagements your source is copied into the container. Your filesystem is never mounted, the container has no route back to it, and the whole thing is torn down when the engagement ends.
The pipeline
Four stages, and one of them exists to say no
Each finding is worked by a chain of specialist agents rather than a single generalist. The chain is what makes the discard step possible.
- 01
Discovery
A specialist agent per vulnerability class per component. It maps the surface and forms a hypothesis about what might be exploitable.
- 02
Validation
A separate agent tries to actually exploit it. Failing here is a normal, expected outcome — that is the whole point of the stage.
- 03
Reporting
Only a reporting agent can file a finding, and the filing is rejected outright if it arrives without working exploit code.
- 04
Fixing
White-box only. Produces a patch against the responsible lines, tests it, and includes the diff in the report.
Trust
Why a finding from us is worth reading
Three mechanisms. Two are enforced by the tooling regardless of what the model says. The third is a judging pass, and it is worth knowing which is which.
No exploit, no finding
A report submitted without executable proof-of-concept code is rejected by the tooling before a human ever sees it. On web targets this is what removes false positives.
Severity is computed
CVSS 3.1 base metrics are submitted individually, validated against the allowed values, and scored by a scoring library. The number is calculated — never a model guessing at “high.”
Duplicates get merged
Every candidate is compared against what is already filed, on root cause rather than on symptoms: would the same patch fix both? If so, you get one finding instead of nine.
This one is a judging pass, not a rule — a model makes the call. We would rather say so than let you find out on a technical call.
Deliverables
One interactive report, and nothing else
No artifact bundle, no CSV dump, no copy of your code parked in a platform. The testing environment is destroyed when the engagement ends and the report is the only thing that leaves it.
- Findings you can open up
- Ordered by severity, each with its CWE, its computed CVSS 3.1 score, the affected endpoint or function, and the evidence behind it — what was sent, what came back, and what that proves.
- The reproduction script, inline
- Copyable straight out of the report. Its second job is the useful one: re-run it after your fix and watch it fail.
- The proposed fix
- In white-box engagements, a diff against the responsible lines, formatted so a reviewer can apply it from a pull request.
- A summary anyone can act on
- An executive summary for the people deciding what to fund, and a methodology section an auditor will accept.
Native binary co-analysis
Where most AI pentesters stop
For endpoint software, what a customer runs is a compiled binary. Compilers inline functions, eliminate dead code, and optimise across translation units — so the source you review and the machine code you ship are not the same artifact.
Three inputs, one view
We correlate the shipped binary, its debug symbols, and the source tree into a single white-box picture, driven by Ghidra — the NSA's reverse-engineering suite — alongside symbolic execution and source-level taint analysis. Findings are cross-checked in both directions: what the source says should exist, and what the disassembly shows actually shipped.
The pipeline is deterministic and fixed: inventory the dangerous API calls, map who reaches them, trace taint backwards from each one, then annotate each candidate with a reachability tier — resolving every unknown downward. It does not filter on reachability, because it cannot prove it.
What this is not
- Not runtime-proven. Native findings are static — recovered from decompilation and pinned to the exact function, but not executed the way a web exploit is.
- Symbol-dependent. Debug symbols make this fast and reliable. On stripped or obfuscated binaries the decompiler and data-flow analysis still run, but name-based detection degrades — the same way it does for a human reverse engineer.
- A candidate generator. It surfaces high-signal leads with evidence attached. It does not claim to have proved reachability.
In your pipeline
It can gate a merge
On the continuous plan, scans run headless and exit non-zero when they find something, so your CI can fail the build. Scope can be limited to the diff on a pull request, so a change gets tested as it merges rather than six months later.
Bring us something hard
Nominate a target — an application, a repository, or a binary you ship. The first scan costs nothing, and we walk you through whatever comes back.