Remediating AGPL-Licensed Code in a Production Service After an AI Coding Assistant Suggested It

Confirm the license finding before changing anything

Start by preserving the finding. Record the exact snippet, the file and commit where it entered, the author and merge date, and whatever the assistant session or pull request description says about where the code came from. Then identify the upstream file it matches, the license on that file and the license version that applied at the time of the match. Licenses can differ between files and between releases of the same project, so a match to a repository is not yet a match to a license.

Use more than one method. Software composition analysis is built around declared dependencies, so it can miss code that was pasted into a source file. Snippet-level matching finds pasted code, but modified, reformatted or partial snippets can fall below a match threshold. Git history analysis can show when a block appeared and how it changed, but it cannot say where the text came from. Treat each tool as evidence with known limits rather than as a verdict.

Bring counsel in at this stage. The AGPL's network-use provisions can create source-disclosure obligations for software that users interact with over a network. Whether that applies depends on facts such as whether the code was modified, how it is used and how users reach the service. Engineering supplies those facts. Counsel decides what they mean.

Choose a remediation option and accept its trade-offs

NIST's AI Risk Management Framework describes responses to AI risk as including mitigation or removal, supported by compensating, detective, directive and recovery controls. That framing fits here: the choice is rarely only technical.

Removal is the fastest path when the code is isolated, but it fails if the service depends on the behavior the snippet provided. Clean-room rewrite means engineers who have not seen the AGPL code implement the behavior from a written specification. It is slower, and anyone who reviewed the AI suggestion is a poor candidate to write it. The separation should be documented.

Replacement with a permissively licensed library is often the most practical. Verify the replacement's own license and its dependencies, and test for behavioral differences. License compliance, meaning releasing source under AGPL terms, or obtaining a commercial license from the rights holder, are business and legal decisions. Their scope and feasibility depend on the rights holder and on what else the service contains, so counsel should lead them.

Whichever option you pick, write down why. A short decision record that names the alternatives considered is more useful to an auditor than the fix itself.

Ship the fix without breaking the service

Handle the remediation commit like any other production change, with review and change control. Before replacing anything, write characterization tests that capture what the existing code does, so the replacement can be checked against real behavior. Run static analysis as part of the review.

Validate in a production-like environment, then roll out in stages with a canary and clear health criteria. Plan rollback deliberately. Reverting redeploys the affected code, so set a short limit on how long a rollback state is acceptable and have counsel's view on it.

A fix is not complete until the old code is gone everywhere you found it. Rebuild images, retire older versions that are still running, and rescan the result. Follow the incident-handling pattern of recovery: confirm the service is operating normally, then address the cause. Here the cause is an ungated path from assistant output into the repository.

Prevent a recurrence at the point of suggestion

Most of the difficulty in this runbook comes from missing records: nobody knew which snippets were AI-suggested, what license applied or when they shipped. Scanning in CI helps, but it runs after the code has been accepted. NIST AI RMF GOVERN 6.1 calls for policies that address third-party intellectual property risk from AI systems, and the most direct place to apply such a policy is where assistant output is accepted.

Trussed enforces policy in the execution path of coding assistants. Its code provenance supplies the origin, license and security context of code, so a license-risky suggestion can be allowed, redacted or blocked at runtime, not reviewed after the fact. Because enforcement itself generates audit-ready evidence, a regulated enterprise can trace a later finding to a specific suggestion rather than reconstructing it from history.

This complements existing SCA, SBOM and CI/CD gates and does not replace them or counsel's judgment. Keep those controls in place, and use runtime enforcement to reduce how often you need this runbook.