Detecting GPL and AGPL Snippets in Cursor-Generated Code Before Merge

Why dependency scanning leaves a gap

Software composition analysis (SCA) works from declared inputs: package manifests, lock files and build metadata. It maps those entries to known components and their licences. That model fits code that arrives as a dependency. It does not fit code that arrives as text.

When an AI coding assistant writes a function into a file, nothing is added to a manifest. The output carries no attribution and no licence signal. If that function reproduces or closely resembles copyleft-licensed code, including GPL or AGPL code, a manifest-based scan has nothing to match against. The code looks like first-party code, and it is reviewed as such.

This is a different control problem from dependency management. The question changes from "which packages do we ship?" to "where did this block of code come from?" Older NIST material on software security tooling describes this idea as pedigree analysis: tools that scan software within an organization and highlight its original source, so licensing concerns can be resolved against a known project name and version. The principle carries over to AI-generated code, although a pedigree tool built for whole components should not be assumed to catch inline snippets. Test that against your own samples.

Detection layers and where each fits

Four approaches are commonly combined. Each covers a different part of the workflow and each has limits.

Snippet matching compares code text, often after normalizing whitespace and identifiers, against an index of known open source code with licence data. It works well for near-verbatim copies. It is weaker when the assistant has renamed variables or restructured logic, and its coverage is only as broad as the index behind it.

Similarity analysis and fingerprinting reduce code to structural or token-level fingerprints and score how close two pieces of code are. This catches modified copies that exact matching misses. The cost is that results are probabilistic. A score is a signal for review, not a finding of infringement, and short or idiomatic code will produce false positives.

Provenance metadata records origin, licence and security context for code when it is generated or introduced, rather than reconstructing it later. This is the most useful input for audit, but it only helps where the metadata is actually captured. NIST's generative AI guidance material lists metadata embedding and cryptographic hashes among content provenance techniques, as general approaches rather than licence-specific controls.

Pre-merge checks are not a detection method in themselves. They are the enforcement point where the other three run, typically in pre-commit hooks or in CI on the pull request. Placing the check before merge matches the principle in NIST CSF 2.0 (ID.RA-09) that the authenticity and integrity of software is assessed prior to use. Pre-merge checks also catch code regardless of which assistant or editor produced it, which makes them a sensible baseline.

Policy decisions and the evidence behind them

Obligations attached to GPL and AGPL code can differ depending on whether software is distributed or made available to users over a network. Which of those cases applies depends on how each product is delivered. That is a legal determination, not an engineering one. Platform teams should ask counsel to state the rule per product or repository type, then encode it as policy. Treat the detection output as input to that decision and not as the decision itself.

The decision record matters as much as the detection. A defensible record answers a few questions: what was detected, against which source and licence, who reviewed it, what they decided, and when. NIST code-signing guidance also recommends keeping a reviewed list of who can submit and approve code, and separating administrators from authorized submitters. Applied by analogy, the same discipline works for licence escalations: a defined approver list, reviewed periodically, with no self-approval.

False positives need an owner. Periodically testing detection processes, as general cybersecurity guidance advises, applies here. Sample dismissed matches, check that thresholds still reflect reviewer judgment, and record changes to the rules.

Where Trussed fits

Pre-merge checks catch code at the pull request. Trussed addresses an earlier point: the interaction between a developer and a coding assistant. Trussed enforces policy in the execution path of coding assistants, with allow, redact, block, or escalate for human approval applied to individual interactions and tool calls. Enforcement happens at runtime, not in a review after the fact.

Trussed also provides code provenance: the origin, licence and security context of code. That context gives policy something to act on. A policy can, for example, block output tied to a copyleft licence or send it for human approval, rather than leaving the question to a later review.

Each enforcement decision produces audit-ready evidence, which is mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency. Trussed has run in continuous production in a regulated enterprise for more than 18 months, and serves customers in insurance, pharma, healthcare and education.

This does not replace CI-level checks. Scope is per interaction and tool call, so a pull request gate remains a useful second control. Used together, the two give a regulated enterprise one policy decision at generation time and another at merge, each with its own evidence.