A Buyer's Guide to IP provenance for AI code

During technical diligence an acquirer asks which parts of the codebase were AI-generated and under which tool and settings. The answer is that nobody recorded it. Assistants were adopted across teams over eighteen months, usage was never tracked at commit level, and the code is now indistinguishable from anything else in the repository. The licence scanner comes back clean, which addresses a different question. What cannot be answered is the one that was asked, and the inability to answer is itself the finding.

The exposure is not that AI-generated code carries a licence problem. It is that you cannot say which code it is.

IP provenance for AI code means recording, at the time of generation, which code came from an assistant, under which tool, model, and settings, so the question can be answered later.

How Often AI-Generated Code Introduces an OWASP Top 10 Flaw

Understand how often AI-generated code introduces critical OWASP security flaws.

Download Whitepaper

However, most programmes buy licence scanning, which detects known code matches and says nothing about origin, tooling, or the terms in force when the code was produced.

If you are a CTO or Head of Engineering at an enterprise, the intent of this article is:

Define why attribution at generation time is the control
Show what licence scanning does and does not cover
Lay out what diligence and indemnity actually require

To do that, let's start with the basics.

What Is IP Provenance for AI Code? The Basic Definition

At a high level, IP provenance for AI code is the ability to establish where code in your repository came from. For AI-assisted development that means knowing which portions were generated, by which tool and model version, under which account and terms, and how much a human changed afterwards. None of that is recoverable retrospectively. Code generated eighteen months ago under a tool whose terms have since changed looks identical to hand-written code, which makes the capture point the moment of generation and the control a workflow one rather than a scanning one.

To compare:

Relying on licence scanning for provenance is checking a warehouse for stolen goods by looking for serial numbers on a watch list. It catches known items. It cannot tell you which crates arrived from which supplier under which contract.

Why Does IP Provenance for AI Code Matter?

Issues that it addresses or resolves:

Diligence questions about AI-generated code with no answer
Tool terms changing with no record of what was generated when
Licence scanning treated as an origin control

Resolved Issues by Provenance Done Well

Generated code attributable at commit level
Tool, model, and terms recorded at generation time
Diligence answerable with evidence

Core Components of IP Provenance for AI Code

Attribution captured at generation, not inferred later
Tool, model version, and settings recorded
Account and applicable terms linked
Human modification extent noted
Retention through the diligence horizon

Modern Provenance Practice

Assistant telemetry linked to commits
Repository metadata carrying generation attribution
Tool and terms inventory with effective dates
Licence scanning retained for its actual purpose
Vendor indemnity terms recorded per tool

These practices answer the question. Linking assistant telemetry to commits is the step that makes attribution possible at all.

Other Core Issues They Will Solve

Vendor indemnity claims supportable with evidence
Tool policy changes assessable against existing code
Diligence proceeding without a finding

In Summary: IP provenance requires attribution at generation time, because origin is not recoverable from the code afterwards and scanning answers a different question.

Importance of IP Provenance for AI Code in 2026

Assistants are in routine use across engineering teams. Four reasons explain why this matters now.

1. Adoption ran ahead of recording.

Tools were adopted team by team with no attribution practice.

2. Terms change over time.

A vendor's IP and indemnity position can differ from when the code was generated.

3. Diligence now asks.

Acquirers and investors ask the question directly, and an inability to answer is a finding.

4. Scanning does not cover origin.

A clean licence scan says nothing about which code was generated or under what.

Traditional vs. Modern Provenance Approach

Licence scanning as the control vs. attribution at generation
Origin inferred later vs. recorded at commit
Tool terms unrecorded vs. inventoried with effective dates
Indemnity assumed vs. terms captured per tool

In summary: A modern approach captures origin when it exists and keeps scanning for what it is good at.

Details About the Core Components of IP Provenance for AI Code: What Are You Designing?

Let's go through each component.

1. Attribution Layer

Recording at generation.

Attribution decisions:

Generated portions marked at commit
Granularity decided
Developer workflow impact minimised

2. Tool Layer

Which assistant and version.

Tool decisions:

Tool and model version recorded
Settings captured where material
Account and licence tier linked

3. Terms Layer

What applied at the time.

Terms decisions:

Tool terms inventoried with effective dates
Indemnity position recorded
Changes tracked over time

4. Modification Layer

How much a human changed.

Modification decisions:

Extent of human editing noted
Substantially rewritten code distinguished
Thresholds defined

5. Retention Layer

Surviving to diligence.

Retention decisions:

Records kept through the diligence horizon
Survivability across repository migrations
Accessibility for counsel

Benefits Gained from Provenance Done Well

Diligence answerable with evidence
Indemnity claims supportable
Policy changes assessable against existing code

How It All Works Together

The organisation captures attribution at the moment of generation, marking which portions of a commit came from an assistant, because that information does not exist anywhere afterwards and cannot be reconstructed from the code. The tool, model version, and material settings are recorded alongside, with the account and licence tier, since those determine which terms applied. A terms inventory with effective dates is maintained so that code generated in a given period can be matched to the IP and indemnity position in force then, which is the thing a vendor's changed policy makes relevant. The extent of human modification is noted against defined thresholds, because substantially rewritten code sits differently. Records are retained through the diligence horizon and survive repository migrations. And licence scanning continues for its actual purpose, which is detecting known code matches.

Common Misconception

Our licence scanner comes back clean, so our AI-generated code is fine.

A scanner compares your code against known corpora and flags matches. That is a useful control against a specific risk and it answers none of the provenance questions. It cannot tell you which code was generated, which tool produced it, what terms were in force at the time, whether a vendor indemnity applies, or how much a human changed. When an acquirer asks the origin question, a clean scan is not responsive, and the absence of any record becomes the finding regardless of whether the underlying code has a problem. The two controls address different things and one does not substitute.

Key Takeaway: A clean licence scan answers a different question. The finding in diligence is usually the absence of a record, not a defect in the code.

Real-World Provenance Work in Action

Let's take a look at how it operates with a real-world example.

We worked with an engineering organisation unable to answer a diligence question, with these constraints:

Capture attribution at generation rather than inferring later
Record tool, version, and applicable terms
Retain through the diligence horizon

Step 1: Capture at Generation

The only moment it exists.

Generated portions marked at commit
Granularity decided
Workflow impact minimised

Step 2: Record the Tool

And its version.

Tool and model version captured
Settings recorded where material
Account and tier linked

Step 3: Inventory the Terms

With effective dates.

Terms recorded per tool
Indemnity position captured
Changes tracked

Step 4: Note Modification

Human contribution.

Editing extent noted
Rewritten code distinguished
Thresholds defined

Step 5: Retain and Preserve

Through diligence.

Retention horizon set
Survives migrations
Accessible to counsel

Where It Works Well

Teams whose assistants emit usable telemetry
Repositories supporting commit-level metadata
Organisations with a diligence horizon in view

Where It Does Not Work Well

Licence scanning treated as provenance
Attribution attempted retrospectively
Records that do not survive repository migration

Key Takeaway: Capture at generation, record the tool, inventory terms, note modification, retain through diligence.

Common Pitfalls

i) Treating scanning as provenance

Scanners detect known matches and say nothing about origin, tooling, or terms. Keep both controls and do not substitute one.

Scanner clean
Question unanswered
The absence was the finding

ii) Retrospective attribution

Generated code is indistinguishable from written code after the fact. Capture at the moment or accept you never will.

iii) No terms inventory

Vendor IP and indemnity positions change, and matching code to the terms in force requires effective dates. Maintain the inventory.

iv) Records that do not survive

Attribution held in a tool that is replaced, or lost in a repository migration, is equivalent to no attribution. Design for survivability.

Takeaway from these lessons: The information exists for one moment, and after that it is gone.

IP Provenance Best Practices: What High-Performing Teams Do Differently

1. Capture attribution at generation time

Record which portions came from an assistant when it happens, since the information is unrecoverable later.

2. Record tool, model version, and account

Make it possible to match code to the terms that applied.

3. Maintain a tool terms inventory with effective dates

Track vendor IP and indemnity positions over time, not just currently.

4. Note the extent of human modification

Distinguish lightly accepted suggestions from substantially rewritten code with defined thresholds.

5. Design records to survive migrations and tool changes

Ensure the attribution outlives the assistant that produced it.

Logiciel's value add is helping engineering organisations capture code provenance at generation, so the diligence question has an answer.

Takeaway for High-Performing Teams: Capture at generation, record the tool, date the terms, note modification, survive migration.

Signals You Are Doing This Well

How do you know it is working? Not by scanner results, but by whether you could answer an acquirer today. These are the signals that separate provenance from licence hygiene.

Attribution exists. Generated code is marked at commit level.

Tools are recorded. Model version and account are captured.

Terms are dated. You can match code to the position in force then.

Modification is noted. Rewritten code is distinguishable.

Records survive. Attribution outlasts tool and repository changes.

Adjacent Capabilities and Connected Work

This work does not exist in isolation. Provenance depends on, and feeds into, the surrounding estate. Ignoring the adjacencies is the most common scoping mistake.

Technical due diligence consumes the record. Third-party model risk covers vendor terms. Test automation for AI-written code covers quality assurance. Acceptable use policy governs which tools are sanctioned. Naming these adjacencies upfront keeps the work scoped and helps leadership see generation time as the capture point.

The common mistake is treating each adjacency as someone else's problem. The attribution capture is your problem. The terms inventory is your problem. The retention design is your problem. Pretend otherwise and a clean scan will accompany an unanswerable question. Own the adjacencies you depend on, partner with the teams that hold them, and share the record.

Conclusion

AI-generated code is indistinguishable from hand-written code the moment it lands in a repository, which means provenance is a capture problem rather than a detection problem. Licence scanning addresses a real and different risk, detecting known code matches, and it cannot say which portions were generated, by which tool under which version and terms, or how much a human changed afterwards. When an acquirer or a vendor indemnity claim requires that information, the absence of a record is itself the finding. Capture attribution at generation, record tool and account, maintain a terms inventory with effective dates, note modification extent, and design the records to survive.

Key Takeaways:

Generated code cannot be identified retrospectively, so capture happens at generation or not at all
A clean licence scan answers a different question from the one diligence asks
Vendor terms change, so matching code to the position in force needs effective dates

Establishing IP provenance requires capturing at the moment. When done correctly, it produces:

Diligence questions answerable with evidence
Indemnity claims supportable

A Spec-Driven Development Playbook for a Codebase That's Mostly AI-Written

Build reliable specifications for codebases increasingly shaped by AI-generated production code.