AI Code Provenance: The Accountability Gap Nobody Has Closed

As AI generates and modifies code, teams need provenance. Embedding AI-generated metadata in git commits makes automated edits auditable, reviewable, and manageable.

Ash Minhas

15 Apr 2026 — 8 min read

Photo by Kaleidico / Unsplash

Opening a repository that contains AI-generated code can feel like opening a book with no footnotes: the code is there, but the origin story is missing. The problem is no longer theoretical. Claude Code alone now appears in more than four percent of public commits on GitHub [10]. By some estimates, AI tools assisted in generating 41 percent of new code merged globally in 2025 [4]. Yet most of that code carries no structured record of what produced it, which model was involved, or whether a human reviewed the output before it shipped.

The result is a growing accountability gap — and the tools being built to close it are still early, fragmented, and competing with each other.

The scale of the problem

AI-assisted coding crossed a threshold in 2025. Across Fortune 50 enterprises, AI-generated code showed up with 2.5 times more high-severity vulnerabilities (CVSS 7.0+) than human-written code [17]. Veracode tested over 100 LLMs and found that 45 percent of AI-generated code samples failed security tests, introducing OWASP Top 10 vulnerabilities [11]. Georgia Tech's Vibe Security Radar, launched in May 2025 to track CVEs directly attributable to AI coding tools, logged 74 confirmed vulnerabilities out of 43,849 advisories analyzed by March 2026 [9] — a number the researchers themselves say reflects detection blind spots, not superior AI safety [10]. As the project's founder put it: everyone was saying AI code is insecure, but nobody was actually tracking it [9].

Meanwhile, GitGuardian's 2026 State of Secrets Sprawl report found that Claude Code co-authored commits leaked secrets at roughly double the baseline rate at 3.2 percent versus 1.5 percent across all public GitHub commits [13]. In 2025, 28.65 million new hardcoded secrets were detected in public commits, a 34 percent year-over-year increase, with eight of the ten fastest-growing categories of leaked secrets tied to AI services or AI infrastructure [13].

These numbers share a common root cause: when you cannot reliably identify which code came from a model, you cannot reliably audit it, trace its vulnerabilities, or govern its use. The traditional git trace, author, committer, message all become blunt instruments. A terse commit message like "auto-refactor" tells you nothing about which parts of a change came from a model, which prompt produced it, or what safety checks were applied.

What provenance metadata looks like — in theory

At its simplest, AI-generated metadata is structured information embedded alongside a commit: the model version or provider, a prompt hash or conversation reference, line-level attribution of what the AI wrote versus what the human wrote, and flags for human review or automated tests. That metadata can live in several places: the commit message, a signed footer, a dedicated file in the repo, or git notes that attach metadata without changing the commit history.

Each approach has trade-offs. Commit messages are visible and searchable but easy to overwrite during rebases. Repo files create clutter but are versioned. Git notes are elegant and survive history rewrites but are less familiar to most teams. The right answer depends on your workflow, and nobody has converged on a single approach yet.

Beyond placement, the metadata needs a schema — consistent, machine-readable fields that turn ad hoc annotations into queryable audit trails. That much is obvious. What is less obvious is how far the industry is from having one.

Two specs, no standard

Two specifications are currently competing to define how AI code provenance works, and they are not interoperable.

Agent Trace was announced in January 2026 by Cognition AI (the company behind the AI software engineer Devin) and released as an RFC by Cursor [7]. It has backing from Cloudflare, Vercel, Google Jules, Amp, OpenCode, and git-ai [7]. Agent Trace uses a JSON-based "trace record" that connects code ranges to conversations and contributors [5]. It tracks attribution at file and line granularity, classifying contributions as human, AI, mixed, or unknown [6]. The spec is intentionally storage-agnostic — it does not prescribe whether traces live as files, git notes, or database entries [5]. It is currently at version 0.1.0 and explicitly leaves questions about merges, rebases, and large-scale agent-driven changes unresolved [6].

Git AI is an open-source git extension that takes a different approach. Rather than a vendor-neutral data spec, it is a full implementation: a CLI tool that hooks into coding agents (Cursor, Claude Code, Copilot, Codex) and automatically records which lines each agent wrote, using Git Notes to store authorship logs [8]. Its standard, now at v3.0.0, uses an attestation format with session hashes and line ranges, linked to transcripts stored locally or in a cloud-hosted prompt store [8]. Git AI's philosophy is that "detecting" AI code is an anti-pattern — supported agents report exactly which lines they authored, giving precise attribution rather than heuristic guessing [8].

The two approaches differ in fundamental ways. Agent Trace is a data specification — it defines a format, not a tool [5]. Git AI is a tool that defines its own format [8]. Agent Trace's required fields are version, id, timestamp, and files; model information and confidence scores are optional vendor-extensible metadata [5]. Git AI's standard requires attestation sections mapping files to session hashes with specific line ranges, plus a metadata section linking those hashes to prompt records [8]. A team adopting one cannot read the other's output without translation.

This fragmentation is the central obstacle to the provenance story. The industry cannot query across repositories for AI-origin changes if every repository uses a different schema or, more commonly, no schema at all.

The attribution gap in practice

Even without formal specs, teams are already trying to track AI contributions through simpler mechanisms. Research on 14,300 commits across 7,393 GitHub repositories between 2023 and 2025 identified two dominant patterns [1]. The first treats the AI as an author: commits carry AI identity through dedicated email addresses (like cursoragent@cursor.com), co-author trailers, or attribution footers [1]. Teams filter commits by matching against these patterns [2]. The second treats the AI as a tool: the human remains the committer but flags AI involvement with trailers like Assisted-by: or Generated-by: and Co-Authored-By [4].

But a significant share of AI-generated code goes entirely unlabeled. The same research found that developers often default to vague or absent attribution, partly because existing attribution norms were built for human collaboration and offer limited guidance in this new context, and partly because of fear of negative peer reactions to AI-generated code [1]. A separate study analyzing 33,580 pull requests found that AI coding agents leave detectable behavioral fingerprints even when submitted through human accounts [3] — which means the boundary between "author" and "tool" is blurrier than either pattern assumes.

A large-scale study of 6,275 repositories with 304,362 verified AI-authored commits across five major coding assistants found that reliable attribution still depends on explicit traces in git metadata [2]. Projects or tools that use AI without leaving such traces are invisible to any analysis [2]. The researchers noted that GitHub changed its Events API in October 2025 to remove commit-level summaries from PushEvent payloads, making post-hoc attribution even harder [2].

Design choices and their risks

Choosing how to record AI edits is an exercise in balancing transparency, security, and workflow friction. A permissive strategy that attaches raw prompts to commits maximizes interpretability but risks leaking things such as secrets, API keys, proprietary logic, internal system descriptions into version history. This is not hypothetical: AI-assisted commits already leak secrets at elevated rates [13]. A conservative approach that logs only a prompt hash and model fingerprint protects secrets but reduces the immediate usefulness of the metadata for debugging and review.

Equally important is the interaction model between the AI and the human. When a model proposes changes that a developer reviews and commits, the metadata requirement is relatively light: a trailer noting the model and a human approval flag. When an autonomous agent applies changes after tests pass and commits directly, the governance bar is higher. Automated commits need stronger attestations like cryptographic signing, CI evidence, and immutable logs to establish that the change was authorized and tested.

Cryptographic signing of commits is well-established in Git (GPG and SSH signatures have been supported for years). Governance frameworks are pushing further: sealed policy artifacts, signed enforcement receipts, and tamper-evident evidence chains are being developed for autonomous AI agent systems [15]. Microsoft's open-source Agent Governance Toolkit, for example, adds deterministic policy enforcement and cryptographic verification to agent actions with sub-millisecond overhead [14]. But applying this level of infrastructure to routine developer commit workflows where the AI is an assistant, not an autonomous agent remains mostly aspirational. The gap between "sign your commits" and "maintain a cryptographic chain of custody for every AI-generated patch" is substantial.

What teams can do now

Adoption of any provenance scheme will hinge on minimal friction. The practical patterns emerging today are modest but real: commit-footers that follow a compact, parseable format; CI hooks that validate metadata presence before allowing merges; and lightweight review gates that require a human sign-off token when a model performs non-trivial changes. Pre-commit hooks can enrich commits with metadata automatically, and server-side hooks can enforce policies.

A reasonable starting checklist

Pick a metadata approach and commit to it. Whether that is Agent Trace [5], Git AI [8], or a simpler convention like Generated-by: trailers [4], consistency within a codebase matters more than which format you choose.
Decide on storage. Commit footers for visibility, git notes for durability through rebases, or a dedicated metadata folder for ease of querying. Each has trade-offs; none is clearly dominant.
Enforce through CI. Fail merges that are missing required metadata or human sign-off. This is where policy becomes real.
Protect sensitive content. Never attach raw prompts to commits. Store prompt hashes at most. Audit for secret leakage — and assume the leak rate for AI-assisted commits is higher than your baseline [13].
Monitor the specs. Agent Trace and Git AI are both under active development. Whichever gains broader adoption will determine what tooling and integrations emerge. Betting heavily on either at this stage carries risk.

The feedback loop that does not exist yet

The most compelling promise of AI code provenance is the feedback loop: standardized metadata enabling queries that isolate AI-origin changes, measure their frequency, and correlate them with security incidents, code quality metrics, and maintenance costs. That loop would let teams identify which models produce brittle code, which prompts lead to insecure patterns, and which workflows need tighter review gates.

Today, that loop does not exist at any meaningful scale. Large-scale empirical studies still rely on heuristic pattern-matching scanning commit messages and author fields for known AI signatures rather than structured, machine-readable metadata [2]. Even dedicated tracking efforts like the Vibe Security Radar acknowledge that their CVE counts underrepresent the true scope of AI-introduced vulnerabilities because attribution is so unreliable [10]. No agreed standard for correlating AI-origin code changes with incident reports has emerged.

The aspiration is sound. The infrastructure is not there yet.

Where this is heading

The future of collaborative coding will not be anonymous; it will be annotated. But doing that annotation in a way that is compact, machine-readable, privacy-conscious, and enforced by CI requires the industry to converge on a standard, or at least on interoperable standards, which it has not done. Agent Trace at v0.1.0 [5] and Git AI at v3.0.0 [8] represent genuine progress, but they also represent a standards race whose outcome is uncertain.

The teams that start instrumenting their workflows now; even with simple, imperfect conventions will be better positioned when the tooling matures. The teams that wait for a finished standard may be waiting a while. The provenance problem is real, the security data is alarming, and the gap between what the industry needs and what it has is wide. Closing it will require not just better specs, but adoption and in my experience adoption requires the kind of minimal-friction, zero-configuration tooling that does not yet exist at scale.

We are all still learning.