Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Autonomous AI attacks have definitively moved from the research demos everyone's been awed by to standard operating procedure. For anyone paying enough attention, this is not necessarily news: the Five Eyes Alliance warned everyone back in June that AI will bypass cybersecurity in months, not years, with adversary breakout times that can now be measured in seconds. Gartner itself predicted something similar, expecting the window to exploitation to be cut in half as early as next year.

Applications can change several times between scheduled security assessments. New features, APIs, and integrations may introduce risk long before the next annual penetration test begins. That gap is pushing offensive testing beyond a single tool or a single point-in-time engagement. Teams are increasingly combining Dynamic Application Security Testing (DAST), AI penetration testing, and AI red teaming to evaluate different layers of application risk.

When we started thinking about how to surface AI model risk inside Evo, the obvious answer was to borrow from how we score everything else: find the issue, assign a severity, surface it. Done. The core of the new approach is a real risk score, built the way security teams already reason about risk: Likelihood × Impact. Likelihood comes from Attack Success Rate (ASR), the share of real adversarial attacks that succeed against a model. Impact is how much damage the attacker's goal does when it lands.

The Remediation Agent and Malicious Code Defense are the first two pieces of Evo Agentic AppSec: security that not only surfaces risk, but resolves it and prevents the next ones. This morning, we announced the broadest expansion of the Snyk AI Security Platform to date: discover, remediate, validate, and prevent. A loop with a missing segment is not a loop; it is a gap that an autonomous attacker will occupy. Evo Continuous Offensive Security closes validation and shipped today.

Building on our initial partnership that brought Snyk’s security intelligence into the Snowflake AI Data Cloud, we are taking the next step in securing the future of data-driven development. This new collaboration integrates Snyk Studio directly with Snowflake Cortex Code, ensuring that as organizations move their application logic to where their data lives, security remains an inherent part of the process rather than a secondary hurdle. Play Video: YouTube video 1.

A few months ago, I wrote that AI is building your attack surface faster than you can test it. I stand by every word I wrote then. But in the months since, after more than a hundred conversations with CISOs, CIOs, and CTOs across nearly every industry and geography, I've watched the picture get sharper, and a lot more urgent. The attack surface was only half the story, because the attacker profile has changed too.

Every so often, an industry gets a moment that quietly redraws where the line is — not because anything was said, but because something was proven. AI security had one of those moments last week, and it's worth being direct about that before getting into the details: this wasn't an incremental data point. It was the moment a risk that security and safety researchers had described in theory for years showed up, fully formed, in a disclosed incident report.

AI pentesting (AI penetration testing) is the use of reasoning-capable AI models to autonomously find, exploit, and validate security vulnerabilities in running applications — especially the context-dependent flaws, such as broken authorization and business-logic abuse, that traditional scanners cannot detect.

Here's a genuinely unsettling way to lose control of your laptop in 2026. You clone a normal-looking repo, ask your AI coding assistant to "set it up," and it writes an attacker's SSH key into your ~/.ssh/authorized_keys -- without ever really telling you that's what it did. No memory corruption, no zero-day, nothing clever. Just a file in the repo that wasn't the file it claimed to be. That attack is real, it's this week's news, and I'll walk through it. But the trick underneath is decades old.

We ran 300 vulnerability-finding scans to measure how repeatable an agentic LLM security review is on the same code, prompt, and harness. The headline result is not that one scanner "wins" a self-referential leaderboard. It is that LLM security findings are unevenly repeatable: reference-matched findings were stable, but extra-model reports varied widely from run to run.