From “Can This Scale?” to “Can This Survive?”
Why AI-enabled threats are changing how we think about diligence
In November 2025, Anthropic shared what may be the most significant cybersecurity development in the AI era so far: a large-scale attack in which their Claude model was manipulated into helping execute cyber intrusions, mostly on autopilot.
Roughly 30 organizations were targeted across sectors like tech, finance, manufacturing, and government. The attackers didn’t use jailbreaks or brute-force exploits. Instead, they did something quieter: they split malicious tasks into harmless-looking requests, posed as security researchers, and got Claude to perform 80-90% of the work with little or no human intervention.
Anthropic called it the first documented case of a major cyberattack carried out primarily by an AI system.
That’s a milestone. But more importantly, it’s a wake-up call. Because the scary part isn’t only the autonomy. It’s the ordinary-ness of the attack.
The requests didn’t raise red flags, the behavior didn’t look obviously malicious, and the surface-level system checks all passed. But underneath, the system was being manipulated.
The old way of thinking: Secure the perimeter
For decades, cybersecurity has revolved around protecting the perimeter. Firewalls, access control, antivirus, threat detection. Most diligence processes followed that logic, too: make sure the software doesn’t have obvious security holes, check compliance, assess tooling, move on.
But AI changes the shape of risk. The biggest threat isn’t always a breach. Sometimes, it’s the illusion of safety while a model or system is being used against you in ways you can’t immediately see.
The Claude incident marks a shift from one-time exploits to ongoing, adaptive threats, executed at machine speed and designed to blend into the background noise of a modern system.
A new kind of diligence question
At Kickdrum, we get called in to evaluate technology at critical moments:
During an acquisition
After a growth plateau
When a roadmap stalls
Or when the team starts losing confidence in their own systems
And lately, the question is starting to change. Where diligence used to focus on “can this scale,” we’re now hearing “can this survive?”
Can it survive the pressure of rapid growth without breaking?
Can it survive turnover without losing critical knowledge?
Can it survive scrutiny from regulators, enterprise buyers, or security auditors?
Can it survive a bad actor asking good questions?
Can it survive an intelligent system probing for its weak spots?
Resilience is a product and engineering issue
What makes these threats so hard to assess is that they often don’t live in the security tooling layer, but in the product itself.
A platform with an outdated permissions model
A critical service owned by one engineer who’s been threatening to leave
A monitoring setup that floods dashboards but misses the signal
A core process that relies on everyone “just knowing how it works”
An ML model integrated with little oversight into critical flows
That’s why resilience isn’t just a security question, but a product and engineering one.
Investors have to understand how the system is built, how the team works, and what really happens when something goes sideways. That’s how we approach diligence. Not just by checking the boxes, but by stepping into the real conditions the system is operating under, whether it be pressure, uncertainty, complexity, or increasingly, the presence of intelligent actors on both sides of the equation.
The bottom line:
The Claude attack should make it clear: Technical diligence needs to evolve. Not toward fear-mongering, but toward clarity.
We need to ask better questions, test under more realistic conditions, and stop pretending that legacy complexity is someone else’s problem.
Diligence isn’t just about scalability anymore. It is about survivability.
