The security evidence layer for AI-built software

AI-assisted software can be produced faster than a buyer, client, or reviewer can reconstruct how it was checked. That creates an evidence problem before it creates a new scanner category.

A useful handoff should answer: what revision was reviewed, which tool and rules ran, what was in scope, what was found, what was resolved, and what remains uncertain?

A report is necessary, but incomplete

The current Verglos scanner runs locally against JavaScript and TypeScript projects and produces local output. That can preserve findings, locations, rule identifiers, and scan context without requiring source upload.

But a scanner report does not prove that every issue is exploitable, that every route was modeled, or that the deployed system matches the scanned checkout. Evidence should make those limits visible rather than turn a scan score into a certification.

The evidence layers

Project identity: repository or project name, commit identifier, dirty-worktree state, and scan time.

Method: tool version, rule set, configuration, exclusions, and supported languages.

Observation: findings and their severity, location, rationale, and status.

Decision: accepted risk, remediation, false-positive rationale, or deferred work, each attributable to a reviewer.

Integrity: a way to detect whether a shared artifact changed after it was produced.

Current and proposed Verglos surfaces

Today, the defensible surface is the local scanner and its report artifacts. The repository also documents a broader direction for local verification and signed handoff evidence. In 2.0.0-alpha.1, the related hunt and attest commands are shells, not completed workflows.

That distinction matters commercially and technically. A public verification page would need a privacy model, a signing and key-rotation design, stable schemas, deletion controls, and language that does not imply certification. None of those should be inferred from the presence of a CLI command name.

The evidence-layer thesis remains useful even while the product is smaller: keep security records close to the code, make scope and uncertainty legible, and let a reviewer trace every claim to a concrete artifact.