On 31 March 2026, Anthropic, one of the world’s leading AI safety companies, accidentally published the source code for its Claude Code command-line tool. A packaging error bundled a debug map file into a public npm update, exposing approximately 500,000 lines of code across nearly 1,900 files. Anthropic confirmed no customer data or credentials were compromised, but the leak revealed proprietary techniques and instructions at the heart of their AI coding agent.
This was not a sophisticated attack. No adversary breached their perimeter. A human made a routine deployment error, and as AI agents perform more work, these events will happen more often. A single missing control turned it into a public incident.
That distinction matters. Because if a company built entirely around AI safety, with the world class resources, talent, and incentives to get security right, can have a packaging error become a front-page story, the question for every other organisation is not “could this happen to us?” It already can, the only real question is: how ready are you when it does?
A Single Layer of Defence Is Never Enough
The Anthropic incident is a textbook case for security in depth – the practice of building multiple, independent security controls so that no single failure becomes a catastrophe.
Most organisations think about security as a perimeter. Keep attackers out, and you are safe. But the Anthropic leak did not involve an attacker at all. It involved an insider, following a normal process, making a human error. The perimeter was irrelevant.
Security in depth acknowledges this reality. Each layer operates independently, so a failure at one level, say application packaging, does not automatically compromise everything else.
| Layer | What it protects | Examples |
|---|---|---|
| Physical | Hardware and infrastructure | Access controls, surveillance |
| Network | Traffic and access points | Firewalls, intrusion detection, VPNs |
| Host | Servers, workstations, devices | Endpoint protection, OS hardening |
| Application | Software and deployment processes | Secure coding, release controls, security testing |
| Data | Information at rest and in transit | Encryption, access controls, data loss prevention |
The Anthropic failure occurred at the application layer – specifically in the release packaging process. A pre-release security scan of outbound npm packages, or an automated check for debug artefacts, could have caught it. That control was missing.
One absent control at one layer produced one very public incident. As we move to a more AI agents performing work, these layers will become even more important.
Preparation That Performs Under Pressure
Knowing the layers of a security framework is useful. Having a tested response plan is what actually limits damage when something goes wrong.
A crisis response plan (CRP) is not a document filed in a drawer for legal purposes. It is a practised capability. The organisations that navigate breaches well are not the ones who improvise better, they are the ones who have rehearsed this scenario until the response is automatic.
The core phases of an effective data breach response are:
Preparation. Establish an incident response team with defined roles before anything happens. Run simulations. Develop notification templates. Identify who has authority to make decisions at 3am. This is the only phase you have complete control over.
Identification and assessment. When a potential incident is detected, verify it, scope it, and understand what was affected. Good monitoring tools and forensic capability determine how quickly you move from suspicion to certainty.
Containment. Stop the spread. Isolate affected systems, revoke compromised credentials, pull problematic packages from distribution. Anthropic acted quickly here, the package was removed promptly once the issue was identified. Speed in this phase directly limits the impact.
Eradication and recovery. Find the root cause, not just the symptom. Patch the vulnerability, rebuild affected systems, and implement the control that was missing. A phased return to normal operations is preferable to rushing and missing something.
Notification and communication. Legal obligations around notification vary by jurisdiction and data type. Beyond compliance, how you communicate with affected parties – customers, partners, regulators – shapes whether trust survives the incident. Transparency and clarity matter as much as speed.
Post-incident review. Once the immediate crisis is resolved, the most valuable work begins. What failed? What worked? What needs to change in the process, not just the technology? A single incident, treated as a learning opportunity, should permanently improve the system. The same incident occurring twice is a signal that the learning did not happen.
Where to Start
The Anthropic incident is a useful prompt, but not because Anthropic is unusual. It is useful because the cause was ordinary: a human error in a routine process that a missing control did not catch.
That description fits most data incidents. Which means the most productive question to ask right now is not “what would we do if we were breached?” but “which of our routine processes has no independent control to catch a human or AI error?”
Start there, mapping the answer. Then build the control that is missing.
A crisis response plan is worth nothing if it has never been tested. Schedule a simulation. Find the gaps in your plan before an incident does.
The Anthropic team moved quickly to contain and communicate. That is what preparation looks like in practice. It does not prevent the human error. It determines what happens next.