On-Premise & Air-Gapped Pentest Platforms: A Buyer's Guide

Most buyers compare pentest platforms on what they find. For regulated organizations the first filter is often somewhere else: where the platform's control plane and AI run, and therefore where the findings, credentials and evidence go. That choice decides three things a risk committee cares about:

• Who is a third party

  A vendor cloud that receives your findings is a service provider that processes your security data, with its own locations, subcontractors and staff.

• What has to be assessed and contracted

  Every such provider adds due diligence, contract clauses, monitoring and an exit plan.

• What happens if the vendor stops

  If testing depends on a vendor cloud, a suspension, outage or insolvency stops your testing too.

None of the rules below bans a cloud-hosted pentest platform, and many organizations run one after doing that work. This guide makes the work visible before the purchase, and shows what an on-premise or air-gapped option has to deliver to remove it.

• Defense, armed forces and the defense industrial base

  Classified and controlled information, networks that are air-gapped by rule, and for US defense suppliers the CMMC scoping rules on where CUI and security data may go. See defense and air-gapped networks and US defense industrial base (CMMC).

• Public administration and government

  National-security and data-classification rules, such as Italy's national cybersecurity perimeter, and the principle that the tools defending the state stay under its control.

• Banks, insurers and market infrastructure

  ICT third-party risk, concentration risk and exit strategies under DORA in the EU, and outsourcing or data-residency rules from national supervisors elsewhere.

• Healthcare and life sciences

  Special categories of personal data under GDPR Art. 9, HIPAA business-associate obligations in the US, and hospitals classed as essential entities under NIS2.

• Operators of OT and industrial networks

  Plant, energy and utility networks that are deliberately isolated, where a tool that needs a standing internet connection cannot be installed at all.

The common thread is not size but the sensitivity of the security data and the isolation of the network. The full list, with the regulatory driver for each sector, is on the on-premise AI red team page.

Three rules turn the place where a pentest platform runs into a compliance question. None of them bans the cloud; each one adds work when your findings leave the building.

• DORA (EU financial entities)

  The contract must state where data is processed and stored (Art. 30(2)(b)), and services supporting critical or important functions need a tested exit strategy (Art. 28(8)).

• NIS2 (essential and important entities)

  Supply-chain security is a mandatory measure (Art. 21(2)(d)), and each supplier's own vulnerabilities and security practices must be taken into account (Art. 21(3)).

• CMMC (US defense contractors)

  A cloud service that receives your findings or test credentials processes Security Protection Data, which makes it an External Service Provider in your assessment scope (32 CFR 170.4).

Vendors use on-premise for very different architectures: a local sensor driven from a cloud console, a local engine calling a cloud AI model, or a self-contained appliance. Define the term in the contract, item by item:

• No telemetry by default

  List every outbound connection the product makes in normal operation, its destination and its payload. Anything beyond that list should be opt-in and documented.

• Local AI models

  State where inference runs. If any prompt, finding or credential can reach an external model endpoint, that provider is a third party and belongs in your assessment. See private AI in cybersecurity.

• Offline licensing

  The platform should keep running if it cannot reach the vendor, with the license term checked locally, so a vendor outage, dispute or insolvency does not switch off your testing.

• A controlled update process

  Updates signed by the vendor, verifiable before installation, applicable offline where the network is isolated, and installed when you decide.

• Local evidence storage

  Findings, evidence and credentials stored on your hardware, with integrity you can verify without the vendor and export formats you can keep after the contract ends.

• Data deletion

  How data is wiped when the contract ends or hardware goes back for repair or replacement, and what proof of destruction is provided.

• Remote support

  Whether the vendor ever needs remote access, who approves it, and how it is logged.

• Air-gapped behavior

  Which features depend on the internet and are lost when the platform is fully isolated, so the test scope is planned around them.

Deployment options differ more than category labels suggest. From the documentation we reviewed for our comparison pages:

• Horizon3.ai NodeZero

  Runs from a customer-hosted host but is orchestrated from Horizon3's cloud, which that host needs continuous outbound access to during a test. An EU-hosted portal is available; no air-gapped edition is documented.

• Pentera

  Pentera Core installs on your own infrastructure, while Pentera Surface is hosted on AWS and its generative-AI features call a cloud LLM service. No fully air-gapped operation is documented.

• Cymulate

  SaaS-only: lightweight test points run on your network, while the platform and its AI run in Cymulate's cloud.

• XM Cyber

  SaaS by default, with EU hosting options and BSI C5. We found no documented fully on-premise or air-gapped edition.

• XBOW

  Delivered as SaaS on third-party frontier models; targets internet-facing web apps and APIs.

• Picus Security

  A breach and attack simulation (BAS) vendor, SaaS-first, but it does document on-premise and air-gapped deployment.

Two fair conclusions follow. SaaS platforms bring real advantages, faster onboarding and no hardware to manage, and for organizations without the constraints above they may be the right choice. And on-premise or air-gapped options are not unique to one vendor: ask every shortlisted vendor the questions below and read the answers in the contract, not the datasheet. Vendor documentation changes, so verify each point with the vendor at the time of purchase. Side-by-side pages are on alternatives.

Send these to every vendor on your shortlist and keep the answers with the contract.

1. 1List every outbound connection the platform makes in normal operation, with destination and payload. Can each one be switched off?
2. 2Where do the AI models run? Can any prompt, finding or credential reach an external inference endpoint, and who owns the models?
3. 3Does the platform run fully with no internet connection? Which features are lost in air-gapped mode?
4. 4Is there any telemetry, including usage, crash or update-status reporting? Is it off by default, and what does the payload contain?
5. 5How is the license enforced? Does the platform keep working if it cannot reach the vendor, and what happens at the end of the term?
6. 6How are updates delivered, signed and verified, and can they be applied offline at a time you choose?
7. 7What do updates contain, and do you see release notes before installing?
8. 8Where are findings, evidence and test credentials stored, and can you verify their integrity without the vendor?
9. 9In which formats can evidence and reports be exported so they remain usable after the contract ends?
10. 10How is data deleted at contract end or when hardware is returned, and what proof of destruction is provided?
11. 11Does support ever require remote access? Who approves it, and how is it limited and logged?
12. 12Which subcontractors, hosting providers or AI providers touch your data, and in which countries (DORA Art. 29(2) and 30(2)(b))?
13. 13Is a software bill of materials available for the platform, and how are vulnerabilities in the platform itself handled and disclosed?
14. 14What independent assurance covers the vendor and the product: certifications and their status, and third-party penetration tests of the platform?
15. 15How does the platform stay inside the authorized scope, who approves risky actions, and how is it stopped? The OWASP APTS guide for buyers turns this question into a structured evaluation.

Under DORA the answers feed the register of information and the exit plan; under NIS2 the supplier assessment; under CMMC the asset inventory and the system security plan.

Zero Hunt is an autonomous AI red team for networks and infrastructure delivered as an appliance, a desktop unit for smaller sites or a 2U rack for enterprises and data centers. What the site states about its deployment:

• Outbound connections and telemetry: the full stack, including the AI models, the evidence store and the console, runs on the appliance, and no customer data leaves it. When connected, the appliance reaches out only to fetch signed product updates, public threat intelligence and, for gray-box analysis, the published source of the software version under test, which can be switched off or pointed at your own source mirror. Update-status reporting (release ID, status, timestamp) is opt-in.
• AI models: its own ZeroHunt Apex models run on the appliance GPU, with no external AI API.
• Air-gapped mode: nothing goes out; updates arrive as signed offline bundles and threat intelligence as offline imports. Public-OSINT reconnaissance and downloading published source are switched off there, so those assessments run black-box, unless the appliance can reach your own source mirrors.
• Licensing: with an offline license the appliance checks its term locally and does not need to reach Zero Hunt to keep running.
• Evidence: each attack attempt is recorded in a signed, hash-chained evidence record kept on the appliance, and exported reports are signed.
• Assurance: the Trust Center states the current status openly: the appliance image is pentested annually by an independent firm, ISO/IEC 27001 is in progress and SOC 2 Type II is planned. See the Trust Center.

Two honest caveats. On-premise does not take Zero Hunt out of a DORA register: a vendor that ships updates provides an ICT service under Article 3(21), so it still needs to be recorded and assessed, but the data location is your own site. And items such as data deletion at contract end or hardware return are matters for the contract; ask for them in writing, as you would from any vendor. To check the fit with your environment, request a demo.