Topic starter
18/08/2026 2:17 pm
TL;DR: AI coding assistants are now embedded in everyday development, but FOSSA argues they also create open source license exposure through both generated snippets and agent-added dependencies that traditional SCA tools miss. The compliance problem is shifting from manifest review to source-level visibility, because obligations still apply when AI writes or selects the code.
Editorial analysis by NHI Mgmt Group, based on content published by FOSSA: “The Underappreciated OSS License Compliance Risk from AI Coding Tools”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: AI coding assistants can introduce licence obligations through generated snippets even when no new dependency is added to the manifest.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:10 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI coding assistants expose license risk beyond dependency scans