How Acquirers Assess AI-Generated GPL and AGPL Exposure in Code Due Diligence

Start with what the target can prove

A conventional code audit asks what is in the codebase. AI-assisted development adds three further questions: which code was produced with an assistant, what the assistant was permitted to produce, and whether output that resembled copyleft code was blocked or accepted. Many targets cannot answer these, because AI-generated code often has no recorded origin, no attribution and no licence context. That gap is what turns a licence question into a pricing question, since the acquirer cannot size exposure and must price the uncertainty through adjustments, indemnities, escrow terms or remediation conditions.

The starting principle is consistent with NIST's secure development guidance for generative AI, which does not distinguish between human-written and AI-generated source code because all code needs evaluation before use. Applied to licensing, the target should be able to show how AI-assisted code passes the same review as any other code. NIST also advises extending acquisition and vendor diligence for generative AI to cover intellectual property risk, which is the framing buyers apply to the tools a target relies on.

GPL and AGPL triggers differ, and the delivery model decides which matters

In general terms, GPL obligations attach when covered software is distributed to others. A target that ships installable software, embeds components in a product, or delivers code to customers for their own environments is exposed to the distribution trigger. A target that only runs software on its own servers and never conveys it may not trigger GPL source obligations through that use alone.

AGPL adds a condition aimed at that gap. Broadly, if modified AGPL-covered software is made available to users interacting with it remotely over a network, the operator may need to offer those users the corresponding source. For a SaaS target, AGPL-matching code in a network-facing service is therefore a different class of finding from GPL-matching code in the same service.

This is why acquirers map every finding to where the code runs: a customer-facing service, a distributed client or agent, an internal tool, or a build-time utility. Whether code is combined or derived in a way that extends obligations to proprietary components is a legal judgement for counsel. This guide is not legal advice.

What scanning can and cannot establish

Composition analysis is effective at finding declared dependencies and known snippets. AI-generated output stretches both capabilities. Generated code may reproduce, paraphrase or restructure existing code without attribution, so a clean snippet scan shows only that no match was found. It does not show that no copyleft-derived code was involved. A match, in turn, shows similarity but not how the code came to be there or whether the assistant's filtering was active when it was produced.

Source-level scanning can be supplemented with binary analysis, which helps verify the contents of what actually ships. SBOMs in standard formats make comparison easier to automate, but they list only what has been declared. None of these methods recovers the origin of code that was never recorded.

This is where recorded provenance and after-the-fact detection part ways. NIST notes that provenance tracking can record that content was generated or edited with an AI tool, and that the effectiveness of detecting synthetic text is subject to ongoing debate. For code, the practical reading is that a record made at the time of generation is stronger evidence than an inference drawn later from the finished artefact.

Where runtime enforcement and provenance records fit

The most useful evidence is generated when the code is produced. Trussed enforces policy in the execution path of coding assistants, applying allow, redact and block decisions to individual interactions and tool calls. It records code provenance, covering the origin, licence and security context of code, and produces audit-ready evidence as a by-product of enforcement. The policy is enforced at runtime, not reviewed after the fact, so a target can show what its assistants were permitted to do and what happened, instead of reconstructing it during diligence. Deployment is self-managed in the customer's cloud, with configurable retention and data residency.

For an acquirer, this changes the diligence conversation from inference to inspection. Records of enforcement decisions and provenance sit alongside scan output as a separate evidence layer. They do not replace scanning, and they do not cover code written before such records existed. Nor do they remove legal risk or settle how a licence applies to a given combination of code. They reduce uncertainty about what was produced and under which rules, which is the input counsel and deal teams need to size exposure, scope remediation and draft protections.