AI coding assistants expose license risk beyond dependency scans

At a glance

What this is: FOSSA argues that AI coding assistants create open source license exposure through both generated snippets and agent-added dependencies that traditional SCA tools can miss.

Why it matters: Compliance teams and software owners need visibility into AI-assisted code generation and package selection, because licence obligations can enter the codebase before manifest-based review ever runs.

Context

AI coding assistants change where compliance risk enters the software lifecycle. Instead of arriving only through a deliberately added dependency, licence exposure can now appear in generated source lines or through agent-driven package selection before a human reaches a review gate.

This matters because conventional software composition analysis was built around manifests and lockfiles, not source-level origin analysis. In practice, that leaves a governance gap for legal, engineering, and platform teams when AI writes or selects code inside the development workflow.

Key questions

Q: How should organisations handle licence risk from AI-generated code?

A: They should treat generated code as untrusted until it is compared against known open source sources and checked for copyleft similarity. Standard manifest scanning is not enough because the risky material may never appear as a declared dependency. The governance model needs snippet-level detection and human review for matched content.

Q: Why do AI coding assistants create compliance and audit risk?

A: They create compliance and audit risk because they can generate code and process inputs outside traditional review paths. If organisations cannot show who used the assistant, what data was exposed, and how outputs were approved, they lose the evidence needed for audits, incident review, and regulatory accountability. The risk grows quickly when assistants are allowed near sensitive logic or regulated data.

Q: What do compliance teams get wrong about AI-assisted dependency selection?

A: They often assume the pull request is the first meaningful checkpoint, but an AI assistant or coding agent may already have chosen and installed the package earlier in the workflow. That means policy enforcement needs to start at selection time, not only at merge time. Otherwise the organisation reviews the record of a decision rather than the decision itself.

Q: How should legal, engineering, and security teams align on AI code compliance?

A: They should use one shared control path for generated snippets, human-written code, and third-party dependencies. Separate processes create blind spots because snippet review, package approval, and SBOM production can disagree about what is actually in the product. A unified workflow gives each team the same evidence and reduces late discovery during audits or disputes.

Technical breakdown

How generated code can inherit open source licence obligations

Code-generating models do not understand licence terms. They predict likely token sequences based on training data that may include public repositories governed by copyleft or attribution licences. When a model reproduces a distinctive fragment or a memorised sequence, the output can carry obligations that the developer never deliberately sourced. The risk is not that every AI suggestion is a copy, but that conventional review rarely has the evidence needed to tell when a suggestion is derivative. That makes provenance analysis a compliance problem, not just a coding-quality problem.

Practical implication: treat AI-generated source as potentially licensable content and check for origin, not just syntax.

Why dependency scans miss AI-assisted licence exposure

Traditional SCA tools inspect package manifests, lockfiles, and dependency graphs. That works when a package is explicitly added through a manager command and appears in a recognised inventory. It fails when an AI assistant pastes source code directly into a file or when an agent installs a package outside the normal human review path. In both cases, the compliance issue exists before the manifest-based control ever sees it. The control gap is coverage, not intent, which is why workflow location matters as much as licence policy.

Practical implication: extend compliance controls upstream into the editor, agent workflow, and source review layer.

How agentic package selection expands the compliance boundary

Conversational and agentic coding changes the decision point. The tool may decide that an open source package is the fastest solution and install it with little or no human involvement before code is committed. That creates a broader compliance surface because one dependency can bring its own licence terms plus transitive obligations. The issue is not only the package itself, but the fact that the selection and installation may happen before any engineer consciously evaluates policy. This shifts governance from post-addition scanning to pre-addition control.

Practical implication: gate package introduction and agent installation actions, not just the pull request that records them.

NHI Mgmt Group analysis

AI coding assistants have turned licence compliance into a source-level governance problem. The old model assumed that risky material entered software through visible dependency changes. AI-generated code breaks that assumption because it can embed copied or closely derived open source logic directly in source files, outside the manifest-driven control path. Practitioners should treat provenance as part of software governance, not an after-the-fact legal check.

Agentic development compounds the problem because the decision to add a package can now happen before human review. A coding agent can choose and install a dependency as part of solving the task, which means the organisation no longer controls the timing of policy exposure. That is a lifecycle issue for engineering governance, and it aligns closely with machine-identity style risk thinking: action is taken by a non-human actor inside a trusted workflow. Practitioners should move controls to the point of selection.

Source-level visibility is becoming the new compliance baseline for AI-assisted development. Manifest scanning still matters, but it is no longer sufficient when code can arrive through paste, prompt, or agent action. The named concept here is compliance blind spot drift: the widening gap between where modern code is introduced and where legacy controls still look for it. Teams should close that gap before AI usage becomes normalised.

Legal review and engineering control now have to operate as one chain. The article shows that snippet risk and dependency risk are not separate problems in practice, because both can land in the same branch and the same release. That means compliance policy, code review, SBOM generation, and developer workflow design need to be aligned rather than sequentially disconnected. Practitioners should design one control path for both human and AI-assisted code entry.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Compliance blind spot drift: AI-assisted development moves licence exposure upstream into places legacy SCA was never designed to inspect. That means the reader’s programme needs source-level controls, not just dependency governance, if it wants a reliable view of what is shipping.

The more autonomous the coding workflow becomes, the less useful a manifest-only compliance model will be. Teams should prepare for a world where the compliance decision is made before a human opens the pull request, which changes both policy design and evidence collection.

For practitioners

• Add source-level licence detection to the development workflow Scan function and expression-level code for likely open source origin, including AI-generated snippets that never appear in package manifests.
• Control package introduction before the pull request stage Review any dependency selected by an AI assistant or coding agent at the moment it is proposed, not only when it lands in a manifest.
• Unify snippet and dependency inventory Keep AI-generated code, manually written code, and added packages in one compliance inventory so legal review sees the full licence picture.
• Harden agent permissions for package installation Restrict which repositories, package managers, and install actions an autonomous coding agent can use without explicit approval.

Key takeaways

• AI coding assistants can introduce licence obligations through generated snippets even when no new dependency is added to the manifest.
• Traditional dependency scanning misses source-level code origin, which is why compliance controls need to move closer to the editor and agent workflow.
• Organisations should unify legal review, SBOM generation, and package approval so human and AI-assisted code follow the same governance path.

Key terms

• Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
• Source-Level Licence Risk: Source-level licence risk is the possibility that code embedded directly in application source carries obligations from an open source licence. It matters when generated snippets or copied fragments never appear as a separate package, because the compliance problem exists in the code itself rather than in dependency metadata.
• Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
• SBOM: A software bill of materials is an inventory of components, dependencies, and often transitive packages used in an application or build. It gives defenders visibility into what entered the software supply chain and helps spot risky or newly introduced dependencies.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the course if your programme is now being forced to govern non-human actions inside trusted development workflows.