If the surface you need tested is an internal network or an identity estate, NodeZero is the kind of tool built for it and Arxiis is not. Horizon3 publicly positions NodeZero as autonomous pentesting with an emphasis on internal infrastructure, and it publishes proof pages for its findings. Arxiis is measured on web applications and APIs. The useful comparison is not which is better; it is which surface you are actually worried about.
Two surfaces
Internal network and identity. Hosts, services, credentials, directory misconfigurations, the paths between them. This is where NodeZero's public material concentrates, and where Arxiis makes no measured claim at all. Our Claims Register does not include lateral movement or credential compromise, and we do not report either.
Web applications and APIs. Injection, template handling, server-side request forgery, XML external entities, token handling, file inclusion, and the rest of the executor list. This is where Arxiis is measured. On XBOW-104, run dated 19 October 2026: 56% raw and 44% confirmed cross-level; ~82% on level-1 common web bugs, level-1 tier only; 0–42% on hard chained and blind attacks, a known weak spot; 0% measured false positives from an evidence audit.
A team with both surfaces may well end up with both kinds of tool. A team searching for NodeZero alternatives because NodeZero does not cover their web applications the way they need is the team this post is for.
The axes that transfer across surfaces
Whichever surface you are testing, four properties decide whether you can act on the output.
Proof per finding. Horizon3 publishes proof pages, and you should read them for the surface they cover. For Arxiis the proof is a record in a tamper-evident, hash-chained execution ledger, and a finding is labelled proven only when its evidence binds to that record. Anything else is needs review. Ask any platform to show the artefact behind one finding.
Confirmed versus raw. Arxiis publishes both numbers and the gap between them. Ask each alternative for its equivalent.
Measured false positives. Ours is 0%, from an evidence audit of confirmed XBOW-104 solves. Ask for the number and the method.
Scope and escalation control. Arxiis will not engage a non-local target without a written SCOPE + ROE file. A scope guard checks every outbound request. A human operator approves each escalation from the console, and the system cannot approve its own next step. Ask each alternative which of these are enforced outside the model.
Where NodeZero fits better
Internal network and identity testing. That is the surface Horizon3 describes publicly, and Arxiis does not test it. A buyer whose risk lives in the directory and the internal segments should not be evaluating Arxiis for that job.
Where Arxiis fits better
A defined web-application or API scope, a team that acts on the report rather than re-testing it, and a requirement that the tool stops at the scope boundary and waits for a human before escalating. Arxiis also deploys with a live operator console, a headless CLI and an API, is model-agnostic with the flagship validated on Claude Sonnet, and is human-supervised by design.
The honest shortlist for NodeZero alternatives depends entirely on what you typed into the search box before "alternatives". If it was "internal network", keep looking in that category. If it was "web app proof", you have found the right page.
Mapping your attack surface before you shop
Before comparing tools, list what you actually need tested. A short inventory is enough.
- Internet-facing web applications and APIs. How many, how often they release, and who owns each.
- Internal applications. Reachable only from the corporate network or a VPN.
- Identity and directory services. Where credentials live and how they are managed.
- Internal network segments and hosts. Servers, workstations and the paths between them.
- Third-party and partner systems. Which you may test and which you may not.
Then mark which items are tested well today and which are not. The gaps tell you which category of tool to evaluate first.
Matching tools to the surface
| Surface | Look for |
|---|---|
| Web applications and APIs | A tool measured on web classes, with evidence per finding |
| Identity and directory | A tool built and published for that surface |
| Internal network | A tool built and published for that surface |
| Third-party systems | Usually none. Not yours to test without permission |
No single tool covers every row. Be wary of any vendor that claims to, and ask for per-class results.
Questions to ask about proof
Proof pages and evidence trails differ between vendors. When you read them, ask what exactly is being proven.
Is it that a request was sent and a response observed? That a condition was reproducible? That a particular outcome followed? Each is a different claim, and a vendor should be able to say which one their evidence supports.
For Arxiis, the claim is narrow and specific: a stored request produced a stored response containing the cited evidence. We do not claim downstream effects such as lateral movement or credential compromise, because we have not measured them.
A pilot for a mixed estate
If your estate includes both web applications and internal infrastructure, you can pilot in two tracks. Run a web application platform against one staging application. Run an internal-surface platform against one isolated network segment. Use the same written authorization format for both, and compare the same four measures: findings your engineers agreed with, honestly labelled unconfirmed findings, time spent on triage, and whether the tool stayed in scope.
Staying fair to other vendors
We describe other vendors only as they position themselves publicly, and we make no performance comparisons. Their products change, so confirm current details with the vendor before you decide.
What to ask about coverage claims
Coverage claims in this market often blur categories. When a vendor says its tool covers "applications, infrastructure and identity," ask three follow-ups.
Per surface, what was measured? A single headline figure across all surfaces hides where the tool is strong and where it is not. Ask for results broken down by surface and class.
Per surface, what artefact backs a result? Evidence for a web finding looks different from evidence for an infrastructure finding. Ask to see an example of each.
Per surface, what does the tool refuse to do? A tool that has been designed carefully will have limits on each surface. A vendor who cannot name any has not looked.
What to bring to a vendor conversation
Arrive with a short brief so the conversation stays on your needs, not the product tour.
Bring your inventory of surfaces, with the ones you most want tested marked. Bring your scope file template. Bring the four measures you plan to use in a pilot. And bring your own list of "what stops it from leaving scope" questions.
A vendor who engages with the brief is easier to evaluate than one who steers back to the demo.
Total cost thinking
Licence cost is one input. Effort is the other, and it is easier to underestimate.
For any tool, think about who will operate it, how much of their week it takes, who will triage the output, and how much retesting happens afterwards. Use your own figures. Two tools with similar licence costs can differ widely in the effort they demand from your team, and evidence per finding is one of the biggest drivers of that difference.
Security of the tool itself
Any tool that runs against your systems deserves its own security review. Ask where it runs, what data it stores, who can access stored evidence, how credentials you supply are handled, and what logs it keeps.
For Arxiis, evidence is stored in the engagement ledger, which is isolated per engagement, and the client receives it at close. Ask every vendor for the equivalent description.
Recording what you learn
Keep a short log of what each vendor said and what the pilot showed. Next year, when the contract comes up for renewal or a new vendor appears, the log is the fastest way to restart the evaluation without starting from zero.
Frequently asked questions
Does Arxiis test internal networks like NodeZero?
No. Arxiis is measured on web applications and APIs. It makes no measured claims about internal network, identity, lateral movement or credential compromise.
What vulnerability classes does Arxiis cover?
Web-application classes including SQLi, SSTI, SSRF, XXE, JWT and LFI, and others per the executor list. Results on XBOW-104 are 56% raw and 44% confirmed cross-level, with 0% measured false positives.
How do I decide between internal network testing and web application testing tools?
List the surfaces you need tested, mark which are tested well today, and let the gaps guide the category. No single tool covers every surface, so ask for per-class results and be wary of claims of full coverage.
What does Arxiis's evidence actually prove?
That a stored request produced a stored response containing the cited evidence. Arxiis makes no claims about downstream effects such as lateral movement or credential compromise, because they have not been measured.
See it on your own stack.
Arxiis runs a coordinated crew of specialist agents through a full engagement in hours, not weeks. Every finding is CVSS-scored, MITRE ATT&CK-tagged and auto-mapped to RBI CSF, CERT-In and nine more frameworks — and every command lands in a tamper-evident ledger. It runs entirely on your own infrastructure.
