Does AGPL Section 13 Apply to AI-Suggested Code in an Internal Web Service?

What Section 13 conditions on

AGPL-3.0 is built on the GPL, with an added network clause. Under the general terms, running a covered work without conveying it to others carries no source-sharing duty. Section 13 is the exception. In outline, if you modify the program, your modified version must prominently offer all users interacting with it remotely through a computer network an opportunity to receive the Corresponding Source of that version. The clause applies only where the version supports such interaction.

Read as engineering conditions, there are four to test: the code is AGPL-covered, your version is modified, the version supports remote network interaction, and there are users interacting with it. If any one fails, the source offer obligation does not arise under this clause. The licence text itself is the authority here, and any summary, including this one, should be checked against it.

Applying each condition to an internal web service

Covered work and modification. An internal service that merely runs an unmodified AGPL program differs from one where your team has changed AGPL code or written a service that incorporates it. Section 13 is framed around modified versions, so the first fact to establish is what AGPL code is in the service and what your team did to it.

Remote network interaction. A typical internal web service is accessed over a network by definition. Being internal, meaning reachable only from a corporate network or VPN, does not obviously remove the network element. The text turns on remote interaction through a computer network, not on whether the network is public.

Users. This is where internal deployment gets contested. One reading treats employees using the service as users interacting remotely, so the offer is owed to them. Another treats the organisation and its staff as one party, so no outside user exists. The licence text does not settle this for every employment, contractor, subsidiary or partner arrangement, and the answer may vary with who actually has access. Treat it as a question for counsel, not an assumption either way.

Where AI-suggested code adds uncertainty

The licence text does not mention AI assistants. The question that matters is factual and legal at once: does a given suggestion reproduce or derive from AGPL-licensed source, and if it does, does including it make the service a modified version of an AGPL work?

NIST AI 600-1 lists intellectual property as a generative AI risk, including easier replication of licensed content without authorisation, and notes that the status of generated output that resembles but does not strictly copy protected work is still being debated in legal fora. That debate is directly relevant. A verbatim reproduction of a substantial AGPL file is a different case from a short, common idiom or a structurally similar function, and the licence analysis may differ between them.

NIST SP 800-218A takes a useful operational stance: its practices do not distinguish between human-written and AI-generated source code, because all source code needs evaluation before use. The same logic suggests that AI-suggested code should go through the same licence review as any other third-party-influenced code, with provenance as an added input. The difficulty is that reviewers rarely have that input at the moment the code is written.

Code origin and licence evidence to capture at generation time

After-the-fact review depends on someone reconstructing where a snippet came from, which is often impossible once it sits in a commit. Capturing a record when the suggestion is produced is a design choice that moves part of the work earlier. Where to capture it, in the IDE, at an assistant gateway or at a proxy, depends on your architecture.

The record should support a reviewer who has never seen the suggestion. A withdrawn NIST draft pointed toward transparency mechanisms for tracking the origin of generated content, which is consistent with this approach, though it is not current guidance.

• Suggestion origin: the assistant, model and request context that produced it
• Any matched source, with its repository and licence identifier where a match exists
• Security context: whether the suggestion carries known vulnerability patterns or secrets
• The decision taken: accepted, modified, rejected or escalated, with a timestamp and identity
• A link from the suggestion record to the resulting commit or service

Runtime policy enforcement and licence review

A record of what was suggested is more useful when policy acts on it before the code lands. Trussed enforces policy in the execution path of coding assistants, with actions to allow, redact, block, rate limit or escalate for human approval, applied to individual interactions and tool calls. Its code provenance covers the origin, licence and security context of code. A suggestion whose provenance indicates a copyleft licence can be blocked or sent to a human reviewer, while routine suggestions proceed.

The enforcement decision and its context become audit-ready evidence, so a licence reviewer or counsel can see what was suggested and how policy handled it. This supports licence review. It does not replace it, and it does not determine whether Section 13 applies. That determination remains a legal judgement on the facts above.

Flagged findings should reach counsel before a service is released, and again before an internal service is exposed to external users, since that changes the user question materially.