AI Coding Assistant SSPL License Detection: What Filters Cover and What to Add

How license filters and reference trackers work

A public code filter and a reference tracker are related but distinct controls. A filter acts before or at suggestion time: output that resembles known public code is suppressed or flagged. A reference tracker acts alongside the suggestion: it surfaces the matched source and license so a developer can decide what to do. Both depend on the same underlying mechanism, which is a comparison between generated output and an index of known code.

That mechanism has four variables that determine what is actually caught. The first is the indexed corpus: code that is not in the index cannot be matched. The second is the license taxonomy: a match is only useful if the system maps the matched source to a license, and a license outside the taxonomy may be recorded as unknown or not reported at all. The third is the match threshold, meaning how much of a suggestion must resemble indexed code before it counts. The fourth is the matching granularity, snippet versus file, together with how the tool treats code that has been renamed, reformatted or paraphrased.

None of these variables is visible from the editor. A filter that is switched on tells you a control exists, not what it covers. Security engineers should therefore read a filter as a bounded, vendor-defined control and ask for each variable in writing.

SSPL as a test case for coverage gaps

SSPL is a useful probe because it is not a typical entry in a permissive or conventional copyleft list. Any detection system built around a fixed set of license identifiers can have gaps at the edges, and non-standard licenses such as SSPL are the kind of entry that may be missing, grouped under a generic label, or left unclassified. Older license analysis tooling worked from patterns of licenses and known packages, which implies a list that can be incomplete. The same logic applies to any pattern-based classifier today.

There are three distinct failure modes to separate. The first is a corpus gap: SSPL-licensed code is not in the index. The second is a taxonomy gap: the code is matched, but the license is not mapped to a restricted category. The third is a reporting gap: the match is classified but is not surfaced to the user or recorded anywhere durable. Each requires a different question to the vendor, and a single yes or no answer to "do you detect SSPL" will not distinguish them.

Until a vendor lists SSPL explicitly as covered, treat coverage as unknown rather than assumed. Silence is not evidence of detection. Whether SSPL terms are acceptable for a given use is a legal determination for counsel, not a scanner setting.

Vendor-native filtering compared with enterprise-defined enforcement

The two approaches answer different questions. Vendor-native filtering reduces the chance of obvious public code reproduction within the limits the vendor sets. Enterprise enforcement applies your own policy to every interaction, whatever the vendor's filter does.

• License taxonomy: Vendor-native: set by the vendor and may not name SSPL. Enterprise-defined: set by the enterprise and counsel, with SSPL and other non-standard licenses named explicitly.
• Scope of matching: Vendor-native: bounded by the vendor's index and thresholds. Enterprise-defined: policy applies to all code that passes through the path, including output the filter did not match.
• Action on a finding: Vendor-native: determined by product settings. Enterprise-defined: allow, redact, block or escalate, chosen per license.
• Where it runs: Vendor-native: typically inside the assistant or editor. Enterprise-defined: in the request and response path, so it holds across tools.
• Evidence: Vendor-native: depends on what the product exposes. Enterprise-defined: a durable record of origin, license context and decision per accepted suggestion.
• Change control: Vendor-native: vendor changes the behavior. Enterprise-defined: policy changes are versioned and owned internally.

Defining a runtime policy and evidence approach

Start by keeping the license taxonomy under enterprise control, separate from any vendor's filter. Define a custom list that names SSPL and other non-standard licenses, and assign each an action: allow, redact, block or escalate. The content of that list is a decision for the enterprise and its counsel. The engineering task is to make it enforceable.

NIST's Generative AI Profile frames the output-side expectation as reasonable measures to prevent, flag or take other action on outputs that reproduce licensed content, and as documenting the origin and history of generated data. It does not prescribe a mechanism or name specific licenses. Mapping "prevent, flag or take other action" to allow, redact or block decisions in the request and response path is a design choice, but a natural one, because that is the only place a decision can take effect before code reaches a developer.

Generation-time control is not sufficient on its own. SBOMs support license checks, and SCA tools use them for license and vulnerability review, but those methods work on declared components. A pasted or accepted snippet carries no package metadata, so decide explicitly how such snippets are recorded and reviewed downstream. Then test: run known samples under the licenses you care about, including modified and paraphrased variants, through each tool and through your enforcement path, and keep the results as baseline evidence.

Finally, record the origin, license context and policy decision for each accepted suggestion, and retain those records for audit. Pair this with internal acceptable-use terms for AI coding tools that state how license-restricted output is handled. NIST guidance is not binding law, and legal interpretation belongs with counsel.

Where Trussed fits

Trussed is one approach to the enforcement and evidence layer described above. It enforces policy in the execution path across coding assistants, models, agents, tools and MCP servers, with actions to allow, redact, block, rate limit or escalate for human approval. Enforcement is applied to individual interactions and tool calls, at runtime rather than reviewed after the fact.

Trussed also provides code provenance, covering the origin, license and security context of code, and generates audit-ready evidence from enforcement itself. It can be deployed self-managed in the customer cloud, with configurable retention and data residency. This sits alongside a vendor's native filter rather than replacing the questions you put to that vendor. It is intended for a regulated enterprise that needs to show what its AI was allowed to do and what it did.