AI Code Provenance for Commits: Recording Which Tool and Model Produced Each Change

Treat attribution as an evidence problem

Standard Git metadata records an author and a committer. It does not record the AI tool, the model, the version or the settings in force when code was generated. When an indemnity claim, an open-source license audit or an M&A diligence request arrives, those are the details reviewers want.

Vendor indemnity programs typically carry conditions tied to specific tools, configurations and settings. To rely on one, a team has to show which tool produced the code, in which configuration, at the time. License audits and diligence reviews ask a related question: where did this code come from, and under what license context?

A commit trailer typed by a developer answers neither question reliably. Tags are applied inconsistently, are easily omitted, and cannot be verified by the person reading them. An auditor, counsel or insurer will treat them as a convention, not as evidence.

Two points from NIST guidance frame the design. NIST SP 800-218A does not distinguish human-written from AI-generated code, because all code needs evaluation for vulnerabilities and other issues. AI attribution is therefore an added evidence layer, not a replacement for that evaluation. And NIST AI 600-1 notes that provenance data tracking helps assess authenticity, integrity and intellectual property rights, with metadata recording as one of the well-known techniques.

Fields a commit-level provenance record needs

NIST's provenance metadata elements are a useful starting point: the creator or developer, date and time, modifications and sources. NIST does not define commit-level AI fields, so the rest of the record below is design judgment. Each field earns its place by answering a specific audit question.

• Tool and build: The assistant and its version. SP 800-218A also calls for build tool versions and features in provenance tracking.
• Model and version: The model that generated the change. This maps to NIST's creator or developer element.
• Session or interaction reference: A stable identifier pointing to the full interaction record. This is the key an auditor follows from commit to evidence.
• Timestamp and modification scope: When the change was generated and which files or ranges it touched, matching NIST's date/time and modification elements.
• Policy decision: The outcome (allow, redact, block, escalate) and the policy version in force. This is the field most relevant to configuration-based indemnity conditions.
• License and security context: Origin and license findings and security findings for the generated code, captured when it was produced.

Comparing capture points

The trade-offs below are editorial judgment. Most programs combine several capture points, but the evidentiary weight differs sharply. The question to ask of each is who or what creates the record, and whether it can be created after the fact.

• IDE or assistant plugin: Close to generation and able to see tool and model. Coverage depends on every assistant offering a plugin and on the plugin being installed and unmodified.
• Git hooks and trailers: Easy to adopt and visible in history. Hooks run on developer machines and can be skipped, and trailers are only as reliable as whoever wrote them.
• CI checks: Centrally enforced and good for verifying that records exist and are consistent. CI sees the result of a change, not how it was generated, so it cannot establish the model.
• Runtime enforcement in the execution path: Records are created as a side effect of each interaction, with the policy decision attached. It requires the path to cover every assistant in use.
• Git notes: Keep metadata out of commit messages. Notes are keyed to commit identifiers, so rewrites need explicit handling, and they are still only as trustworthy as their writer.
• External evidence store: Durable and able to be made tamper-evident, with retention managed separately from the repository. It needs a reliable join key back to commits.

History rewriting, mixed authorship and retention

Squash, rebase and cherry-pick all produce new commit objects with new identifiers. A record keyed only to a commit hash can therefore be orphaned by routine workflow. Key the record to the interaction reference and to a hash of the generated change, then resolve the final commit to its records at merge time, for example in a CI step. Verify this behavior in your own workflows before relying on it.

Mixed authorship needs finer granularity than a single label per commit. Record AI involvement per interaction, with the files or ranges affected, and record later human edits as modifications. A commit-level summary can then be derived from those records. Labeling a whole commit as AI-generated or human-written overstates precision in both directions.

Signed commits remain worth enforcing. NIST SP 800-204D describes verifying developer identity and enforcing signing of commits as pipeline protections. Signatures bind a commit to an identity, not to a tool or model, so they are an integrity baseline and not AI attribution.

For retention, SP 800-218A refers to retaining provenance data for each release, and NIST AI 600-1 advises a document retention policy. Link commit-level records to release-level artifacts such as an SBOM, and set retention to cover the longest period in which an indemnity claim or audit could be raised. Counsel should confirm that period. NIST also advises that contracts specify provenance expectations, which is a reason to align vendor terms with the fields you can actually produce.

Evidence by enforcement, not self-reporting

NIST's emphasis on maintaining records of changes, including sources, timestamps and metadata, points toward creating the record when the change happens. Reconstructing it later from assistant logs or developer recollection produces weaker evidence, because the policy settings and context in force at that moment may no longer be recoverable.

This is where capture in the execution path matters. Trussed enforces policy inside the execution path of coding assistants, with actions that include allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. Its code provenance capability records the origin, license and security context of code, and the audit-ready evidence is generated by enforcement at runtime, not reviewed after the fact. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.

The scope is specific. This is interaction-level evidence for code produced through coding assistants. It does not address model lineage or dataset provenance, and it does not trace end-to-end agentic workflows. Whatever tooling you choose, the architectural test is the same: the record exists because the interaction occurred, not because someone remembered to describe it.