How an OSPO Should Write an AI Coding Assistant Policy for GPL and AGPL Code

Treat the policy as a control, not a document

AI coding assistants can suggest code that resembles or reproduces GPL- or AGPL-licensed source. Developers can also paste copyleft code into prompts, or accept suggestions without knowing where the code came from. A static guidance document does not change either behaviour, and it leaves no record of what was allowed or blocked. The OSPO still has to show legal, security and audit stakeholders that the policy was applied.

Start by separating three things: what the licences require, what your policy chooses to specify, and what a mechanism can enforce. Licence obligations are for legal counsel to interpret. The policy turns those interpretations into operational rules. Enforcement is the mechanism that applies those rules to individual interactions. Keeping the three apart prevents the policy from restating licence text it cannot verify.

The first section to write is scope. List the assistants covered, including IDE plugins, chat interfaces, agentic tools and any assistant a team adopts outside procurement. Then list the use cases: autocomplete, code generation from natural language, refactoring, test writing and code review. Finally, state which repositories and projects are covered, and whether code that is internal only, distributed, or offered as a network service is treated differently. That last distinction matters for the next section.

Treat GPL and AGPL as different policy problems

GPL obligations are generally associated with distributing a covered work. AGPL adds obligations that can arise when users interact with the software over a network. A single generic rule such as 'no copyleft code' is either too broad to be followed or too vague to enforce. Have legal counsel confirm which licence versions the policy names and what each trigger means for your products, then express the result as decisions the policy can apply.

• Trigger to record: GPL: distribution of the resulting software. AGPL: distribution and also network use by users. The policy should record which deployment model each project has.
• Default outbound rule: Set by legal for each licence and deployment model. AGPL code often warrants a stricter default for any network-facing service.
• Inbound rule: Copyleft-licensed code in prompts and context needs a rule even when no code is distributed, because it can shape what the assistant returns.
• Exception owner: Name who may approve a use that falls outside the default, such as legal counsel or an OSPO review board.
• Version handling: State how GPL v2 and GPL v3 are treated, and do not assume they are interchangeable.

Write separate rules for inbound and outbound code, backed by provenance

Inbound rules govern what enters the assistant: prompts, open files, repository context and pasted snippets. A reasonable policy states which code classes may be sent, such as internal code, permissively licensed code and code of unknown origin, and which require redaction or approval. Copyleft-licensed code in context is the case to name explicitly.

Outbound rules govern what comes back: suggestions, generated files and tool-call results written into a repository. The policy should say what happens when a suggestion matches known code, when its licence cannot be determined, and when it matches code under GPL or AGPL.

Both sets of rules depend on code provenance: the origin of the code, its licence and its security context. The policy should require that provenance be available at the point of decision, not reconstructed later. It should also say what to do when provenance is unknown. Allowing unknown-origin code by default and blocking it by default are both defensible choices, but the policy has to pick one per project class.

Do not assume a detection control works because it exists. NIST AI 600-1 suggests policies for measuring the effectiveness of content provenance methods. The same discipline applies to licence detection: define how it will be tested, how often, and who reviews the results. Vendor-provided matching or referencing features should be evaluated against their documented limits and your own test cases before the policy relies on them.

Enforce at runtime and keep audit-ready evidence

Review after the fact means the code has already been suggested, accepted and possibly committed. Runtime enforcement applies the decision path above inside the execution path, on the prompt, the context and the generated output, before the result reaches the developer or repository. That is where an allow, redact, block or escalate decision can change an outcome. Controls that depend on pull-request review still have value, but they are a second line, not the enforcement point.

Evidence needs its own specification. NIST AI 600-1 suggests a retention policy that keeps history for testing, evaluation and content provenance methods, and after-action assessments of incidents, including statistics on actual policy violations. For an OSPO, that translates into a record for every decision: the tool and user, the rule applied, the provenance consulted, the outcome, any approver and the timestamp. Define the retention period, storage location and who can retrieve records. Record the results of detection tests as well, so effectiveness is demonstrable.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants, with outcomes of allow, redact, block, rate limit or escalate for human approval, applied to individual interactions and tool calls. Its code provenance supplies the origin, licence and security context of code, and enforcement generates continuous audit-ready evidence mapped to frameworks including NIST. It can be self-managed in the customer cloud, with configurable retention and data residency, which suits a regulated enterprise with strict requirements on where code and records reside.