Two stories from the past couple of weeks caught my attention.
Reuters reported that a hacker spent about $5,000 on AI tokens and unleashed a fleet of agents against more than 1,200 websites, compromising roughly 100 companies, including Deere, SharkNinja and Cummins. That’s approximately $50 per successful breach.
In South Korea, attackers reportedly used a Chinese state developed AI tool alongside Claude Code to target the banking sector, exposing information on some 68,000 people.
Think about those economics for a moment. Attacks that once required teams of skilled hackers, expensive tools and weeks of preparation can increasingly be carried out by AI agents running around the clock.
Demis Hassabis has called incidents like these early warning shots, suggesting we may have only a couple of years before something considerably worse.
That brings me to Veeam Software‘s October 15 Global Launch, which I followed closely. I also spoke with Rick Vanover on my podcast ahead of the event.
I’ve watched Veeam evolve over the years, and I think the company is making an important move here. For two decades, Veeam has been the company organizations turn to when systems fail, data disappears or ransomware strikes.
Now it’s asking a bigger question: What happens when AI agents start changing enterprise data faster than anyone can monitor, understand or recover it?
And how do you restore something when you don’t even know what’s been changed?
Three questions every CIO should be asking
Veeam CEO Anand Eswaran opened with a story from Spain.
A company reported a breach to its national data protection authority. The attacker wasn’t a person operating a keyboard or a conventional piece of malware. It was an AI agent operating largely on its own.
The agent scanned files for vulnerabilities, authenticated to an application, kept probing until it found an opening, and then modified personal information, invoices and billing records.
According to Anand, this was the first time a national data protection authority had formally identified an AI agent as the attacker.
Under GDPR, organizations generally have 72 hours to report a qualifying personal data breach once they’re aware of it. They need to establish what happened, the data affected and the likely consequences.
Anand boiled the challenge down to three questions:
- Which records changed?
- What did they change to?
- What were they before?
Simple questions. Try asking your IT, security and data teams whether they could answer all three after an AI-driven incident.
I’ve been putting that question to people, and most don’t have a convincing answer.
They might know an account was compromised. They might know an application was accessed. They might even know which agent performed an operation.
But reconstructing exactly what happened to the underlying data is another matter.
That’s the problem Veeam is trying to solve.
From backup to cyber resilience to AI resilience
I liked the way Anand described the evolution of the industry.
The first era of data protection was built around assuming failure. Hardware breaks, disks fail, people delete things. You need a backup.
The second era was about assuming breach. Ransomware changed the conversation from having a backup to having a clean, recoverable copy that attackers couldn’t destroy.
Now we’re entering a third era: assume drift.
And importantly, all three risks still exist.
Much of the AI security industry is focused on agent drift. An agent goes off course, follows an outdated instruction, accesses an unauthorized system or performs something nobody intended.
That’s a legitimate concern. But there’s another problem getting much less attention: data drift.
Data becomes outdated, is reclassified, gets exposed to the wrong model, is modified incorrectly or is deliberately poisoned.
An agent can have perfectly valid credentials, operate within its approved permissions and still produce a disastrous outcome because the data itself is wrong.
There’s also a fundamental difference in how long these problems persist.
Agents may be temporary. They can be created for a task, execute thousands of actions and disappear. The data they touched remains.
Six months later, when a regulator, customer or auditor asks what happened, the agent may be long gone.
The altered records won’t be.
Some of the numbers presented at the event were striking. Anand cited research showing that nearly half of organizations had experienced an incident involving unauthorized AI activity in the previous year, while only 5% reported clearly defined accountability across the AI lifecycle.
Veeam CMO Mika Yamamoto said more than 82% of enterprises have unknown AI agents operating in their environments.
Steve MacIntyre from Fidelity put the scale into perspective: large enterprises can have roughly 82 AI identities for every employee.
Imagine trying to govern that environment using traditional access reviews and manual audits.
Start with the data, not just the agent
This is where Veeam’s approach gets interesting.
Most AI security conversations start with the agent. What is it? Who owns it? What permissions does it have? Which tools can it access?
All necessary questions.
But what about the agents you don’t know exist?
The agent in the Spanish incident wasn’t in the victim’s inventory. You can’t enforce governance on an agent that nobody knows is operating inside your environment.
Veeam is approaching the problem from the opposite direction.
Start with the data. Understand where it resides, who or what can access it, how sensitive it is, what changed and what a trustworthy version looked like before the incident.
Then work backward.
Identity and security platforms tell you who did something and how they accessed a system. Data protection can help tell you what happened to the information itself and whether it can be recovered.
You need both.
Consider the Spanish company. Even if its security team had detected the agent immediately and revoked access within seconds, that wouldn’t automatically repair the corrupted invoices, billing records and personal information.
Stopping an attacker and fixing the damage are two different jobs.
Michael Cade from Veeam made another practical point at RSAC: organizations are still discovering accounts with effectively unlimited privileges in 2026.
We have a long way to go before enterprise AI governance is as mature as some vendors would have us believe.
A recovery point is not a recovery map
One of the more useful ideas from the launch was the distinction between a recovery point and a recovery map.
A recovery point tells you what you can restore.
A recovery map helps you determine what actually needs restoring, what was affected and what should remain untouched.
Traditionally, backup was about finding a good copy. Ransomware introduced the need to identify a clean copy and recover it quickly enough to keep the business operating.
AI adds another dimension.
What if an agent modifies 200 documents across Microsoft 365 while thousands of employees continue working on perfectly legitimate updates?
You don’t want to roll back the entire environment. You want to identify exactly which files and records were damaged, understand the dependencies and reverse the unwanted changes without losing everyone else’s work.
That’s considerably more complicated than restoring yesterday’s backup.
Veeam calls its approach Intelligent ResOps.
Anand was careful to explain that this isn’t a standalone product or another feature bolted onto the backup console. It’s a broader strategy built around the DataAI Command Platform, combining Veeam’s existing resilience technologies with data security, governance and AI context.
Securiti’s data security posture management technology is central to that approach.
Veeam Data Platform, Veeam Data Cloud and Kasten remain the underlying resilience engines. What changes is the visibility they gain across data, identities, access and activity.
For a company with a claimed customer base of roughly 550,000 organizations, that’s a significant direction to take.
The real question is how well all those pieces work together in production.
What customers discovered in their own environments
The customer examples were among the most convincing parts of the event.
Mika shared findings from early customers examining their Microsoft 365 environments.
One organization discovered that roughly a quarter of its 40-terabyte data estate had no business remaining in production.
Another found a birth certificate sitting in a shared operations folder.
In one Microsoft 365 tenant, the system identified 25 AI agents, two of which were actively modifying data.
The interesting part is that those customers weren’t necessarily looking for rogue agents. They were examining their data, and the agents became visible through that process.
Robert Davis, who runs IT infrastructure and operations at Construction Resources, a Home Depot company, made an important point.
Before you can confidently deploy Microsoft Copilot or other AI systems, you need to understand where your information came from, where it’s going and whether it should be there in the first place.
He also challenged the traditional attitude toward redundant, obsolete and trivial data.
We tend to treat ROT data as a storage expense or housekeeping issue. In an AI environment, it can become a compliance, security and legal problem.
His advice was refreshingly practical: Start running queries against your environment without assuming you already know what you’ll find.
You might be surprised.
David Robinson from Ontario’s Renfrew County Catholic District School Board described another benefit. Better visibility into how AI accesses Microsoft 365 data helps the organization confirm that sensitive information isn’t unnecessarily exposed.
That matters because AI governance isn’t just about preventing bad outcomes. It’s also about giving organizations enough confidence to adopt the technology.
And this isn’t limited to huge banks or Fortune 100 companies with enormous security budgets. School districts, local governments and midsize enterprises are dealing with the same issues.
What Veeam announced
Rehan Jalil, who leads Veeam’s product and technology organization, walked through the roadmap.
There was a lot to unpack, but several announcements stood out.
Intelligent ResOps for Microsoft 365
The product is moving into general availability as an add-on to Veeam Data Cloud for Microsoft 365.
The demonstration showed an AI agent with access to approximately 44,000 files, including sensitive information.
Administrators could see which files the agent accessed, modified or deleted and examine that activity through a timeline.
They could also restore a specific deleted item from a known good version rather than recovering an entire workload.
Preview customers reportedly connected their environments in just a few clicks and started seeing useful results within hours.
Google Workspace support is planned.
Veeam Data Platform integration
A private preview brings workloads protected by Veeam Backup & Replication into the same cloud management experience without moving the underlying backup data.
That means on-premises environments can remain on-premises while administrators gain centralized visibility, search across protected virtual machines and indexed files, selective recovery and proactive operational alerts.
There’s also an AI-assisted ability to generate audit reports through natural language requests.
I can see that being particularly useful for large, distributed IT environments where preparing a compliance report often requires considerable manual effort.
Identity resilience
Veeam is extending identity protection beyond Microsoft Entra ID and Active Directory.
Okta protection is in private preview, including immutable restore points across 29 object types and the ability to compare individual properties between live and known good configurations.
Restoration can include memberships, application assignments and roles, not merely the user or group object.
That’s important because restoring an identity without its relationships and permissions may still leave applications unusable.
Support for Azure IAM, AWS IAM and Google IAM is also on the roadmap.
Source code and development environments
GitHub protection is coming in private preview, covering branches, CI/CD pipelines, rulesets, issues, pull requests, wikis and permissions.
This is particularly relevant as AI coding agents become more common.
Agents can generate and modify code at a speed no human development team could previously match. One erroneous force push or compromised automation can create substantial damage.
The ability to protect repositories, restore configuration and test backed-up code using advanced cyber models without exposing live repositories is an interesting direction.
GitLab, Azure DevOps, Jira and Confluence are also planned.
Of course, roadmaps are roadmaps. The private previews, production capabilities and actual recovery performance will tell us much more than a launch presentation.
Fidelity offers a useful reality check
One of my favorite conversations was between Veeam’s John Jester and Steve MacIntyre, SVP of data protection, analytics and cloud security at Fidelity.
Steve made the case for treating data as a first-class enterprise asset rather than something that simply belongs to an application.
That sounds obvious until you examine how most organizations prioritize recovery.
We often build recovery plans around applications, servers and infrastructure. But those systems are of limited value if the underlying data is corrupted, inaccessible or untrustworthy.
Steve described data as a service that deserves its own place in the recovery order of operations.
He also emphasized limiting access to each dataset so a compromised identity or agent can’t affect the entire organization.
Smaller blast radius, smaller recovery problem.
And permissions need to be continuously reviewed, not approved at a governance meeting and forgotten for six months.
His message to vendors was equally relevant.
Enterprise customers don’t necessarily want another giant platform claiming to replace everything they already own.
They want vendors that are excellent at their core discipline and can work with the security, identity and infrastructure investments already in place.
I hear that sentiment frequently from CIOs and CISOs.
Integration matters. Nobody wants another expensive rip-and-replace exercise.
The real-world recovery stories
Kim LaGrue, CIO of the City of New Orleans, shared two incidents that put the entire discussion into perspective.
In one, a user with system administrator privileges clicked a phishing link. More than 2,500 desktops were compromised.
The city refused to negotiate with the attackers and rebuilt using clean data.
A recovery initially expected to take months was completed in less than 30 days.
Two years later, Hurricane Ida knocked out power. A fire involving diesel generators at City Hall contributed to an outage that took every nola.gov site offline.
Systems were restored within 48 hours.
Those are the stories that remind you why dependable backup and recovery still matter, regardless of how sophisticated AI security becomes.
Edwin Moraal, CISO of a Dutch public safety region, captured it well: If you cannot restore something, it’s a useless backup.
Analysts Steve McDowell of NAND Research and Fernando Montenegro of Futurum raised another important issue: selective recovery.
Undoing an AI agent’s changes sounds straightforward until another employee modifies the same document after the agent’s mistake.
Now you’re dealing with conflicts between legitimate and illegitimate changes. That’s a data integrity and merge problem, not merely a backup problem.
It’s precisely the sort of challenge that needs to be tested with real production workloads.
My perspective: We’ve seen this pattern before
I spent much of the 1990s working on paging infrastructure and the 2000s in VoIP and communications technology.
What we’re seeing now reminds me of earlier shifts in networking.
As systems became more distributed, software-driven and automated, the old operational controls stopped being sufficient.
We moved from managing physical switches and network connections toward managing sessions, services, identities and increasingly complex software environments.
Now AI is pushing us toward another shift, with data itself becoming an even more important point of control.
And there’s a major difference this time.
Traditional applications usually operate within reasonably predictable workflows. AI agents can make decisions, interact with multiple systems and execute actions at machine speed.
They can also make mistakes at machine speed.
That $5,000 hacking campaign is a good illustration of what’s changing. The economics are becoming extraordinarily favorable to attackers.
The South Korean banking incident is another warning that increasingly sophisticated AI tooling is finding its way into attacks against highly regulated industries.
Meanwhile, organizations are racing to deploy AI agents internally, often without a complete inventory of what those agents can access or modify.
I don’t think the answer is to slow down AI adoption across the board. Businesses are going to automate more processes, give agents more responsibility and connect them to more sensitive systems.
But we need the ability to understand what those agents actually did and recover when things go wrong.
That’s why I find Veeam’s move interesting.
Backup has always been about maintaining a reliable history of information. If you can combine that history with an understanding of identity, access, activity and data sensitivity, you have the foundation for something much more valuable.
Not just restoring systems after failure, but understanding the damage and rebuilding trust in the data itself.
I also think there’s a legitimate question about whether any single platform can provide the complete picture. Enterprises are complicated. Data is scattered across cloud services, SaaS applications, databases, code repositories and legacy infrastructure.
The integrations will matter enormously.
Rick Vanover made the point at RSAC that Veeam’s traditional audience has a highly calibrated BS meter.
He’s right. Backup and infrastructure professionals tend to be skeptical because they’ve lived through failed recoveries, broken promises and plenty of vendor marketing.
For this audience, polished demonstrations aren’t enough.
The technology has to work when an actual incident happens, under pressure, with real operational constraints.
What I’ll be watching
I think Veeam is making a smart bet, and it’s a meaningful evolution of its business.
But the most important measure of success won’t be how many agents a dashboard discovers or how many new integrations appear on the roadmap.
It will be whether organizations can answer those original three questions quickly, accurately and with enough evidence to satisfy their security teams, customers and regulators.
Which records changed?
What did they change to?
What were they before?
If Intelligent ResOps can turn those answers from a multiday forensic exercise into something an operator can reliably reconstruct and act on, that’s a real advance.
It also changes how we should think about backup.
In an AI-driven enterprise, simply having yesterday’s data isn’t enough. You need to know which parts of yesterday’s data you can still trust, what’s changed since, and how to recover without destroying legitimate work.
After more than three decades watching enterprise infrastructure evolve, I think that’s a problem worth paying close attention to.
The AI era is going to produce a lot more changes to enterprise data, intentional and otherwise. The winners will be the organizations that can explain those changes and, when necessary, undo them.
Veeam’s on-demand launch sessions are available through December 18. If you’re going to watch one, I’d recommend the Intelligent ResOps for Microsoft 365 deep dive.
