Every year at the RSA Conference, SANS faculty take the keynote stage to name the most dangerous new attack techniques they have seen in the wild. It is one of the few sessions where the people running incident response and building the offensive tooling tell you, plainly, what is about to ruin your quarter. The 2026 edition, moderated by Ed Skoudis at Moscone Center, delivered a signal the panel had reportedly never sent before: for the first time, all five techniques carry an AI dimension.
Skoudis did not soften it. As recounted from the stage, his message was that there is no longer any meaningful trend in attacks that does not involve AI — that is simply where the industry is. That framing matters, because it is easy to read "AI" on a slide and tune out as marketing. This was the opposite — five working practitioners describing how the economics of attacking have already shifted under their feet. Here is the honest breakdown of each, and what actually helps.
1. AI-Generated Zero-Days: From Scarcity to Surplus
Joshua Wright opened with the technique that reframes the rest. Zero-days used to be scarce and expensive — measured in dollars, hoarded, traded. Wright's argument is that the unit of cost is changing: increasingly, the right way to price an exploit is how many tokens it takes an AI model to find a previously unknown vulnerability. When discovery becomes a compute problem rather than a talent problem, scarcity evaporates.
His framing stuck with the room: attackers were already faster than defenders, and AI threatens to make that gap unbridgeable at our current pace. The phrase "at our current pace" is the whole point. This is not a claim that defense is hopeless — it is a claim that defensive timelines built around human-speed patching no longer fit the threat.
Wright's defender recommendations were unglamorous and correct: accelerate every phase of the patching lifecycle, automate patching wherever you can, and bring AI-powered detection into the loop so your reaction time is in the same order of magnitude as the attacker's. If exploit discovery is automated and your remediation is a quarterly ticket queue, you have already lost the race.
2. Supply Chain Risk: Your Vendor's Vendor's Vendor
Wright also took the second slot, and this is the one closest to home for us. His framing, as relayed from the keynote: the problem of supply chain threats is not the software you choose, but your vendors' software and their vendors' software. The risk is not in your direct dependency list — it is two and three hops down, in code you never evaluated and cannot see.
The numbers the panel cited are sobering. Per figures referenced in the keynote, 65 percent of organizations experienced a software supply chain attack in 2026, and third-party involvement in breaches roughly doubled to 30 percent. The open-source registry picture is worse: more than 454,000 malicious packages were reportedly published to open-source registries in 2025, a roughly 75 percent jump over the prior year. SANS also pointed to a gap that explains why this keeps happening — a reported 79 percent of organizations run cybersecurity programs that cover less than half of their supplier ecosystem.
The defender guidance was concrete: plan for supplier compromise as a when, not an if. Demand verifiable proof of how software was built — provenance and attestation, not a vendor questionnaire taken on faith. And expand your definition of "supply chain" to include update channels and developer tooling, because those are exactly the paths attackers are automating against.
3. OT Complexity and the Root-Cause Crisis
Robert M. Lee took on operational technology, and his contribution was less about a single technique than about a structural trap. As industrial environments standardize on uniform controls, attacks scale more easily — the same playbook works across more sites. Layer AI on top and you get a new problem: it becomes genuinely hard to tell a cyberattack apart from a safety failure in these systems-of-systems, because AI adds a layer that obscures root-cause analysis.
Lee was blunt about the stakes, warning that it is realistic to imagine outages no one knows how to recover from in a reasonable amount of time — consequences that, in an industrial setting, can extend to loss of life. That is not hyperbole in an OT context, and it is the kind of thing that should reset how a board thinks about industrial monitoring.
His recommendations leaned on established, boring-because-they-work frameworks: implement the SANS ICS Five Critical Controls, adopt NERC CIP-015 monitoring standards, and stand up OT visibility before an incident — capture network traffic and command data so you can actually investigate later. You cannot do root-cause analysis on telemetry you never collected.
4. The Dark Side of AI in Forensics and Incident Response
Heather Barnhart delivered the most uncomfortable technique, because the "attacker" here is us. The danger is irresponsible use of AI in digital forensics and incident response — analysts feeding evidence into a model and shipping the output as findings. Her warning was direct: lean on AI to simply generate a report and you risk losing the credibility you have built across your entire career.
This is the failure mode that should worry every SOC adopting AI tooling. Hallucinated findings in a vulnerability scan waste time; hallucinated findings in a forensic report can sink a case or misattribute an incident. Barnhart's framing is that most breaches fail at decision points, and AI cannot be the decision point.
The guidance was specific. In forensics, AI is acceptable for identification and triage only — validation stays human-exclusive, and AI is never used for attribution. In incident response, broader AI integration is fine, but final decisions stay human-driven. Across both, maintain human oversight at every decision point. It is a useful, defensible line: let AI surface and organize, never let it conclude.
5. The Race to Autonomous Defense
Rob T. Lee closed on the only optimistic note, and even that came with a caveat. The fifth technique is really the defensive counterpart to the first: attackers have autonomous offense, so defenders need autonomous defense. As he put it, the adversary already has its artificial intelligence — now defenders have to build theirs.
The recommendations here mirrored the forensics panel — develop defensive AI agents, but use them to organize workflows and surface insights rather than replace human judgment. Maintain human validation and decision authority. The consistent theme across panelists, AI everywhere notwithstanding, was that the human stays in the loop at the moment of decision. SANS also pointed listeners toward community efforts to build defensive tooling together, which is the right instinct: no single vendor owns this defense.
How Safeguard Helps
The two techniques most aligned with what we build — AI-generated zero-days and the vendor's-vendor's-vendor supply chain problem — are exactly the cases where a single model is not enough. Safeguard treats the underlying AI model as a plug-in component beneath a verification and orchestration layer: our Multi-Agent TAOR Deep Think AI Engine runs findings through cross-checking agents to cut false positives, while AIBOM and ML-BOM, provenance and attestation, vendor scorecards, and policy gates push supply chain visibility down to the dependencies you never chose. The panel's repeated point — keep a human at the decision point — is the architecture, not an afterthought: reliability lives above the model. If you want to see how that holds up against your own dependency tree, reach out.