Topic starter
18/08/2026 2:09 pm
TL;DR: Leakage now follows repositories, pipelines, third-party integrations and AI coding assistants, according to Cycode. Development teams have to govern code, secrets and prompts across the full build surface, not only source control.
Editorial analysis by NHI Mgmt Group, based on content published by Cycode: “Intellectual Property Leakage: Risks, Detection, and Prevention”.
Key questions
Q: Why do leaked credentials make IP exposure more dangerous than code alone?
A: Code leakage becomes far more damaging when secrets are embedded in it because the attacker gets both the blueprint and the key.
Q: How should security teams handle AI-assisted coding as a leak vector?
A: Treat AI-assisted coding as part of the exposure surface because developers may paste sensitive context, accept generated code with embedded values, or reveal internal information indirectly.
Q: What breaks when source code is exposed through human error or compromised developer access?
A: When source code is exposed, defenders lose control over sensitive implementation details and may also expose credentials, internal APIs, and unpatched weaknesses.
Practitioner guidance
- Inventory every development system that can expose IP Map repositories, build systems, collaboration tools, AI assistants and external integrations that can carry source code, secrets or design material.
- Scan for secrets beyond the main branch Extend detection into commit history, pull requests, build logs, container images and pipeline configurations so deleted or hidden credentials are still found before attackers reuse them.
- Control AI tool usage as a leakage path Create an approved list of assistants and agents, block sensitive prompts where possible, and treat proprietary code pasted into unmanaged tools as a governance event rather than normal developer productivity.
Bottom line: IP leakage now follows the paths where software is built, shared and automated, which makes code, secrets and AI usage one governance problem.
Glossary terms: Intellectual Property Leakage, Secret-To-Access Conversion, Shadow AI, Third-Party Development Access
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
18/08/2026 3:02 pm
IP leakage is now a development-governance problem, not just a data-loss problem. Cycode’s analysis reflects a broader shift: the assets that matter most are now moving through repositories, pipelines, AI tools and vendor-connected workflows. That means security teams have to govern where intellectual property travels, not just where it is stored. The practitioner conclusion is that software delivery and identity governance now share the same blast radius.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: When should organisations review third-party access to repositories and pipelines?
A: Review it whenever vendors, contractors or automation no longer need standing access, and again after any change in project scope, ownership or integration design. Development ecosystems accumulate dormant permissions quickly, and those permissions become part of the exposure path if a partner account or connected tool is compromised. Least privilege only works when access is continuously revalidated.
👉 Read our full editorial: Intellectual property leakage now follows code, secrets and AI tools