AI-authorship provenance, explained

Code is not insecure because an AI helped write it. Authorship does not turn a harmless line into a vulnerability, and a detector should never raise severity merely because generation is probable.

Provenance can still help a reviewer answer a different question: where did rapid or mixed-authoring workflows create review gaps?

The correct hierarchy

A security finding should begin with an observable pattern: a missing authorization check, dangerous sink, exposed credential, unsafe package reference, or another reviewable condition. Repository context and authorship estimation come afterward.

Useful provenance is:

• probabilistic rather than absolute;
• attached to file and change context;
• separable from the underlying finding;
• visible to the reviewer;
• absent from decisions where it adds no value.

Where it can help

Teams can use provenance context to inspect review coverage, compare defect clusters across workflows, or prioritize unfamiliar generated sections for human attention. It can also help an agency explain which parts of a delivered system were generated, edited, and independently reviewed.

Where it becomes harmful

It becomes harmful when it is used as employee surveillance, a quality score, proof of policy violation, or a shortcut around validating the code. False certainty is especially dangerous because mixed authorship is normal: a human prompts, an agent drafts, a formatter rewrites, and a maintainer edits.

Verglos treats provenance as supporting context in its scanner output. The product claim is limited to that role. The finding still has to be defensible without the authorship estimate.