September 15, 2026
0 mins readFor the past year, I've described this as an AI fog: competing claims, uncertain risks, and leaders struggling to see what mattered. The winds are up now. AI is accelerating software creation, exposing years of accumulated vulnerabilities, and handing both attackers and defenders capabilities that operate at machine speed.
We used to call it fog. Fog rolls in, and it rolls out.
I've said for a year now that creation moved to machine speed and validation didn't, and that the gap between the two is where real risk lives. That diagnosis hasn't changed. What has changed is the cadence. The kind of severe flaw that AI now surfaces in widely used software, the sort of find that used to arrive once or twice a year and reset everyone's quarter, is landing several times a week in what I'm seeing. That isn't weather you can wait out.
It collapses into three problems: automated attacks moving faster than a human-speed backlog can absorb, agentic development that writes code and reaches for tools nobody vetted, and AI applications running in production with no inventory, no policy, no audit trail.
The hurricane is already here. Debating its speed will not weatherproof the application or infrastructure layers.
Meanwhile, the AI opera grows louder: civilization-ending predictions, dramatic warnings, competing demands to control who can build what. I've been in security a long time, through more than one of these moments, and I understand the instinct to tune it out as noise.
Don't. This is different.
Take the actual risk seriously, and scrutinize whether the proposed answers actually make us safer or just add another voice.
Independent scrutiny is the argument now
Dario Amodei just published "We Must Pace the Frontier," proposing that frontier labs slow capability advancement so safety work can catch up. Look at how he proposes to do it.
Anthropic is committing to embedded third-party evaluators with ongoing access to verify its safety practices. Separately, Amodei cites agents attacking systems outside their assigned task, including the system evaluating their performance. These raise different questions about oversight and control. For enterprise security, our architectural requirement is clear: the system creating a change must not be its sole validator.
CrowdStrike's George Kurtz picked up the thread with the practitioner's counterpoint: pacing what comes next doesn't secure what's already deployed. His read is that runtime is the real control point. The unit of threat today is an autonomous campaign, not a hacker, and every agent has to be treated as a privileged identity, enforced live, with proof instead of promises: board-level accountability, independent red teaming, incident disclosure, controls that hold in production.
George's runtime argument is essential. I would extend it into development: govern the agents doing the writing, the tools and MCP servers they use, and the code they ship. Development controls reduce the exposure we introduce; runtime controls constrain what deployed systems can do.
Otherwise, we're generating tomorrow's exposure faster than we can contain today's. And the rule holds at every layer: the system that generates the code, or proposes the fix, cannot be its own sole validator.
Three different starting points: a frontier lab, a runtime defender, and us, at the point where code and agents are created. That is not a joint platform. It is the same requirement showing up at three different layers: independent scrutiny matters at each layer, and cannot be assumed. The architectural claim past that point is ours, that the system creating a change must not be its sole validator. When people with the most to gain from saying "trust us" instead choose "verify us," that's not a talking point; that's confirmation.
Independence here is a technical property, not a branding one. It means the evidence is generated by something the producing agent cannot alter, and checked against controls outside that agent's reach: executed tests, data-flow analysis, observed runtime behavior. A second prompt, a second agent, or a second model is not independent. That is the same kind of judgment, asked twice.
The evidence isn't hypothetical anymore
A couple of weeks ago, I said the thing I was most worried about was not the sophistication of these attacks but the spread of them: that the capability was going mass-market, and soon a lot more people would be able to do this.
Eight days later, Anthropic's September report opened with the same finding in its own words: sophisticated attacks no longer require sophisticated attackers, because AI has collapsed the labor and tooling gap that used to separate state-sponsored operations from individuals. I would rather have been wrong.
The incident Amodei cites is one failure mode: agents leaving the task they were given. What follows is the other, and it's the one most organizations will meet first: people using these tools deliberately, at scale.
Anthropic's September report documents GTG-20006, a Russian state-nexus espionage actor by Anthropic's attribution, running an AI-assisted workflow that identified, modified, rebuilt, and redeployed its own implants after security products flagged them. The malware did not evolve on its own: a human directed it, and AI closed the loop faster than a new detection could be written and shipped.
The same report documents the AI supply chain becoming a target in its own right. A financially motivated actor injected malicious instructions into an AI vendor's automated evaluation sandbox and obtained the credentials that the sandbox held, including production API keys from that vendor's own environment.
Anthropic reports that its own systems were not compromised, and that the actor's attempt to reach a prerelease model failed. Stolen AI credentials buy an attacker three things at once: scale, someone else's compute, and someone else's name on the traffic. The AI supply chain isn't a future risk category, but an active one, today.
Closer to home: Snyk is a signatory to the collective cyber defense letter, alongside OpenAI, Anthropic, Google, Microsoft, Akamai, and hundreds of other organizations, warning that criminals could launch AI-driven attacks on critical infrastructure within months. As I told the Boston Globe, it's like knowing a hurricane is coming. Maybe you never fixed that window. Maybe your shutters are jammed. If you know it's coming next week, are you going to fix it or not?
Building for the storm
Secure at inception. Enforce at runtime. Validate independently.
Secure software at inception, catch what AI-generated code introduces, what packages it pulls, before it gets anywhere close to committing and shipping, not after.
Govern agents and their supply chains, as an agent with too much access and an unvetted tool is a standard attack surface now, not an edge case.
Continuously test and remediate, because a point-in-time pentest can't keep pace with a threat landscape that moves weekly. Continuous offensive testing, grounded in production evidence, is how you establish that specified controls hold against the attack paths you have actually tested. That's a narrower claim than "we're secure," and it's the only one worth making.
And independently validate what AI builds, the same discipline the industry is now converging on at every layer, applied to every line of code and every agent your teams ship.
None of this works if the findings just accumulate. Jason Clinton, Deputy CISO at Anthropic, put the operational half of it well when we announced our partnership: "In AI security, detection was never the bottleneck. By pairing Claude's capabilities with Snyk, enterprises can turn high-fidelity findings into action inside the workflows where software is built."
Open. Allied. Still standing.
The defensive layer has to stay broadly accessible. Open models, shared intelligence, and support for open source maintainers belong inside the safety architecture, not outside it.
Amodei's later steps call for coordination among frontier labs, and then among governments. That's a reasonable thing to propose, and it is not a plan to shut anyone out. My concern is about effect rather than intent: any arrangement that ends up concentrating the ability to build, inspect, and defend AI systems in a handful of labs becomes a single point of failure, whatever it was designed to be. Resilience that depends on trusting one vendor's roadmap isn't resilience. Judge every proposed fix, ours included, by whether it widens the set of people who can defend.
Some of this predates AI. We shipped software for forty years without holding ourselves to the safety discipline that other engineering fields treat as non-negotiable. We love to create, but we have never much loved securing what we create. AI didn't introduce that gap; it removed the time we'd been using to hide it, and it has added new risks of its own on top.
Preparedness is a leadership responsibility, and it starts with the part we choose.
Open. Allied. Still standing.
On September 17, I'm joining Alon Krifcher, Head of Applied AI at Anthropic, to walk through the four moves that close the gap between machine-speed attack and defense: discover, remediate, validate, and prevent. Save your seat today.
Ask your own agent
If you want to turn this into a conversation with your own team, hand the following to your agent. It won't tell you whether you're exposed, no public document can do that, but it will tell you what to ask.
Thursday, 17 September 2026 at 10:00am EDT
Webinar: How to prepare for the coming wave of autonomous attacks
Learn how to prepare for a new generation of AI-driven, machine-speed attacks, and what Snyk and Anthropic are actually seeing at the model and application layers.