Enforcing a Block on AGPL Matches from AI Coding Assistants at Runtime

Why runtime enforcement beats after-the-fact review

AI coding assistants can return suggestions that match code published under AGPL-3.0. That licence carries network-use copyleft obligations, which can conflict with proprietary or SaaS distribution models. The risk is not that a licence exists. It is that no one has evaluated the code before it enters the product.

Pull request review and periodic repository scans both act after the suggestion has already reached a developer workspace, and often after it has been committed. By then the code has been copied, edited and possibly merged with other changes, which makes it harder to trace and remove. A runtime block moves the decision to the moment of production, when the cost of refusing the suggestion is a single rejected interaction.

This follows a broader principle in NIST SP 800-218A, which treats the handling of model outputs as a control point and notes that AI models can be too complex to inspect thoroughly. If the model cannot be fully inspected, the practical place to apply control is the output. NIST's guidance concerns unauthorized code execution rather than licence matching, so applying it to AGPL is an architectural inference, but the logic carries over.

Step 1: Define the AGPL blocking policy

Write the policy before choosing tooling. A policy that cannot be stated precisely cannot be enforced consistently. Decide which licences are in scope: AGPL-3.0 only, or also other network-copyleft licences your counsel wants treated the same way. Counsel should own the licence position, while security and platform teams own how it is expressed as a rule.

Then specify the conditions that trigger each outcome. For example, a confident match to AGPL-licensed origin is blocked, a low-confidence or partial match is escalated, and a match to a permissive licence is allowed. Set explicit risk thresholds for what triggers review, in line with the SP 800-218A expectation that systems alert when activity passes a defined risk threshold. Threshold values are yours to set and should be tested against real suggestion traffic.

Assign named owners for policy changes, exception approval and evidence retention. NIST workshop notes on comparable AI development settings point to responsibility gaps between teams, and licence enforcement is exposed to the same problem. Apply least privilege to who can edit policy or approve exceptions, so the enforcement rules are themselves protected.

• Scope: which licences are blocked, and for which repositories or products.
• Triggers: the match conditions mapped to allow, redact, block or escalate.
• Ownership: who edits policy, approves exceptions and retains evidence.

Step 3: Handle partial matches, ambiguity and exceptions

Edge cases decide whether a block policy is workable. Partial matches are the first. A suggestion may contain a fragment that resembles AGPL code without reproducing a whole file. Decide in advance whether a match length or similarity score blocks outright, triggers redaction of the matched portion, or goes to review. Redaction is only appropriate where the remainder is still coherent and the policy permits it.

Licence ambiguity is the second. If the origin is known but the licence is missing, conflicting or unidentifiable, the safer default is to escalate rather than allow. Choose the default deliberately and document it, because it determines how often developers meet friction.

Approved exceptions are the third. A team may have a legitimate reason to use AGPL code, such as a project that is itself released under AGPL. Handle this with a defined approval path: a named approver, a scoped and time-limited exception, and a reference recorded against the later decision. Escalated items should go to a human with enough context to decide, including the matched origin, the licence signal and the policy rule that triggered review. False positives and negatives will occur, so track overridden blocks and reviewed escalations to tune thresholds over time.

How Trussed applies this pattern

Trussed enforces policy in the execution path across coding assistants, as well as models, agents, tools and MCP servers. For coding assistants, it uses code provenance, meaning the origin, licence and security context of code, to make allow, redact or block decisions at the level of individual interactions, and it can escalate for human approval where a policy calls for it. Enforcement happens at runtime, not after the fact.

Audit-ready evidence is generated by that enforcement, with mappings to frameworks including NIST, so the record of each decision is a product of the control rather than a separate reporting exercise. Trussed deploys self-managed in the customer cloud, with configurable retention and data residency. It has run continuously in production in a regulated enterprise for more than 18 months.

The steps above apply whichever tooling you use. What to test in any evaluation is whether the check sits before the suggestion reaches the workspace, whether exceptions are controlled and recorded, and whether evidence exists for every decision.