Why Verglos will not ship an attacking agent

Autonomous offensive security is a legitimate category when targets are authorized, scope is governed, and operators understand the possible effects. It is not the category Verglos is designed to enter.

The product commitment is specific: Verglos will not autonomously select external targets or conduct open-ended attacks. Its working surface is a local source scanner. The proposed next surface is bounded verification of eligible findings against code the user controls.

Why the boundary matters

An attacking agent needs materially greater authority: network access, target scope, credentials or test identities, runtime state, and permission to send behavior-changing inputs. Mistakes can affect systems beyond a repository checkout.

A local verifier still carries risk because project code can execute subprocesses, consume resources, or attempt network access. But its design can start from stronger constraints: explicit invocation, a checked-out project, denied outbound access, controlled fixtures, and a narrow proof question.

Evidence is not the absence of an exploit

A successful authorized proof can demonstrate that one issue reproduced under stated conditions. A failed attempt cannot demonstrate safety. Environment differences, fixtures, timeouts, and incomplete paths all limit the conclusion.

That is why a future Verglos artifact would need to record inputs, project state, tool version, verdict, and limitations. It should not produce a universal “secure” badge.

Current product truth

verglos hunt and verglos attest are unavailable shells in 2.0.0-alpha.1. There is no shipped sandbox verifier, attacking agent, signing service, or public verification URL. The repository and npm package remain the sources for that status.

This boundary leaves room for teams to use authorized offensive tools when they need them. It simply keeps Verglos focused on local code review and, if the design can be implemented safely, portable evidence for a review or handoff.