For many companies, the most valuable assets on the balance sheet are not the ones it fully captures. They are buried in source code, internal tooling, model harnesses, prompts, training pipelines, product roadmaps, proprietary datasets, design documents, and deployment logic. In the AI era, that reality has become sharper. Increasingly, the real enterprise moat is more than the model or the patent portfolio; it is the integrated system that distinguishes your business. Specifically, it is the code, the orchestration layer, the workflow logic, the data provenance, the operational know-how, and the internal controls that keep your intellectual property assets from becoming public commodities.
That is why the recent Anthropic incident deserves close attention from boards, chief legal officers, and executives responsible for risk management. As reported by PCWorld, a Claude Code release inadvertently exposed more than 500,000 lines of internal source code through a packaging or source-map error, and subsequent takedown efforts initially swept broadly before being narrowed. This incident was not just an embarrassing technical mishap, but a live demonstration of how quickly a release-control error can become an IP-loss event, a trade secret risk event, a regulatory and governance event, and a reputational event all at once. The right strategic response is not to conclude that leaks are inevitable, and enforcement is futile. Instead, the right approach is more demanding: companies need a disciplined operating model for protecting proprietary information before disclosure, and an equally disciplined playbook for containing, enforcing against, and remediating a disclosure once it occurs. In legal terms, the objective is to do more than just "send takedowns." The aim should be to preserve rights, reduce propagation, protect content and secrecy where still possible, maintain evidentiary integrity, and position the company for platform action, injunctive relief, contractual remedies, and (when necessary) copyright or trade secret litigation.
What the Law Actually Protects
The starting point is to recognize what the law actually protects. While code created by humans that contains creative expression is protectable under copyright law, it is important to note that source code that was largely "vibe coded" or created by an AI system (or agent) is not protectable expression under copyright law.
Importantly, content generated entirely by AI systems is generally not copyrightable absent human authorship, but human contributions such as selection, arrangement, editing, or refinement of AI-assisted outputs may still qualify for protection. See Thaler v. Perlmutter, 130 F.4th 1039 (D.C. Cir. 2025).
Next, under the Defend Trade Secrets Act, "trade secret" includes technical and engineering information, including programs and codes, but only if the owner has taken reasonable measures to keep the information secret and the information derives independent economic value from not being generally known. State trade secret laws have a similar framework. This matters enormously. If a company treats source code, internal prompts, system architecture, and unreleased product logic as casual engineering artifacts rather than classified enterprise assets, it weakens the very predicate for later trade secret claims.
Courts also increasingly require plaintiffs to identify alleged trade secrets with reasonable specificity, making early classification and documentation critical. See InteliClear, LLC v. ETC Glob. Holdings, Inc., 978 F.3d 653 (9th Cir. 2020).
So prevention begins with governance, not with a takedown notice.
Governance to Prevent IP Leakage
First, companies should maintain a trade secret and proprietary information inventory that does not merely say "our code is confidential." They should identify the categories of code, models, documentation, prompts, internal evaluation sets, deployment scripts, model harnesses, build artifacts, design docs, and commercialization materials that are treated as crown-jewel assets. Early trade secret identification is often outcome-determinative in litigation because courts increasingly expect plaintiffs to identify what the alleged trade secret actually is with reasonable specificity. A company that cannot quickly define the asset it is trying to protect will struggle in court and often on platforms (after discovering a leak) as well.
Next, access must be narrowed to genuine need to know. That sounds obvious, but it is frequently ignored in fast-moving product organizations. Source code and other high-value materials should not be sitting on a broadly accessible network drive or in lightly governed collaboration systems. Sensitive repositories, internal tools, and unreleased features should live in segmented environments, with role-based access controls, logging, approval gates, and periodic access recertification. In practice, many IP losses occur not because a company lacked a legal right, but because it lacked access discipline.
Third, release engineering must be treated as an IP-control function. NIST's Secure Software Development Framework (SSDF), set forth in Special Publication 800-218 issued by the National Institute of Standards and Technology (NIST), provides a structured model for integrating security and integrity controls into the software development life cycle. NIST also specifically points to verifying the integrity and provenance of source code and binaries. The implication for legal and executive leadership is important: release pipelines, artifact generation, source maps, debug packages, container images, and dependency manifests are critical legal risk vectors because they can disclose or propagate proprietary information at scale in minutes. It elevates the importance of provenance, integrity verification, and controlled release processes.
For that reason, mature organizations should require pre-release checks specifically designed to detect IP spill risks. Those checks should cover source maps, debug symbols, build manifests, embedded comments, internal URLs, package contents, open-source license contamination, secrets, credentials, internal prompts, and links to archives or storage buckets. In many companies, security reviews narrowly focus on exploitable vulnerabilities while overlooking disclosure vulnerabilities. A package that leaks unreleased source code may be "working as designed" from a functional standpoint while still failing catastrophically as an IP-protection matter. As reflected in NIST's Secure Software Development Framework (SSDF) Version 1.1 and CISA's software supply chain guidance, security and release-integrity controls should be integrated across the software development life cycle rather than treated as ad hoc exceptions.
Fourth, separate secrets from code and shorten the life of any credential that must exist. Even GitHub provides guidance on this: avoid hardcoding secrets; use environment variables or dedicated secret-management services; use least privilege; and rotate exposed credentials immediately if a leak occurs. GitHub's secret-scanning tools can scan repositories, history, branches, pull requests, issues, and more, and the company explicitly advises immediate credential rotation upon exposure. This is an important business-continuity safeguard. If leaked code also contains credentials, the event moves from being only an IP-loss matter to a more disastrous access-compromise event.
Fifth, train people like the company's moat depends on it, because it often does. Trade secret law repeatedly turns on whether the company acted reasonably to protect secrecy (see, e.g., Ruckelshaus v. Monsanto Co., 467 U.S. 986 (1984)). Our past articles have emphasized the value of confidentiality procedures, need-to-know restrictions, training, monitoring, and agreements with employees and partners. See Justin Pierce & Brandon Phemester, Trade Secrets Risk Exiting a One-Way Door When Data Is Fed to AI (Apr. 2026). And, in the age of AI-assisted development, this training must extend beyond classic confidentiality and include approved-model policies, prompt-handling rules, restrictions on copying proprietary material into external systems, and clear escalation rules for suspicious output or disclosure risk. Simply put, a company that approves AI use without redesigning its confidentiality training is not actually approving AI use responsibly.
Sixth, governance must extend beyond employees to vendors, contractors, and platforms. The leak path is often not theft in a cinematic sense. It is often a misconfiguration, a contractor mistake, an overbroad cloud share, a poorly controlled packaging step, or a partner workflow that quietly externalizes the company's proprietary materials. In our experience, document leaks and IP threats across supply chains indicate that many leak scenarios arise from ordinary collaboration rather than dramatic bad acts. That means the legal architecture should include strong confidentiality and IP-assignment terms, audit rights, prompt notice obligations, incident cooperation duties, return-and-destruction provisions, and restrictions on secondary use of the company's code, content, and data.
Seventh, build provenance and watermarking strategies where feasible. For software, that may include repository provenance, signed commits, signed releases, controlled build outputs, and markers that help attribute leaked artifacts to a source or workflow. For documents and presentations, visible copyright legends and internal classification labels can materially improve takedown posture. Platforms usually act more readily on provable copyright than on bare assertions of confidentiality. The practical implication is simple. If a company wants fast platform enforcement later, it should design its materials now to make ownership and unauthorized copying easier to prove.
How Your Company Should Respond
When a leak happens, the first principle is containment before commentary. The instinct to craft messaging is understandable, but the sequence should be: stop the spread, preserve evidence, assess scope, rotate exposed credentials, isolate affected systems, and determine whether the disclosure is continuing through automation, mirrors, caches, forks, or linked artifacts.
Companies should also consider early involvement of counsel to preserve privilege and assess contractual, insurance, and regulatory notification obligations.
Platform guidance generally advises immediate credential rotation upon detection of exposed secrets and provides separate removal mechanisms where disclosed credentials or similar data create a concrete security risk. For legal teams, the most effective response is typically parallel, with targeted platform reporting (e.g., copyright, trademark, or private-information channels) combined with internal technical containment and external forensic preservation.
Second, define exactly what was lost. This is where many response efforts become muddled. A company should quickly classify the leaked material into at least four buckets: (1) copyrighted material, (2) trade secret material, (3) credential/security-sensitive material, and (4) personal or regulated data, if any is implicated. Each bucket triggers different tools. Copyright supports platform takedowns. Exposed credentials support emergency rotation and, on some platforms, private-information removal. Trade secret status supports cease-and-desist demands, contractual claims, TRO strategy, and potentially litigation under the federal Defend Trade Secrets Act (DTSA) and analogous state Uniform Trade Secrets Act (UTSA) regimes. Regulated data may trigger notification obligations. One indiscriminate "please remove our confidential stuff" demand does not compare to the impact of a targeted, legally mapped response.
For public companies, this classification may determine whether disclosure is required under the SEC's cybersecurity reporting rules.
Third, move fast on platform enforcement, but be precise. GitHub's own takedown guide says notices must be as specific as possible. The Anthropic incident illustrates why. Overbroad notices can disrupt legitimate repositories, create backlash, dilute credibility, and invite counter-notices or public scrutiny. Precision matters not just for fairness, but for strategy. The best enforcement package usually includes exact URLs, specific files, clear ownership assertions, identification of the infringing material, and a tailored explanation of why the platform should act. Where credentials or other security-critical content is involved, companies should evaluate whether the platform's private-information removal channel is also available.
Fourth, do not confuse takedown with recovery. As courts recognize, widespread disclosure can extinguish trade secret protection entirely if secrecy is lost. That does not mean all value is lost; it means the objective shifts. The company is now trying to reduce propagation, preserve claims, prevent further use, identify the leak path, and protect adjacent assets that have not yet been commoditized.
Fifth, preserve your litigation posture from hour one. Under the DTSA, federal courts can issue injunctive relief, damages, and, in extraordinary circumstances, ex parte seizure orders to prevent propagation or dissemination of a trade secret. Those are powerful tools, but they require evidentiary discipline. The company should preserve logs, access records, release records, packaging artifacts, communications, screenshots, hashes, timestamps, and platform correspondence.
Sixth, pursue the human source of the leak where appropriate. The public may focus on the reposts, but the original disclosure vector often matters more. In the Twitter/GitHub source-code disclosure episode in 2023, the New York Times reported that Twitter not only sought removal but also petitioned the court to identify the alleged uploader. That remains an instructive model.
Seventh, conduct a parallel "rights triage" review across the rest of the stack. If source code leaked, what about prompts? Internal eval data? Embedded third-party code? Customer configurations? Internal API documentation? Roadmaps? Trade secrets in surrounding documents? AI-era systems are compositional. The leak may reveal more than the file list suggests.
Eighth, remediate structurally, not cosmetically. The board-level question after an incident should not be, "Who made the mistake?" It should be, "What class of control failed, and how do we make recurrence materially harder?" Frameworks like NIST SSDF provide a useful structure for this type of systemic remediation.
Next Steps for Any Company with Proprietary Code
- Maintain a defensible trade secret inventory
- Designate crown-jewel repositories and proprietary materials, and narrow access aggressively
- Separate secrets from code and reduce credential privilege and duration
- Deploy scanning across repositories, history, issues, and workflows
- Treat release engineering as a legal control point
- Ensure company materials carry ownership and confidentiality signals
- Pre-build a platform-enforcement packet and escalation tree
- Rehearse the first 24 hours of an IP-loss event before you ever need it
These measures may seem like overkill or overengineering, but in today's environment, they are a necessary part of competent enterprise stewardship of intangible assets.
Conclusion
The larger lesson is this: In an AI-driven economy, IP loss is more than a legal or information security problem. It is a challenge for management, systems design, and enterprise value preservation. The companies that will hold their edge are not the ones that innovate or produce more. They are the ones that operationalize protection, so that their code, content, data, and know-how remain both usable and defensible. When proprietary information escapes, the key question is whether the company has built a system capable of preserving and protecting that information in practice.