What portion of your code was written by AI? The question is no longer a technical one.
Code assistants on every team, dozens of branches, and a repository that no one knows in its entirety. For technical management, it’s a control issue. For Legal, it’s a matter of authorship and licensing. For the auditor, it’s a matter of evidence.
The repository that no one knows in its entirety
A V-PROOF repository analyzed in September had 163 branches and 446 commits from four authors. This is not an extreme case. It is typical for any team that has been developing for a year.
On that scale, knowing what exists, who changed it, and why depends on the memory of two or three people. And when you add to that the fact that part of the code is generated by an AI assistant, the question of who the author is is no longer just an academic one.
Before the branch, not after
Verifiable AI Code Governance analyzes each change before the pull request is submitted, checking it against the development standards defined by the organization itself—not against generic rules. It checks four things in each analysis:
Credentials in the code.
Key elements and sensitive variables detected with each change.
Licenses and Vulnerabilities.
Permitted or prohibited licenses and published known vulnerabilities.
Measured authorship.
What percentage of the new lines comes from commits co-authored by AI?
Coverage by area.
Test files versus code files in each part of the project.
When a change violates a rule or reveals a secret, it is flagged and recorded as evidence. Controls monitor; they do not hinder the team’s work. Each change is recorded as implemented, partially implemented, or not implemented, with the figures to support it, in the same governance log as the rest of the AI.
Authorship, measured
The " declared AI use " figure is the one that sparks the most discussion. It serves as the starting point for determining who created a software asset and what licenses apply to it.
With one caveat worth emphasizing: it measures what is declared in the commits. Any use of AI not mentioned in the commit is not included. That’s why the policy on declaring co-authorship is just as important as the tool itself.
From Commit to Evidence
A commit can be sealed along with its glossary and history—what code was there, what it did, and who changed it—all fixed at a single point in time with cryptographic proof. It is verified on the public portal and exported for an auditor or a client.
For those who sell software in Europe, this aligns with the requirements of the Cyber Resilience Act: knowing what components a product contains and being able to demonstrate it.
What it doesn't do
Identifying secrets and vulnerabilities is not a penetration test. The checks are self-assessments reviewed by a designated person. And the functional analysis is generated by a model chosen by the organization, using its own account; only summaries and commit messages are shared—never the code.
If you want to see how the project's technical memory works, we explain it in " Your Code Already Has a History."
Every commit is attributed. Every deployment is verifiable.
Ninety seconds. From commit to evidence.
Recorded on the V-PROOF Portal: repository audit, human-to-AI ratio, and sealed commit.
Watch the demo