Tabnine GPL AGPL Risk: What a Training Data Policy Does and Does Not Remove

What a training data policy can establish

A training data policy is a vendor claim about what went into a model. If a vendor states that its base model was trained on permissively licensed code and excludes copyleft code, that is useful input to a risk file. It tells a reviewer something about one source of exposure.

It is still a claim, and it describes the past. It does not tell a reviewer where a particular accepted suggestion came from, which licence governs it, or whether it resembles code under GPL or AGPL terms. NIST treats these as separate activities. NIST AI 600-1 recommends diligence on training data use to assess intellectual property and privacy risks. It also recommends red-teaming for output that reveals copyrighted, licensed, proprietary or sensitive information. Diligence on inputs and testing of outputs are two controls, and neither substitutes for the other.

A note on scope: NIST frames generative AI intellectual property risk in copyright terms, including where use of copyrighted works is not a fair use. It does not discuss open-source licences such as GPL or AGPL. How those licences apply to AI-generated code is a question for counsel, and this guide draws no legal conclusions.

Exposure paths a training data policy leaves open

The table separates the claim a training data policy makes from the paths it does not reach. Each path needs its own evidence.

• Output that resembles existing code: A model can produce code that closely resembles material it learned from. A statement about training sources does not show that a given suggestion is free of resemblance. Output-level testing and similarity or licence checks address this path.
• Customization on private repositories: If a customer enables tuning or customization on its own repositories, the licence profile of that code becomes part of the system. Private repositories often contain vendored or copied third-party code. The base model's policy does not describe this data.
• Third-party code in prompts and context: Developers can paste code into prompts or expose files as context. That code may carry GPL or AGPL terms and may be reflected in suggestions. The FTC has noted that customers can reveal confidential material to AI models, which supports treating this as a separate input path.
• Origin of an accepted suggestion: Even with a clean training claim, a reviewer cannot trace an accepted suggestion to a source or licence without attribution or matching evidence recorded at the time of use.
• Policy drift over time: Vendor documents, model versions and tenant settings change. A one-time assessment goes stale, and NIST MANAGE 3.1 expects third-party AI risks to be monitored regularly.

Controls a regulated enterprise can apply itself

NIST AI RMF MAP 4.1 calls for approaches to map the legal risks of AI components, including third-party data and software, to be in place, followed and documented. For a coding assistant, treat the base model, any customization layer and the runtime context sources as separate components and map each one.

Document the configuration actually enabled in the tenant, not the configuration the vendor describes in general. Define what developers may place in prompts or context, and state it as a policy that can be checked. Run output-level evaluation for reproduction of licensed material and keep the results, as NIST AI 600-1 suggests.

Finally, write a residual risk statement. AI RMF defines residual risk as the risk remaining after treatment, and MANAGE 1.4 expects negative residual risks to be documented for downstream acquirers and end users. The statement should say plainly what the vendor's training data policy does not address. Assign an owner, set a tolerance for licence exposure, and keep legal conclusions with counsel. NIST SP 800-218A covers cybersecurity risk only and says intellectual property risk should be managed alongside it within a broader enterprise risk programme, so licence evidence needs its own stream rather than relying on a secure development framework alone.

The tradeoff is effort against assurance. Manual reviews of pasted code and sampled output are slow, and they produce evidence after the fact. That gap is where controls at the point of use become relevant.

Where runtime enforcement and code provenance fit

This section describes one way to close the evidence gap and is specific to Trussed.

Trussed enforces policy in the execution path of coding assistants, scoped to individual interactions and tool calls. It can allow, redact or block based on code provenance, meaning the origin, licence and security context of code. For example, a policy can block a prompt that contains code with a restricted licence, or redact material before it reaches the model.

Because policy is enforced at runtime, not reviewed after the fact, each decision produces audit-ready evidence of what the assistant was allowed to do and what happened. That evidence is mapped to frameworks including NIST, which supports the MANAGE 3.1 expectation that third-party risk controls are applied and documented. Trussed can be self-managed in the customer cloud, with configurable retention and data residency.

This does not replace vendor due diligence or legal review. It produces the interaction-level record that a vendor statement cannot.