Beyond Detection: Practical Git Provenance for AI-Edited Code

Detection Is a Mirror, Not a Handle

The urge to detect AI-edited code is understandable. It feels like an answer: run a tool, flag suspect diffs, and sort the rest. But it’s a mirror, not a handle. You can see something about the code’s likely origins; you can’t steer your process with it.

In the last year, a wave of projects has emerged to score or flag probable AI contributions in repositories. Some even compute a “slop score” across commits. They make good headlines and decent research baselines. They also tempt policy teams to imagine a one-switch future: turn on detection, block AI-coded changes, and declare governance achieved. That’s a mistake. You won’t get durable, buildable governance by running a classifier over diffs.

The work we actually need is Git provenance—clear, layered evidence about who changed what, with which tools, under which policy, at what time, and how that change turned into running software. That is the handle. It lets teams write rules, automate enforcement, and leave an audit trail that stands up months later when nobody remembers which shell incantation produced which binary.

There’s urgency here. Platforms are tightening identity and provenance. Signed commits aren’t new, but they’re far easier to adopt than they were. Build systems can emit standardized attestations. Package registries and artifact stores can accept them. It’s finally practical to weave real provenance into developer workflows without wrecking ergonomics. The rise of detection tools is the flashing light on the dashboard; the answer is to fix the brakes.

What We Actually Need From Provenance

Before proposing plumbing, it’s worth naming the outcome. “Code provenance for AI” is not code archaeology. It’s not an invitation to surveil every keystroke. It’s a narrow, enforceable account, useful to humans and machines:

• Identity: Who authored and reviewed the change? Were the identities verified? If an agent contributed, which agent identity was used and who approved it?
• Intent: What change was attempted, and how was AI involved? Not the entire prompt transcript—just a reliable declaration from the developer.
• Build chain: How did this commit become a build artifact? Which builder, which inputs, which environment?
• Policy context: Which checks ran? Which ones were required at merge time? What was waived, by whom, and why?
• Linkability: Can you tie the commit to the artifact you’re running, and from there back to the source and the tests that blessed it?

None of this requires guessing whether a code block “looks like” it came from a language model. We ask the humans and systems involved to attest to facts, we bind those attestations cryptographically to the commit and the artifact, and we let policy engines act on them. This is boring in the best way. It’s standards and signatures, not vibes.

The goal is balance. Teams need enough signal to set rules—say, “AI-assisted changes to cryptography require a senior review.” Developers need a workflow they’ll actually use. And organizations need a story they can defend to a regulator or a customer without exposing proprietary prompts or revealing which junior wrote which line.

A Layered Git Provenance Model You Can Ship Now

You don’t need a grand system to begin. Start with four layers that compose cleanly. Each layer works alone. Together, they give you handles to pull when policies get tighter or your risk profile changes.

1. Signed developer attestation at commit time

2. Artifact provenance emitted at build time

3. CI attestations for checks and reviews

4. Policy automation that reasons on attestations

Let’s walk those in order.

1. Signed developer attestation at commit time

The lightest, highest-leverage move is to add a structured, signed declaration to each commit when AI assistance was used. Don’t invent new UX. Reuse what Git already offers: commit signatures and trailers.

• Signing: Encourage or require developers to sign commits with a verifiable identity. SSH signing and modern keyless flows make this far less painful than the GPG era. The point is to make the commit author field more than a name and an email. A signed commit gives you a cryptographic claim about who authored the change.
• Trailers: Add an opt-in commit trailer convention for AI involvement. A trailer is a line in the commit message footer, like “Signed-off-by: …”. Use something terse and predictable: AI-Assist: yes, AI-Tool: <short name>, AI-Note: <optional freeform>. Keep the minimum data to a boolean and a short tool label. Avoid stuffing detailed prompts or session IDs into the message.

Commit-time developer attestation isn’t surveillance. It’s a promise, made at the moment the change is staged, and tied to an identity. It’s also not infallible; a developer can lie. That’s why it’s layer one, not the whole system. But it’s powerful because it travels with the commit. Every fork, every clone, every vendor mirror: the attestation rides along.

Make it easy:

• Bake trailer insertion into IDEs and commit message templates. A checkbox at commit time is less intrusive than a separate form.
• Teach bots to comment on pull requests when an AI-related change is suspected but unlabeled—gently nudging, not shaming. The bot can’t “detect AI code contributions” reliably, but it can spot patterns like unreviewed bulk edits and suggest an attestation.
• Treat good-faith fixes with kindness. If the attestation is missing, allow a fast follow-up commit to add it.

2. Artifact provenance emitted at build time

Commits are intentions. Artifacts are what run in production. Tie them. Modern supply chain standards make this quite doable.

• Build provenance: Use a provenance format that can describe who built the artifact, with which inputs and environment. The SLSA provenance spec and in-toto attestations are both widely referenced and supported. They let a build system produce a signed statement capturing the commit SHA, builder identity, parameters, and dependencies.
• Signing for artifacts: Sign the artifact and the provenance. Many teams already sign container images or packages. Extend that habit to include provenance statements so you can later prove that image X came from commit Y built by workflow Z.
• Storage: Store attestations in a place designed for them. Some teams attach them as OCI artifacts alongside images. Others push to a transparency log. Pick a model that your CI and registry support without brittle scripting.

This layer is about linkability. If a security team calls about a production incident, they shouldn’t be parsing Git logs. They should be able to look up the running artifact, follow a signed pointer to the commit, and find the relevant attestations immediately.

3. CI attestations for checks and reviews

CI knows things about your code that individual commits don’t. It runs tests, linters, scanners. It enforces code owners and review rules. It can declare which checks were required and which were informational.

Teach CI to say what it did in a signed way.

• Check attestations: After a successful pipeline, have CI emit a signed statement summarizing the checks that ran, their versions, and their results linked to the commit or merge SHA. Keep it compressed: pass/fail plus hashes of reports. Lean on existing standards when possible instead of inventing your own JSON.
• Review attestations: If your platform exposes review state to automation, capture that too. A machine-readable claim that “two human approvals were present; at least one from Team Security” is far more useful than scraping web pages after the fact.
• Policy decisions: If the pipeline allowed an exception—say, a flaky test was waived—attest to the waiver and who approved it. The attestation should be disgracefully boring, like an airline maintenance log entry.

None of this requires sending code to third parties. CI can sign with short-lived keys issued per run. Many platforms support this pattern natively via identity tokens. The result is an audit trail that is truthful, minimal, and bound to the code that shipped.

4. Policy automation that reasons on attestations

Attestations let you enforce rules without guessing. Policy-as-code tools already sit near your CI and repos. Give them higher-quality inputs.

• Pre-merge gating: Write rules like “If AI-Assist: yes and files include cryptography or auth modules, require a senior reviewer” or “If AI-Assist: yes and code introduces a new dependency, run a deeper license scan.”
• Post-merge monitoring: Flag patterns at rest. For example: “Large diffs with AI-Assist: yes without test changes get a follow-up prompt.” Don’t block the merge; surface it in your team channel for discussion.
• Release gates: Only publish artifacts that have both build provenance and CI attestations. You avoid shipping code that bypassed the agreed-on process.

This is where detection can still play a small, useful role. If you have a classifier that’s 70 percent confident a diff was aided by an LLM, treat it as a suggestion to ask for a missing attestation, not as a legal verdict. Use it to increase recall, not to assign blame.

Put together, these layers respect the grain of Git. They acknowledge that governance needs facts developers can assert with one keystroke and facts machines can assert with none. They build a story that can survive audit and incident response without re-running a research paper every time.

Privacy, Ergonomics, and the Minimum Necessary Truth

A provenance model fails if it becomes a diary of private work. Developers deserve guardrails that don’t read their minds. Organizations deserve confident governance without a transcript of every prompt. The trick is to say the minimum necessary truth and say it reliably.

Minimum necessary truth looks like this:

• The identity behind a commit was verified at the moment of commit.
• The developer declared, truthfully, whether AI assisted the change.
• The build system declared, truthfully, how it produced the artifact.
• The CI declared, truthfully, what checks and reviews ran.

Notice what’s missing. No list of prompts. No recording of keystrokes. No screenshot of an IDE. Those might be interesting, but they rarely survive contact with privacy expectations or law. They also shift attention from outcomes to voyeurism.

A few practical hints soften the edges:

• Coarse-grained declarations: “AI-Assist: yes” is enough for most policies. If you must name tools, use short labels. Don’t collect versions or model IDs unless you have a specific, auditable need.
• Local receipts: If your legal team needs the option of future examination, consider local “prompt receipts”—developer devices store hashed transcripts, salted and encrypted by an org-held secret. The attestation only carries a hash pointer. Ninety-nine percent of the time, you never open the box. When you do, you can prove a link without broadcasting the content.
• Data minimization in CI: Keep attestation payloads small. Hash long reports. Store raw artifacts in private buckets by exception, not default.
• Ergonomic defaults: Make attestation the easiest path. A pre-commit hook that inserts a trailer after a checkbox beats a brittle, external portal. A PR template that asks, “Did an LLM assist any part of this change?” is a gentle nudge to tell the truth.

Teams in regulated, multi-entity environments—common in the Gulf, where large programs cut across joint ventures and public-private bodies—need special care. Keep the provenance story consistent across entities, but let each party retain its raw data. Signed attestations travel; private context stays home. That pattern turns a potential privacy fight into a protocol.

Agents Commit Code Too

There’s another player on the field. It’s not only humans using AI assistants. Autonomous or semi-autonomous agents can open pull requests, suggest refactors, and run migration scripts. Some organizations already have bots that fix lint, bump dependencies, or respond to security advisories. Those bots are growing more capable—and more hazardous if left ungoverned.

Agentic code governance is not a buzzword. It’s the extension of the same provenance idea to non-human contributors.

Start with distinct identities. An agent should never hide behind a shared “build bot” account. Give each agent a named, verifiable identity with narrow permissions. Sign its commits. Use platform capabilities to tie the agent’s identity to the workflow that spawned it.

Bound the agent’s scope. Put guardrails in code and policy:

• Where can it write? Restrict to specific branches and path globs.
• What can it change without a human? Maybe formatting and comments can go straight to main, but anything altering logic needs review.
• When can it operate? Off-hours migrations are handy, but midnight pull requests shouldn’t trigger an on-call page just because a bot is bored.

Attest to the agent’s actions. An agent’s pull request should carry an attestation of the toolchain that proposed the changes, including model identity if that’s material to your policy, and the constraints under which it ran. Again, minimum necessary truth. Not every token and hyperparameter—just enough to satisfy your rule engine.

Finally, keep a human loop. Even if an agent can draft a refactor, your policy might require that an owning team approves it. That approval itself becomes an attestation. In a well-lit repository, a line of provenance shows: agent X proposed, human Y approved, CI verified, artifact Z shipped. You can read it and decide whether your system behaved sensibly.

The Honest Counterarguments

Several reasonable objections come up as soon as governance leaves the whiteboard.

“Detection is faster.” Maybe. If you only need a rough sense of how much AI has touched your codebase, detection-based research can get you a number quickly. That can even be helpful as a prelude to real governance: it shows why the investment matters. But it doesn’t give you handles. It’s not enforceable, and it certainly isn’t fair in edge cases.

“Developers will lie on attestations.” Some will. That is not a new risk introduced by AI; it’s the baseline risk of any rules-based system. The cure is a mix of culture and spot checks, not suspicion by default. Layered provenance helps, too. When an unsigned commit without tests introduces a risky dependency and lacks an AI trailer, policy can slow things down and ask for clarity.

“Signing keys can be compromised.” True. That’s not an argument against signing; it’s an argument for modern key hygiene: short-lived keys, hardware-backed secrets where feasible, and keyless flows tied to platform identity. Building on web PKI and transparency logs makes revocation and investigation tractable.

“This adds friction and slows shipping.” It can—if you overreach. The model here leans hard on reuse: Git commit signatures, trailers, CI that already knows the state of tests, and build systems that already sign artifacts. The incremental work is modest, especially compared to the benefits of traceability in an incident or audit.

“Open source won’t adopt heavy provenance.” Many open source communities won’t adopt enterprise-grade attestations, at least not quickly. That’s fine. A layered design degrades gracefully. You can require stronger provenance for internal code and vendor artifacts while accepting weaker signals for third-party code, then compartmentalize risk. Over time, as platforms make signing and attestations easier, upstream projects tend to adopt them when the cost crosses a threshold.

One more caution: provenance is not a moral scorecard. An AI-assisted change is not “worse” by nature. In some areas, it may even be safer because the assistant applied a known pattern consistently. The point of provenance is not to stigmatize; it’s to route work to the right checks.

What Platforms and Enterprises Can Do Tomorrow

Since this is a practical model, the short path matters. Here’s a realistic ramp that a platform team or enterprise can start this quarter.

• Turn on commit signing. Make SSH-based signing the default suggestion in developer onboarding. Offer keyless signing through your platform when available. Don’t force GPG unless you can support it well.
• Adopt a simple AI trailer. Document a one- or two-field trailer for AI assistance. Add it to your commit and PR templates. Update contribution docs. Keep the language neutral and low-friction.
• Teach CI to attest. Extend your pipeline to produce a signed summary of checks and review state for each merge. Store it where your artifact registry or release process can find it.
• Enable artifact provenance. Configure your build system to emit standard provenance tying artifacts to commits. Sign both. Wire your release gating to require it for production publishes.
• Write starter policies. Begin with one or two high-signal rules. For example: AI-assisted changes touching authentication require senior review; AI-assisted changes that add a dependency run a deeper license scan. Ship those rules, measure impact, iterate.
• Add gentle bot nudges. If a PR has a big diff and no AI trailer, the bot asks for one. If a required attestation is missing, the bot links to a one-click fix.

On the platform side, there’s a lot of leverage in small UX changes:

• Surface trailers in the UI. If a commit declares AI assistance, show it clearly in the diff view. If the commit is signed, show “Verified” with details. Don’t bury the signal.
• First-class fields. Consider exposing structured fields for developer attestation rather than relying on free-form commit messages. That supports search and policy in a way scraping trailers never will.
• Sign in the right place. When CI emits attestations, give it proper ephemeral identities with clear provenance back to the workflow run. Expose that in APIs so policy tools don’t have to reverse engineer it.
• Make it exportable. Let teams retrieve provenance for artifacts and releases via API. Don’t wall it off inside the platform UI.

Everyone benefits from rough alignment on standards. The ecosystem already has a common vocabulary for build provenance. Reuse it. When there’s a gap—say, a minimal schema for developer AI attestation—keep it small and human-first. A trailer format that fits comfortably into a commit message is more likely to survive than a 50-field schema.

A note on regional dynamics: in places like the UAE, where public bodies and private players co-develop platforms at scale, provenance that travels cleanly across organizational boundaries is essential. If Entity A can consume Entity B’s attestations without reaching into B’s internal logs, everyone moves faster with fewer legal knots.

Beyond Detection, Toward Durable Habits

If you want a quick picture of how much AI touched your codebase, detection gets you a blurry map. If you want to govern, you need a logbook.

The logbook here is a set of small, durable habits: sign what you assert; assert the minimum necessary truth; have machines attest to the parts they control; write policies that act on attestations and treat humans respectfully. That’s it. None of this requires inventing new cryptography or waiting for a standards committee to finish its tenth draft.

The novelty is not technology. It’s the decision to make provenance a first-class part of everyday Git hygiene, not a compliance project you dust off once a year. That decision reroutes energy from headline-chasing detection tools into infrastructure your team will be glad to have when incidents, audits, and complex collaborations show up—as they always do.

So by all means, read the papers. Run a “slop score” script on a rainy Friday and have a debate about what surprised you. Then go back to work and wire your repos for provenance. The next policy you pass should be as simple as checking a trailer and an attestation, not as brittle as guessing from style.

If platforms keep tightening identity and provenance by default, and enterprises adopt layered, humane policies that assume developers are partners, not suspects, we get a steady state worth living in: fast, accountable, and boring. That’s the right kind of progress for software that many people depend on every day.