There's a line making the rounds in security keynotes that stopped me.
"Every security tool and practice was designed with one thing in mind: that the attacker was human."
It's a compelling line. It's also wrong.
Botnets are decades old. Automated scanning, scripted exploitation, self-propagating worms, credential stuffing at machine speed. The overwhelming majority of attack attempts have been automated for at least a decade. A human has not been at the helm of most intrusion attempts since before many of the people in that room started their careers.
The reason it bothers me isn't the inaccuracy. It's what the inaccuracy reveals. When a vendor gets the premise wrong, everything built on that premise is suspect.
I've spent 20 years at the C-level as a CISO, CIO, and CTO, and I've learned to read the premise before I buy the conclusion.
The better argument
Here's the version of that claim that's actually true, and actually worth making.
For a decade, attackers have used every tool and automation available. Those tools were non-thinking, deterministic, and fragile. They followed scripts. They failed when the environment didn't match their assumptions. They required human direction to adapt.
AI changes that. AI adds reasoning and automatic investigation to what attackers could already do. An AI-assisted attacker doesn't just scan. It interprets. It adapts. It makes decisions. It reads your environment and updates its approach without waiting for a human operator to analyze the results and issue new instructions.
That's a meaningful change. Not because automation is new, but because autonomous reasoning is.
And here's the implication that actually matters: if AI makes attackers faster, smarter, and more adaptive, your ability to recover becomes more important, not your ability to prevent.
Prevention is still necessary. But prevention will eventually fail. Confident, fast recovery is now non-negotiable.
The threat detection question
Modern data-protection platforms keep extending threat detection scanning to AWS, Azure, and NAS environments, including AIX, Solaris, and Unix NAS systems. More coverage, more surfaces, broader detection.
Here's the question I'd ask before buying any of it: when a backup vendor's threat detection conflicts with your existing security tooling, which one do you trust?
You already have endpoint detection. You already have SIEM. You already have your primary threat detection stack, whatever that looks like. You're probably already drowning in alerts and dashboards.
Adding a backup vendor's threat detection layer doesn't reduce that noise. It adds to it.
The security company or the backup company? When your backup platform says something is clean and your endpoint vendor says it isn't, who wins? Where does the backup vendor's threat detection data live? Does it integrate with your existing security stack, or does it create another silo you have to check?
I'm not saying the capability is worthless. I'm saying the integration story is the thing worth evaluating, not the coverage list.
Threat detection built into a backup platform is useful when it either feeds your primary security tooling or surfaces findings your existing tools miss. If it's doing neither, you're paying for a second opinion from someone less qualified to give it.
The endpoint is back
Here's something the keynotes aren't saying, and somebody should.
The endpoint is re-emerging as a recovery target.
For years, we moved data to the cloud, to shared infrastructure, to centralized systems. Individual machines became less important as recovery targets because the valuable data wasn't on them anymore.
That's changing.
AI assistants are generating artifacts that live on individual machines. People have months of context in their AI conversations, their local AI tool configurations, their custom prompts, and agent setups. Professionals are building real intellectual property in their local AI environments, and none of it is in scope for most enterprise backup strategies.
When an employee's laptop gets encrypted by ransomware, the question isn't just "can we reinstall the OS." It's "can we recover the configuration, context, and intellectual property that lived in their AI tooling?"
For most enterprises right now, the answer is no. There's no policy for it. There's no technical solution in place. There's no one who's even been asked the question.
That's the AI recovery problem. Not the agentic infrastructure story. The unglamorous, urgent, already-happening problem: people are generating real IP in AI tools on their endpoints, and nobody is protecting it.
The FUD problem
The AI-in-security conversation is overwhelmed with fear, uncertainty, and doubt.
Vendors describe scenarios designed to make you feel unsafe rather than helping you understand what specifically changed and what you should actually do about it. The "attacker was human" claim is an example. It's crafted to create unease. It implies that everything you knew about security is suddenly obsolete.
Once you scratch the surface, you find that many of these vendors are not security companies. They're backup companies using security language to sell backup products. The gap between the fear they're selling and the protection they're actually offering is the thing worth examining.
That's not a reason to dismiss what they're building. Some of it is genuinely useful. But buy the capability, not the narrative.
The capability worth buying in 2026 is confident, fast, verifiable recovery. AI doesn't change that. It raises the cost of not having it.
A few specifics worth committing to:
- Enterprise IT leaders: Build your endpoint AI data protection policy now. Know what intellectual property your employees are generating in AI tools, and whether it's recoverable if their device is compromised.
- CISOs: Evaluate threat detection integrations, not threat detection features. The question isn't whether your backup vendor detects threats. It's whether that detection feeds your existing security workflow or creates a new silo.