The local sandbox verification concept behind Verglos

A static finding is a reason to investigate, not proof that a system is exploitable. The product concept behind verglos hunt is to narrow that gap with bounded checks against code the user owns.

That workflow is not shipped. In 2.0.0-alpha.1, hunt is a command shell that reports the capability as unavailable. The public repository and npm package are the authority for that boundary.

What the proposed verifier would do

A verifier could select an eligible scanner finding, prepare a minimal test case, run it in an isolated local environment, and attach a result to the original finding. The result would need to include the input, environment assumptions, exit state, and enough output for another reviewer to understand what happened.

The purpose is not to improvise an attack campaign. It is to answer a constrained question about a checked-out project without uploading source or contacting an external target.

The required boundaries

Authorization. The user must invoke the check on code and services they are authorized to test.

Isolation. The verifier should start with no outbound network access and the least filesystem and process authority it needs.

Reproducibility. Inputs, tool version, commit identity, and environment assumptions must be captured. A result without those fields is a demo, not durable evidence.

Refusal. Findings that depend on production data, third-party credentials, live infrastructure, or ambiguous targets should remain unverified.

Asymmetric interpretation. A successful bounded proof can strengthen a finding. A failed attempt only means that one attempt did not reproduce the issue under its stated conditions.

Why keep it local

Local execution reduces the amount of source and project context sent to another service. It also lets a team choose the runtime, fixtures, and dependencies used for a check. Those benefits do not make local execution automatically safe: untrusted project code still needs process, network, resource, and secret isolation.

The design test for hunt is therefore strict. It should not ship merely because the command can run code. It should ship only when the resulting artifact is safer and more reviewable than the uncertainty it introduces.

Why the sandbox is the authority boundary

We considered four shapes for the verification loop: cloud-model triage, local-model triage, deterministic local fixtures, and a hybrid. A model can explain code and propose a test, but a confident explanation is not execution evidence. Sending source and runtime context to a cloud service also changes the privacy and threat model before the team has proved that the extra authority is necessary.

The proposed sequence is deliberately narrow: select an eligible finding, prepare a minimal fixture, run it against the checked-out project in an isolated environment, record the command and observable result, clean up, and package the trace for review. A model may eventually help propose a fixture. It must not rewrite the result after execution or turn an unsuccessful attempt into a safety claim.

This choice has real costs. Sandboxes need language and framework adapters. Results can vary with environment state. Some findings depend on production data, third-party credentials, or live infrastructure and cannot be safely verified locally. The correct result in those cases is not verified, not an invented proof.

The architecture is therefore a product decision, not a feature announcement. In 2.0.0-alpha.1, verglos hunt remains an unavailable command shell. Publishing the boundary now gives the eventual implementation a testable standard: explicit authorization, denied outbound access by default, controlled fixtures, recorded assumptions, and an artifact another reviewer can challenge.