# AI code provenance checks before company adoption

> Use AI code provenance checks to separate copyright, open source license, trade secret, and indemnity risks before generated code reaches production.

AI code generation can pass a security review and still leave a company unable to explain where a critical function came from, whether it can be redistributed, or who pays when a rights holder complains. I would not approve a coding assistant because its output looks original, its vendor has a large legal department, or an engineer promises to review every suggestion. None of those facts establishes provenance.

A workable policy separates four questions: could the output copy protected expression, does an open source license impose conditions, did anyone expose or reproduce a trade secret, and does the contract transfer any financial risk to the vendor? The company then attaches evidence to each accepted change. That is stricter than a blanket approval, but far cheaper than reconstructing six months of AI-assisted development after a diligence request or demand letter.

## Four risks need four separate decisions

Copyright, open source licenses, trade secrets, and indemnity overlap, but they do not answer one another. Put them in one row called "legal risk" and reviewers will approve a reassuring vendor statement that resolves only a fraction of the problem.

Copyright asks two different questions. First, might generated code reproduce protected expression owned by somebody else? Second, will the company itself own an enforceable copyright in the result? A clean similarity scan helps with the first question. It cannot create human authorship for the second.

The U.S. Copyright Office's report Copyright and Artificial Intelligence, Part 2 says that prompts alone, with generally available technology, do not give a user enough control to make that user the author of the output. It also says human selection, arrangement, or modification can qualify when it meets the normal originality standard. That is a useful warning for software teams: "our employee typed the prompt" is not an ownership analysis. Keep the human design notes and substantive edits when exclusivity matters, and ask counsel how local law treats them.

Open source compliance concerns permission and conditions. Code can be intentionally available to the public and still require attribution, notice preservation, source delivery, or licensing of modifications. Conversely, a snippet with no license is not safely reusable merely because a search engine can find it. Public access is not permission.

Trade secret risk runs in both directions. An employee can disclose confidential code, customer data, architecture, or an unreleased product plan in a prompt. A model can also return material that belongs to a third party or another business unit. Similarity filters aimed at public repositories will not reliably identify either event.

Indemnity is contractual risk allocation. It matters after a claim arrives. It does not prove clean provenance, grant missing open source rights, stop disclosure, or guarantee that the vendor will cover the claim. Treat it as the fourth decision, never as a substitute for the first three.

## Approve the service before approving its code

Procurement should approve a specific service, plan, model path, and configuration, not a vendor name. The same vendor may offer a consumer chat product, an enterprise coding plan, an API, and a locally hosted model under different data terms. "Vendor X is approved" gives engineers permission to choose the weakest route.

Require written answers and contract references for these points:

- whether prompts, repository context, outputs, feedback, and telemetry train or improve any model
- retention periods, deletion behavior, storage regions, subprocessors, and administrator controls
- which humans can access submitted content and under what support or abuse-review process
- whether the service can search public code, customer code, or both when producing a suggestion
- which similarity, citation, or duplicate-detection controls exist and whether administrators can enforce them

Do not accept "your data remains yours" as an answer. Ownership language says little about storage, training, access, or confidentiality. Ask what the service does with each data class and where the binding promise appears.

NIST's Generative Artificial Intelligence Profile recommends an inventory of third parties with access to organizational content, an approved-provider list, records of changes that include sources and timestamps, and acquisition reviews that cover intellectual property, privacy, and security. That is more useful than inventing a separate AI committee. Add these fields to the procurement and software controls the company already runs.

Model provenance belongs in the service review too. Ask the vendor to describe training-data categories, collection authority, opt-outs or exclusions, code-specific datasets, filtering, claim history, and the procedure used when a rights holder reports material. A vendor may decline to reveal its full dataset. Record the gap and decide whether the intended use can tolerate it. Do not silently convert "confidential" into "verified."

Open weights deserve the same diligence. The Open Source Initiative's Open Source AI Definition requires enough data information for a skilled person to build a substantially equivalent system, along with training and inference code and model parameters under appropriate terms. A downloadable weight file with a permissive label may not satisfy that definition. More importantly for adoption, the model license, training code license, weight terms, dataset rights, and generated output terms can all differ.

Self-hosting changes the disclosure path, not the underlying rights. Running a model inside the company's network may keep prompts away from a cloud provider, yet the model can still emit memorized code, carry restrictive weight terms, or depend on training data with unclear provenance. Review the model package, serving code, container images, adapters, and datasets as separate components. Record who can update each one.

Fine-tuning and retrieval need their own approval. A company that trains an adapter on private repositories or lets the assistant retrieve across them has created a new route by which restricted material can influence output. Confirm that every source repository may be used for that purpose, preserve its access boundary, and test whether users can retrieve code they could not otherwise read. Reopen the review whenever a new corpus joins the system.

## Every accepted change needs a source trail

The review unit should be the merged change, not the chat session. Engineers explore, discard, regenerate, and edit. Saving every token creates an expensive archive without showing which generated material reached production. For each pull request, record the AI-assisted files, the service and model, the human reviewer, the input sources, scan results, and the disposition of any match.

A small record in the repository is enough to start:

```yaml
version: 1
change: payments/retry-policy
tool:
  service: approved-enterprise-assistant
  model: model-family-2026-05
  account: company-managed
inputs:
  repositories:
    - payments-api@8f2c19a
  prohibited_data: false
outputs:
  files:
    - src/retry.ts
  human_changes: substantial
checks:
  secret_scan: pass
  similarity_scan: pass
  dependency_scan: pass
  license_review: not_required
review:
  engineer: dev-184
  approver: lead-27
  date: 2026-07-18
```

Do not put prompts or source code into this record. Point to access-controlled logs if policy requires retention. The metadata should prove which approved route was used and which checks ran without creating a second copy of confidential material.

The `prohibited_data` field is an attestation, not a magic control. Back it with repository classification, endpoint policy, identity enforcement, and training. The `human_changes` field also needs a team definition. I use "substantial" only when the engineer can explain the design, identify generated portions, and has changed more than names or formatting. This is operational evidence, not a legal conclusion about authorship.

Contractors and autonomous coding agents must write the same record. Do not rely on an employment agreement to fill the gap. A contractor may use an unapproved account, and an agent may call several models or retrieval tools within one task. The orchestrator should log each model route and context source, while the human who merges the change accepts responsibility for the combined output.

You can confirm the change and record survived together with ordinary Git commands:

```bash
git show --name-only --format='commit=%H%nparent=%P%nauthor=%ae%nsubject=%s' HEAD
git show HEAD:.provenance/payments-retry-policy.yml
```

The output shape gives an auditor a commit hash, parent, author, subject, changed file list, and the exact provenance record stored in that commit. If the record names `src/retry.ts` but the commit changes five other generated files, the reviewer rejects it. That simple reconciliation catches more weak approvals than a policy PDF.

Sign or otherwise protect release attestations if the threat model includes record tampering. The goal is to prove that the reviewed commit, provenance metadata, build inputs, and shipped artifact belong to the same chain. A pull request record that disappears during a squash, or an artifact rebuilt later from mutable dependencies, cannot support that claim. Tie the release to an immutable commit and software bill of materials.

## Similarity checks investigate copyright risk

A similarity detector is a triage tool. It compares generated text against an indexed corpus and returns candidate matches. It cannot declare code non-infringing, because its corpus is incomplete and legal analysis depends on protectable expression, license, access, context, and jurisdiction.

Run the check on the final diff before merge, not only on suggestions shown in the editor. An engineer can accept several short suggestions that combine into a meaningful match, or edit a flagged block and preserve its expressive structure. The final artifact is what the company ships.

Define thresholds as routing rules rather than safety claims. A short match involving a conventional error check may need no action. A longer or structurally distinctive match should produce a source location, matched lines, confidence or similarity measure, known license, and reviewer decision. If the source lacks a clear license, rewrite from requirements without consulting the matched implementation, or remove the block.

Keep the detector's limitations in the approval record. At minimum, note corpus coverage, excluded repositories, supported languages, minimum match length, and whether comments count. A vendor's "public code filter enabled" badge does not tell a reviewer what was actually compared.

There is no universal safe number of matching lines. Ten lines of a highly original algorithm may matter more than a hundred lines of mechanical declarations. Percentage scores also shift when a detector normalizes names, formatting, or comments. Write the escalation rule around distinctiveness, source, license, and product use, then let counsel assess close cases. A numeric threshold can trigger review, but it cannot grant permission.

Check more than exact text. Renamed variables and translated programming languages can preserve the structure of a distinctive implementation. Token, syntax-tree, and semantic methods each find different candidates and each creates false positives. For high-risk modules, combine automated results with a reviewer who knows the technical domain and can recognize an implementation that arrived without a credible design history.

The popular recommendation to ban any suggestion that resembles public code sounds safe and usually fails. Software contains conventional declarations, protocol constants, generated bindings, and standard API patterns. A zero-match rule floods reviewers with noise, teaches them to ignore alerts, and can reject required interoperability code. Investigate meaningful matches and document why each one is permitted, rewritten, or removed.

Copyrightability of your own output needs a different record. For code that carries competitive value, keep the human-authored specification, architecture decision, tests, review comments, and meaningful revisions. A similarity scan says nothing about whether a court would recognize the company's authorship. The evidence of human control sits in the development history.

## Open source obligations follow the code

Open source code is not a provenance failure. Undisclosed or incompatible obligations are. The approval policy should let teams use components deliberately while stopping accidental import of code whose conditions nobody reviewed.

SPDX gives the company a precise vocabulary. `MIT`, `Apache-2.0`, and `GPL-2.0-only` identify specific licenses, while expressions such as `Apache-2.0 OR MIT` describe a choice. SPDX also makes an important distinction that teams miss: its short identifiers communicate license information, not copyright ownership. Preserve copyright notices and do not infer the owner from an SPDX line.

Do not confuse the coding assistant's output terms with the license of material inside an output. A contract may assign the vendor's rights in generated text to the customer, but the vendor cannot assign rights it never owned in a reproduced third-party block. The same problem appears when model weights use one license and an emitted dependency uses another. Review the artifact that ships.

Require a software bill of materials and license scan for the final build whenever AI-generated work adds or changes a dependency, copies a meaningful implementation, generates vendored code, or inserts a license header. A source scan alone misses packages pulled during build and code generated from schemas or toolchains. A binary or container scan alone may miss source-delivery duties. Use both at release boundaries when the product is distributed.

The reviewer should classify every finding:

- dependency with an approved license and recorded version
- copied or adapted source with notices and obligations preserved
- dual-licensed code with the selected option recorded
- license conflict requiring replacement or counsel review
- unknown source or license, which blocks the merge

OpenChain's ISO/IEC 5230 describes open source compliance as a program with defined processes, roles, responsibilities, and sustainability. I agree with that framing. A one-time scanner purchase will not decide who answers a notice question, who supplies source to recipients, or who updates an attribution file after an AI assistant changes dependencies.

Generated tests, examples, and configuration need the same review when they ship with the product. Teams often scan `src/` and ignore copied fixtures or generated clients. Copyright and license conditions do not care which directory the developer considered important.

## Trade secrets require control of inputs and outputs

The fastest way to lose confidence in AI adoption is to tell engineers "never paste secrets" while giving the assistant repository-wide context. Secrets include more than passwords. Unreleased source, pricing logic, incident details, customer records, acquisition plans, private issue comments, and another party's code under a nondisclosure agreement can all require restricted handling.

Classify repositories and paths before enabling access. A practical matrix has approved, restricted, and prohibited input classes for each service. Public repositories may use an approved cloud assistant. Internal application code may require the enterprise plan with company identity, configured retention, and no model training. Regulated data, third-party confidential code, security investigation material, or export-controlled content may require a local model or no generative tool at all.

Enforce the matrix technically where possible:

- require company accounts and single sign-on for approved services
- disable unapproved browser extensions and personal API tokens on managed devices
- exclude sensitive paths such as production dumps, private keys, and legal folders from context
- run secret and sensitive-data scanning on prompts where the service supports it and on final diffs
- log service identity, policy version, and repository classification for each accepted change

Output review matters because a model can produce a secret-looking value, confidential business rule, or third-party code even when the current prompt looks clean. A normal secret scanner catches credential formats and high-entropy strings. It will not recognize a proprietary algorithm. For sensitive modules, require a domain owner who can spot material that does not belong.

Do not retain prompts forever by default. Detailed prompts can contain the very material the company is trying to protect. Set retention by investigation need, contract, and data classification. Limit access, encrypt the archive, and test deletion. Provenance needs enough evidence to reconstruct the decision, not an uncontrolled transcript warehouse.

When disclosure happens, treat it as an incident. Preserve the necessary logs, revoke exposed credentials, ask the vendor to delete retained content under the contract, assess notification duties, and identify every output influenced by the material. Quietly deleting the chat leaves the company unable to measure the exposure.

Test confidentiality promises with concrete scenarios during procurement. Ask whether a support engineer can view a prompt, whether abuse monitoring stores it outside the normal region, whether feedback submission changes its treatment, and whether deletion removes backups and derived logs. Then compare those answers with contracts already signed with customers. A provider's confidentiality clause cannot authorize a use that the company promised its customer it would never make.

## Indemnity must survive contact with a claim

An indemnity headline has little value until counsel reads the operative terms. The useful questions are who receives protection, which claims qualify, what the vendor must do, which customer actions cancel coverage, who controls defense and settlement, and what financial limits apply.

Microsoft's published Customer Copyright Commitment illustrates why configuration belongs in legal review. For covered GitHub offerings, the published mitigation requires duplicate detection set to block, or compliance with cited licenses when annotation mode is used. A team that turns off the control may also turn off the protection it expected. Other services and contracts have different conditions, so record the exact product terms and configuration rather than copying this example.

Ask counsel to extract these fields into the approval:

- covered customer entities, users, services, models, and output types
- covered legal theories, territories, and use cases
- exclusions for prompts, fine-tuning, modifications, combinations, or known matches
- required filters, notices, cooperation, tender deadlines, and vendor control of defense
- defense costs, settlements, damages, liability caps, and termination effects

Watch for a circular promise: the vendor covers infringement only when the customer did not know, could not have known, and complied with all referenced documentation, while documentation changes at the vendor's discretion. That may still have some value, but the company needs monitoring and evidence to satisfy it.

Indemnity also does not solve weak ownership. A vendor might defend certain third-party copyright claims while making no promise that the customer can stop a competitor from using similar generated code. Nor does copyright indemnity necessarily cover patents, trademarks, trade-secret claims, open source compliance work, or the cost of replacing code. Put each theory in its own contract row.

For a small vendor or open model project, a broad promise may exceed the promisor's ability to pay. Check insurance, cap structure, survival, and the contracting entity. The goal is not the longest clause. It is a credible defense for the claims that remain after technical controls.

## Risk tiers keep the review proportionate

Applying the same ceremony to a disposable test and a payment engine guarantees workarounds. Set tiers by where the code runs, what it controls, what data it touches, how it is distributed, and how hard it would be to replace.

Low-risk use can include throwaway prototypes, internal scripts with no sensitive data, and suggestions that an engineer rewrites before use. Require an approved service, normal code review, secret scanning, and a lightweight provenance record.

Standard production use adds final-diff similarity scanning, dependency and license scanning, test evidence, and a named human approver. This should cover most application work.

High-risk use includes code embedded in distributed products, safety or financial controls, proprietary algorithms, regulated systems, and large generated modules that few employees understand. Add legal review of material matches and license conflicts, a domain owner, stored generation evidence, stronger authorship records, and a replacement plan. Some prohibited data or contractual restrictions should block AI generation entirely.

Distribution changes the tier. An internal service may never trigger source-delivery or notice duties that attach when the company ships software to customers. A prototype can also become production through a hurried launch. Put a promotion check in the release process so earlier low-risk approval does not follow the code into a new use automatically.

Use an approval checklist that produces a decision, owner, and evidence:

1. Confirm the exact service, plan, model, account, and policy configuration appear on the approved list.
2. Classify every repository and context source, then remove prohibited inputs.
3. Record generated or materially AI-edited files in the pull request provenance record.
4. Run security, secret, similarity, dependency, and license checks required by the risk tier.
5. Investigate matches and obligations, preserving sources, notices, decisions, and counsel review where needed.
6. Verify indemnity conditions remain enabled and attach the applicable contract version.
7. Require a human who understands the code to approve behavior, maintainability, and provenance.
8. Store the record with the merged commit and recheck the release artifact.

That list is intentionally longer than "human reviews the code." A reviewer can find a race condition and miss a copied license header. Technical correctness and provenance are different review jobs.

Exceptions need an expiry date and named executive, legal, and engineering owners. "Temporary" approvals otherwise become the permanent route. Reassess when the vendor changes terms, model family, retention, filters, training policy, or subprocessors, and when the company moves the tool into a new data class or distribution model.

Measure whether the control works. Track unapproved service attempts, provenance records missing at merge, unresolved similarity findings, unknown licenses, and releases whose artifact cannot be tied back to a reviewed commit. Do not turn those counts into developer performance scores. Use them to find a confusing rule, a missing integration, or a service that cannot meet the company's evidence needs.

## Make the policy testable in one release cycle

Start with one repository and one release, then test whether the evidence can answer an uncomfortable question: six months later, can a person who was not on the team identify the generated files, approved service, source context, scans, matches, license decisions, human changes, and contract terms?

Assign ownership before buying more tooling. Engineering owns correct use and the pull request record. Security owns service access, data controls, and incident handling. Open source program staff or a named engineering owner handles license obligations. Legal interprets rights and contract coverage. Procurement preserves the signed terms and change notices. One person may hold several roles in a startup, but the responsibilities still need names.

Run a tabletop exercise with two cases. In the first, a similarity scan finds a distinctive 40-line block from a repository under an incompatible license after release. In the second, an engineer pasted a customer's private integration code into a personal assistant. Ask the team to locate the relevant commits and logs, stop further exposure, identify shipped artifacts, notify decision makers, contact the vendor, and replace affected code. The missing evidence will tell you which controls exist only on paper.

A Team & AI Audit from oleg.is can map this approval flow alongside engineering cost and delivery constraints, including where a smaller AI-augmented team needs stronger records rather than more meetings. The useful deliverable is a control path the existing team can run on every release.

Do not approve AI code generation with a single yes or no. Approve a bounded service for a bounded class of code, demand evidence at merge and release, and keep the four decisions separate. If the company cannot produce that evidence for its next release, it has adopted output generation but not code provenance.