AI Code Provenance, Licensing and IP Risk

Turning on “block suggestions matching public code” is a real control and a weak assurance. It compares generated text against one index, above a length threshold, at the moment of suggestion. Everything that decides your exposure happens outside that comparison — in the dependency the assistant recommended, in the edit that made a blocked pattern pass, and in the question that arrives three years later asking what you can show.

The sentence that turns a contract into a control. Microsoft’s Customer Copyright Commitment documentation states that on tendering a claim “the customer will be required to demonstrate compliance with all relevant requirements”. An indemnity you cannot evidence is an indemnity you may not have.

A public-code filter protects against one thing: your developers unknowingly accepting a block of text that already exists, near-identically, in the public code the vendor indexes. It does not establish that your codebase is clean, because it matches text rather than derivation, sees one corpus rather than all code, and evaluates the suggestion rather than the merged result. The exposure it leaves behind is not exotic. It is the package the assistant told you to install, the attribution obligation nobody discharged at release, and — the one that costs the most time — the absence of any record of which code was AI-assisted, under which tool, at which configuration, on which date. That last gap is a governance problem rather than a technical one, and it surfaces years later in acquisition diligence, in a customer audit clause, or in a demand letter, where the burden is on you to describe your own history. What follows is what the filter does and does not do, the exposures ranked against the controls that actually move them, a provenance record model you can operate without instrumenting a single keystroke, how to read the indemnity you think you have, and how this is treated as an ISO/IEC 42001 risk with a documented treatment rather than a policy sentence.

That third choice is the one with governance consequences, and it is usually made by whoever set the tenant up. Blocking mode removes the decision from the developer. Annotate or reference mode keeps the suggestion and hands them a licence obligation, on screen, in the middle of a task — which is a reasonable design if somebody is going to record and discharge the obligation, and a liability if nobody is. The published required-mitigation terms for one major platform make this explicit for code generation: the protected-material code model must be configured in either filtering or annotating mode, and where annotating is chosen, complying with the cited licence becomes the customer’s own obligation. The contract is not ambiguous about who owns that.

Two practical notes. The setting almost always exists at both user and organisation level, and only the organisation-level policy is a control you can evidence — a per-user toggle is a preference. And the setting is a point-in-time state, so a new organisation, a migrated repository or an acquired team inherits platform defaults rather than your policy. Most of the gaps we find in readiness work are not policy failures. They are scope failures, in a console nobody knew existed.

This is what makes provenance a governance problem rather than a technical one. Nothing about the difficulty is unsolved: the records are trivially cheap to generate at the moment the code is written and effectively impossible to reconstruct afterwards. The failure is one of anticipation. Teams instrument what they are measured on this quarter, and nobody is measured on being able to describe 2025 in 2027.

There is a second, quieter reason to keep the record, and it points the other way — towards what you own rather than what you owe. The United States Copyright Office’s registration guidance on works containing AI-generated material, published in the Federal Register in March 2023 and reinforced by its 2025 report on copyrightability, holds that material generated without sufficient human authorship is not protectable, that only the human contribution to a mixed work is in play, and that an applicant must disclose AI-generated material that is more than de minimis and describe the human contribution. That is a disclosure obligation resting on a factual claim about how a work was made. The organisation that kept a record can make it. The organisation that did not is guessing on a government form.

Framed that way, provenance stops being defensive paperwork. It is the same artefact that answers a buyer’s questionnaire, supports a registration, satisfies an indemnity condition and lets you scope a remediation to the four repositories it affects rather than the whole estate. It belongs beside your AI system inventory, not in a separate initiative.

Two of these deserve emphasis because they are the ones teams skip. The configuration state with dates is the field that converts a vendor commitment into something you can rely on, and it is the field that expires: platform audit-log retention is a plan setting, commonly ninety days, while the question you will be asked arrives at a diligence horizon measured in years. Export it on a cadence into storage you control. And the commit-level marker is worth having precisely because it is cheap and declarative — a trailer the author adds at the moment they are the only person who knows the answer. It is not a percentage, it will not be perfectly applied, and it is still the difference between scoping a review to eighty commits and scoping it to a codebase.

What the record deliberately omits is as important as what it holds. It does not attempt to measure how much of a diff a model produced, because that number is unstable, unverifiable and would invite exactly the surveillance instrumentation this design avoids. It records that assistance was used, under which conditions, and that a human accepted the result.

Model and tool availability governance comes first because it is the only control that operates before anything is generated. Decide which tools may be used for code at all, on which commercial tier, and enforce it where software is actually acquired — identity provider groups, device management, and the expense policy that quietly funds the alternative. A personal subscription used on a work machine sits outside every contractual protection you hold, which is the practical link between this page and shadow AI: the licensing exposure created by a personal account is not merely unmanaged, it is uninsured.

Filter enforcement is second, and the word doing the work is enforcement. Set the policy at organisation level so it cannot be overridden per user, apply it to every organisation rather than the main one, alert on changes to the setting, and export its state on a cadence. The pattern is the same one that makes any configuration control testable: capture the setting at more than one point in the period and keep the audit log that proves it was not relaxed in between.

Dependency provenance is third and pays best. Publish a licence policy as code — permitted, prohibited, requires review — differentiated by how you deliver the artefact, then enforce it in CI so a non-compliant dependency fails the build rather than generating a report. Resolve installs through an internal proxy so a hallucinated or newly registered package cannot be pulled from a public registry on first use. Research presented at USENIX Security in 2025 found that a substantial minority of package names suggested by models did not exist at all, with rates varying widely by model and the same fabricated names recurring across attempts — recurrence being precisely what makes pre-registration worth an attacker’s time. The rate will keep moving. The control should not depend on the rate.

A bill of materials is fourth, and it is worth being precise about what it does. Generate an SBOM at build in SPDX or CycloneDX and retain it with the release. It answers the dependency question completely and the authorship question not at all: the recognised minimum elements — supplier, component, version, unique identifiers, dependency relationships, the author of the SBOM data and a timestamp — contain no field for whether a component was written with model assistance. Related work exists on describing AI systems themselves, including the AI and dataset profiles added in SPDX 3.0, but that documents models and datasets as components rather than recording that a human used an assistant to write a function. Give the SBOM for the dependency question and the provenance record for the authorship question.

The review gate is last on this list and first in importance, because it is the only control that engages with derivation. Branch protection requiring an approving review from somebody other than the author is already your change-management control. Nothing about AI assistance requires a second, parallel process. What changes is throughput and reviewer attention, which is a separate discipline covered under agent governance — and the honest position is that a reviewer will catch a recognisable implementation only if they happen to recognise it.

Nothing in this sequence is a failure of judgement. The company enabled the right setting on the right day, added dependency scanning before a customer forced it, and had a review gate throughout. It still could not answer two of three questions, for one reason: every artefact that would have answered them was held in a system that retained ninety days, while the question arrived at twenty-five months.

The nineteen-day gap is the second lesson, and it is the more common one. It was not caused by anyone disabling a control. It was caused by a new scope appearing — a second organisation, created for a legitimate reason, inheriting platform defaults rather than company policy. Any control expressed as a setting has this property. The countermeasure is not vigilance but a periodic reconciliation: list every organisation, every repository and every seat, and compare the actual setting against the policy on a stated cadence.

The Annex A controls that carry it are the life-cycle and accountability ones rather than anything IP-specific: an AI policy aligned with your other policies, AI roles and responsibilities, requirements and specification for AI systems, technical documentation, recording of event logs, processes for responsible use and intended use, and — for the supplier dimension — the allocation of responsibilities across third parties and the controls for suppliers. Annex A does contain a data provenance control at A.7.5, but read it for what it is: it governs the provenance of data used in AI systems, not the provenance of code an assistant helped a human write. Borrow the discipline, but do not claim the control.

The intellectual-property controls themselves sit in ISO/IEC 27001:2022, which is one reason an integrated AIMS and ISMS is the efficient shape. Annex A 5.32 requires appropriate procedures to protect intellectual property rights, and the standard’s treatment of the term expressly contemplates source-code licences and software copyright. A 8.28 covers secure coding and A 8.30 covers outsourced development, where the guidance already points at licensing agreements addressing code ownership. If you hold ISO 27001, you have a control that already obliges you to do most of this. What is new is the mechanism creating the risk, not the obligation.

Two boundaries to keep straight. On the EU AI Act, the copyright obligation in Article 53 — a policy to comply with Union copyright law including the reservation of rights under the text-and-data-mining provisions, and a sufficiently detailed public summary of training content — sits on providers of general-purpose AI models, applicable from 2 August 2025. It is not an obligation on you as a deployer. What it gives you is a due-diligence question with a documented answer behind it: ask for the training-content summary and the copyright policy, and keep the response. And on SOC 2, there is no trust services criterion for intellectual property. It reaches the examination only through change management, through vendor and business-partner controls where the assistant is the vendor, and through the accuracy of your own description. Saying so plainly is more credible than implying a SOC 2 report answers a licensing question.

A note on roles, since this page touches both regimes. Tranquility Cybersecurity advises, implements and coordinates: risk assessments, control design, policy and evidence, readiness. ISO 42001 certificates are issued by accredited certification bodies and SOC reports by licensed CPA firms. The firm that designs or operates your controls cannot be the one that examines them.

Related reading: the AI agent governance framework, the AI system inventory, use-case approval versus vendor approval, shadow AI, integrating ISO 42001 with ISO 27001, and the ISO 42001 hub.