Source Code in a Public Chat Window: The Most Common Trade Secret Leak of 2025

Source Code in a Public Chat Window: The Most Common Trade Secret Leak of 2025

A software engineer at Samsung pasted proprietary semiconductor source code into ChatGPT in early 2023 to debug an error. That incident became public, Samsung banned generative AI tools internally, and the rest of the industry collectively winced. Two years later, the same thing is happening constantly, just more quietly and at a much larger scale.

The Numbers Are Worse Than You Think

GitHub's 2024 survey on AI in software development found that 92% of U.S. developers use AI coding tools in some capacity. That tracks with what Sourcegraph reported in its own 2024 Cody survey: developers are pasting code into AI assistants dozens of times per day. LayerX Security's 2024 Browser Security Report estimated that 6% of all data pasted into generative AI tools by enterprise employees contains sensitive information, with source code representing the single largest category of sensitive input.

CybSafe's Q1 2025 analysis of enterprise data loss events flagged AI chatbot interactions as the fastest-growing vector for inadvertent trade secret disclosure. Their data showed a 280% increase in AI-related data exposure incidents between Q1 2024 and Q1 2025. Cyberhaven's research, based on real-time monitoring of 1.6 million workers, found that 8.6% of prompts to AI tools contained confidential data, and source code accounted for roughly a third of those inputs.

These are not hypothetical risks. This is the current baseline behavior of knowledge workers across every regulated industry that writes or maintains software.

The Typical Fact Pattern

After reviewing publicly reported incidents and talking to compliance teams dealing with this, a clear pattern emerges. It almost always looks like one of three scenarios.

1. The Debug Paste

A developer hits a bug they cannot resolve. They copy a function, a module, sometimes an entire file into a public AI tool. The code contains proprietary logic, API keys, or references to internal architecture. The Samsung incident is the canonical example, but it repeats daily. The developer is not acting maliciously. They are trying to fix something before a sprint deadline.

2. The Refactoring Request

An engineer pastes a block of legacy code and asks the AI to modernize it or optimize performance. The input often includes business logic that constitutes a trade secret: pricing algorithms, risk models, matching engines, claims processing rules. In a February 2025 incident reported by a mid-market fintech (disclosed in an SEC 8-K filing but not naming the AI tool), an engineer submitted a complete proprietary trading signal algorithm to a public LLM for refactoring suggestions.

3. The Documentation Shortcut

Someone pastes source code and asks the AI to generate documentation, comments, or a README. This feels innocuous, but the input is the trade secret. And under the terms of service of most public AI tools, that input may be used for model training, logged, or otherwise retained in ways that compromise confidentiality.

Why This Is a Trade Secret Problem Specifically

Under the Defend Trade Secrets Act (DTSA), 18 U.S.C. 1836, and the Uniform Trade Secrets Act (UTSA) adopted in some form by 48 states, trade secret protection requires the owner to take "reasonable measures" to keep the information secret. That is the threshold question in every misappropriation claim. If you cannot demonstrate reasonable measures, you lose the trade secret designation entirely.

Pasting proprietary source code into a public AI tool with broad data retention and training rights is, in the eyes of most courts, the opposite of a reasonable measure. It is a voluntary disclosure to a third party without adequate contractual protections.

The Compulife Software Inc. v. Newman line of cases (11th Cir., 2020) reinforced that source code qualifies as a trade secret only when the owner maintains consistent confidentiality controls. In Epic Systems Corp. v. Tata Consultancy Services (W.D. Wis., 2016), the jury awarded $940 million (later reduced to $420 million) partly because Epic could demonstrate rigorous access controls over its source code. The flip side is obvious: if your developers are pasting that same code into public chat windows, your controls argument collapses.

The Restatement (Third) of Unfair Competition Section 39 is explicit that disclosure to others without a duty of confidentiality destroys trade secret status. OpenAI's terms of service for the free tier of ChatGPT, as of March 2025, state that inputs may be used to improve models. That is not a confidentiality agreement. It is the opposite.

The Regulatory Overlay

This is not only a trade secret issue. For companies in regulated industries, the same behavior can trigger additional problems.

• Financial services: FINRA and the SEC have both issued guidance (FINRA Regulatory Notice 24-09, June 2024) on AI governance, emphasizing that firms must control data inputs to AI tools. Source code for trading systems, risk models, or customer-facing applications may also implicate Regulation S-P and Gramm-Leach-Bliley data protection requirements if the code references customer data structures.
• Healthcare: If the source code processes, references, or contains PHI schemas, HIPAA's Security Rule (45 CFR 164.312) requires access controls and audit trails. Pasting that code into a public tool is a potential HIPAA violation independent of the trade secret issue.
• Defense: DFARS 252.204-7012 and the emerging CMMC 2.0 framework require protection of Controlled Unclassified Information (CUI). Source code for defense-related systems almost certainly qualifies. A public AI tool is not a FedRAMP-authorized boundary.
• Legal: ABA Model Rule 1.6 requires lawyers to make reasonable efforts to prevent unauthorized disclosure of client information. Law firms building or maintaining software that processes client data face the same exposure.

What Reasonable Measures Actually Look Like Now

Courts and regulators are going to start evaluating "reasonable measures" in 2025 with AI tools as part of the landscape. A policy that says "do not paste confidential code into AI tools" is necessary but insufficient. Written policies alone have never been enough under DTSA or UTSA analysis; courts look for technical controls, training, monitoring, and enforcement.

The companies that will maintain their trade secret protections are the ones implementing technical guardrails: DLP tools that detect and block source code in AI prompts, enterprise AI deployments with contractual data isolation, prompt logging and review for sensitive content, and AI tools that are architected from the ground up to keep proprietary data within controlled boundaries.

Acceptable use policies need to be paired with tooling that makes the compliant path also the easy path. If your developers have to choose between a frictionless public AI tool and a clunky internal alternative, they will choose the public tool every time. That is just human behavior.

How FirmAdapt Addresses This

FirmAdapt is built so that proprietary data, including source code, never leaves a controlled environment. The platform processes AI interactions within a compliance-first architecture where inputs are not used for model training, are not retained beyond the session scope defined by the customer, and are subject to configurable DLP rules that can flag or block sensitive content types before they reach the model. This means organizations can give their teams access to AI capabilities without creating the fact pattern that destroys trade secret status.

For regulated companies specifically, FirmAdapt maintains audit logs of AI interactions, supports role-based access controls aligned with frameworks like CMMC and HIPAA, and provides the documentation trail that demonstrates "reasonable measures" if trade secret status is ever challenged. The goal is straightforward: make the compliant tool the one people actually want to use.