Intellectual property leakage now follows code, secrets and AI tools

At a glance

What this is: Cycode argues that IP leakage has shifted from a narrow exfiltration problem to a development-surface governance problem spanning code, secrets, collaborators and AI tools.

Why it matters: For IAM, NHI and security teams, the key issue is that leaked credentials, repository access and third-party exposure now sit inside the same workflow that creates software, so controls must follow the SDLC.

Context

IP leakage happens when proprietary code, secrets, designs or internal data leave the organisation without authorisation. In modern software delivery, that exposure is no longer limited to a stolen file or an insider copying a directory. It can occur through repositories, pipeline artefacts, third-party integrations, collaboration tools and AI coding assistants, which makes the control problem broader than classic data loss prevention.

The identity angle is real because much of the leakage path is credentialed. Repository access, API keys, service tokens and delegated third-party permissions determine whether a leak stays local or becomes a wider compromise. That means IP protection now overlaps with IAM, PAM, NHI governance and third-party access management rather than living only inside security engineering.

Most organisations still treat code, secrets and AI usage as separate governance domains, but this article describes them as one operating surface. That starting point is now typical for software teams and atypical only where development remains highly centralised and tightly controlled.

Key questions

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. Human error or compromised access can turn a simple repository mistake into a broader incident involving privilege misuse, lateral access, and disclosure of security gaps. The result is often a mix of IP loss, remediation work, and exploit risk.

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. A valid token, API key or password can turn a passive leak into active compromise, especially when those credentials still work across cloud or development systems. That is why validation and revocation have to happen as soon as exposure is detected.

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. Governance should cover prompts, generated output, and repository review together so the workflow is monitored end to end.

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.

Technical breakdown

Why repositories and pipelines become high-value leakage points

Source repositories and CI/CD systems concentrate the organisation’s most valuable development assets, so they also concentrate leak risk. A private repository flipped to public, a stolen token, or a misconfigured pipeline can expose both the code and the credentials needed to use it. The problem is not just disclosure. Git history, build logs and artefacts preserve sensitive material long after a developer believes it has been removed, which turns one mistake into a durable exposure window.

Practical implication: Treat repository access, pipeline permissions and artefact retention as one control plane, not separate hygiene tasks.

How AI coding assistants change IP and secrets exposure

AI coding assistants create a new leakage path because developers often paste proprietary code, configuration or credentials into prompts and context windows. That material may leave the organisation’s direct control even when the developer sees the interaction as routine debugging. The deeper governance issue is that AI usage is often shadowed, so security teams cannot easily inventory which assistants, agents or integrations are handling sensitive code. Once that visibility is missing, policy enforcement becomes guesswork.

Practical implication: Inventory approved AI tools and block the transfer of secrets and sensitive files into unmanaged assistants.

Why third-party integrations widen the blast radius

Third-party tools, vendor accounts and connected services extend the development trust boundary beyond the organisation’s own infrastructure. If those systems hold code, tokens or pipeline access, a compromise anywhere in the chain can expose proprietary assets even when internal controls are sound. This is an identity governance issue as much as a supply-chain issue, because delegated access, stale permissions and overbroad tokens determine how far a leak can spread. The failure mode is persistence of access after the original business need has passed.

Practical implication: Apply lifecycle control to vendor access, service tokens and shared development integrations.

Threat narrative

Attacker objective: The objective is to steal proprietary code, secrets and development context that can be monetised, reused for intrusion, or handed to a competitor.

1. Entry begins when attackers, contractors or careless users gain access through exposed repositories, shared credentials, compromised integrations or unapproved AI tooling.
2. Credential access follows when API keys, tokens, passwords or other secrets are harvested from code, configs, logs or prompts and then reused against internal systems.
3. Escalation and exfiltration occur when the exposed material reveals architecture, infrastructure or production access, allowing attackers to copy proprietary work or pivot further into connected environments.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Secrets exposure remains the most operationally dangerous form of IP leakage. A leaked repository is bad, but a leaked credential turns disclosure into immediate access. That is why the most important named concept here is secret-to-access conversion, the point at which exposed code becomes a working authentication path into internal systems. The practitioner conclusion is that leak detection and credential revocation must operate as one response path.

AI-assisted development has collapsed the old boundary between code creation and code exfiltration. Prompts, context windows and generated commits now sit in the same workflow as source control, which means security cannot treat AI usage as a side channel. Where AI tools are unmanaged, organisations are effectively blind to a new class of shadow access. The practitioner conclusion is to govern AI tool usage as part of SDLC identity control.

Third-party access is no longer a peripheral risk in software delivery. Vendor integrations, contractor accounts and shared developer tooling create an extended trust chain that can expose code even when internal controls look sound. This article reinforces that NHI and delegated access controls are now part of IP protection, not separate from it. The practitioner conclusion is to review who can touch code, tokens and pipelines across every external dependency.

Detection has to be contextual, not just signature-based. Cycode’s emphasis on fingerprinting, repository monitoring and anomaly detection reflects the reality that leaks are often ambiguous until they are tied to ownership and behaviour. Static scanning alone misses the operational context that tells you whether a finding is a harmless reference or an active exposure. The practitioner conclusion is to pair content discovery with behavioural and ownership signals.

From our research library:

• 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.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Secret-to-access conversion: the decisive governance failure is no longer the leak alone but the moment exposed code becomes a live credential path. That shifts programme priority from finding every possible copy of IP to ensuring that any secret discovered in code, logs or prompts is no longer usable as access.

AI-assisted development will force security teams to treat shadow AI as part of the software supply chain rather than a productivity side note. If organisations cannot inventory assistants, agents and IDE extensions, they cannot credibly claim to govern where proprietary code and secrets are travelling.

For practitioners

• 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. Assign an owner to each sensitive asset and each system that can touch it.
• 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.
• Tighten third-party access to code and pipelines Review contractor, vendor and automation access to repositories, tokens and CI/CD systems, then remove standing permissions that are no longer required for active work.
• Pair leak detection with credential revocation When exposed secrets are found, verify whether they are live and revoke or rotate them immediately so the leak does not become a usable access path.

Key takeaways

• IP leakage now follows the paths where software is built, shared and automated, which makes code, secrets and AI usage one governance problem.
• The most damaging exposures are the ones that combine proprietary material with working credentials, because disclosure becomes immediate access.
• Detection and prevention have to span repositories, pipelines, collaboration tools, third-party integrations and AI assistants, not just source control.

Key terms

• Intellectual Property Leakage: Unauthorized exposure of proprietary assets such as source code, design material, trade secrets, or internal documentation. In software environments, it often occurs through repositories, build systems, collaboration tools, or AI assistants, where sensitive information can leave organisational control without a traditional breach alert.
• Secret-To-Access Conversion: The point at which leaked source material becomes a usable authentication path because it contains live credentials, tokens or API keys. This is a critical failure mode in development security because disclosure immediately becomes compromise if the credential still works.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Third-Party Development Access: External contractor, vendor or integration access to repositories, pipelines, tokens and related development assets. It is a governance issue as much as a technical one because the attack surface depends on delegated permissions, account lifecycle management and offboarding discipline.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps identity, security and platform teams turn access control into a measurable operating discipline.