01
Internal application testing
Reach authorized RFC1918, loopback, link-local, and internal-DNS targets from inside the customer network while cloud workers retain SSRF protections.
Private execution
Run security assessments where your code and internal targets already live.
Private runners execute eligible source and live-target scans from Docker hosts inside networks you control. Evaluate the full workflow during the 30-day commercial trial, keep cloud and private execution explicit per project, and choose how much result detail returns to ZeroQuarry.
Customer-controlled Docker hostsOutbound HTTPS onlyMinimized or standard results
execution://private-poolprocessing
customer network
git · private
app.service.internal
runner
outbound results only · evidence stays local
ZEROQUARRY
assessment runs inside your boundary · no automatic cloud fallback
Capabilities
What runs inside your network
The runner stays connected to ZeroQuarry and to the model provider you choose, so you can describe exactly what runs where instead of claiming it is fully on-premise when it is not.
02
Private Git source execution
Clone Git repositories directly on the runner with scoped credentials. Browser source uploads and binary uploads do not use private execution.
03
Outbound-only enrollment
Enroll a runner with a one-use, 24-hour token and make outbound HTTPS connections without opening an inbound firewall rule.
04
Per-project execution policy
Allow specific pools on a project, choose a default, and let scan creators select only compatible environments.
05
Result minimization
Return allowlisted finding metadata and safe locations while evidence, remediation text, logs, errors, and artifacts remain on the runner.
06
Operational controls
Separate trust zones into pools, monitor health and leases, drain for maintenance, revoke immediately, and retain an account audit trail.
How it runs
Design, enroll, authorize, operate
How a customer-controlled runner is set up, and exactly what it is allowed to reach.
Design
Choose which networks it may reach, which scan types are allowed, how much detail is returned, and which models it uses.
Enroll
Run the generated Docker command on a host that can reach your targets, your Git host, your model provider, and ZeroQuarry.
Authorize
Allow the pool on selected projects and choose whether ZeroQuarry Cloud remains an approved alternative.
Operate
Assign scans explicitly, monitor runner health, and review result and audit behavior without automatic cloud fallback.
Outcomes
Internal coverage, on your terms
It reaches internal systems a hosted scanner cannot, and you decide how much detail leaves your network.
Coverage of internal systems
Assess private applications and APIs that a managed service cannot safely reach.
Less detail leaves your network
Keep detailed evidence local when a summary is enough for triage and reporting.
Explicit deployment control
Give security and infrastructure teams something reviewable: which networks it can reach, which providers it calls, and how to revoke it.
Evaluation FAQ
Questions about private runners
Air-gapping, model keys, fallback behaviour, and how to evaluate before you commit.
Is a private runner fully on-premise or air-gapped?
No. It executes scans on a customer-controlled Docker host but makes outbound HTTPS calls to ZeroQuarry and directly to the model provider you selected.
Which scans can use private runners?
Private pools support Git-backed source scans and authorized remote targets. Source file uploads, archives uploaded through the browser, and binary uploads are not private-runner inputs.
Can a failed private job fall back to ZeroQuarry Cloud?
No. A failed or expired attempt is retried in the same private pool. Cloud execution occurs only when a scan creator explicitly selects an allowed cloud environment.
Do private runners require bring-your-own model keys?
Yes. Every selected scan, review, and artifact model needs an account-managed provider key so the runner can call that provider directly.
Can we evaluate private runners before buying Enterprise?
Yes. The 30-day commercial trial includes self-serve private runner pools. Create a pool, run the generated Docker command, and evaluate a Git-backed source scan or authorized internal target before discussing Enterprise rollout terms.
Related workflows
Internal targets
Run it on your own infrastructure first
Set up a private runner, then test it against one internal target during the trial.