For two decades, cybersecurity had a familiar shape: human attackers probing for weaknesses,and human operators defending, patching, and responding on human timelines.
That world is gone.
Today, attacks run at machine speed. And the systems they're attacking are increasingly run by machines too. AI agents are logging into your SaaS apps, writing to your databases, and reconfiguring your infrastructure—autonomously, continuously, and often faster than any human can review.
This isn't a marginal shift. It's a change in the fundamental math of risk.
The New Math of Risk
A human attacker needs time: to gain access, move laterally, escalate privileges, and do damage. A human employee, even a careless one, is bound by the same limits. They can only touch so many systems, so fast.
AI breaks both sides of that equation. An AI-speed attack can compress a weeks-long intrusion into hours. An AI agent operating inside your company—the one you deployed to help—can execute thousands of actions before anyone notices something is wrong. The result is the same in both cases: 100x the damage, in a tenth of the time.
But the staff tasked to solve these problems cannot move at the same pace. That asymmetry changes the job.
You can no longer build a strategy around detecting and stopping every bad action before it happens. At machine speed, something will get through—whether it's an attacker or an agent that failed to do exactly what it was told. That means building an AI visibility strategy that considers internal AND external threats, unifying your agent observability function with your cyber resilience stack.
Your posture must adapt to the latest AI model, whether that’s Mythos or whatever comes next. You have to assume breach. And now, you have to assume agent overreach.
Assume Breach: Build the Recovery Foundation
Assuming breach means your first job isn't prevention, it's making sure that when something goes wrong, you can recover fast and with minimal disruption to the business.
That starts with coverage. Gaps in coverage aren't a minor risk anymore. Every critical application has to be protected and recoverable, whether it lives on-premises, in the cloud, or in a SaaS platform like Microsoft 365 or Salesforce. These gaps are vulnerabilities an AI-speed attack will find and exploit first, because it doesn't need a human to go looking for the weak spot.
Coverage alone isn't enough, though. When an attack unfolds at machine speed, what matters most is how fast you can find a clean recovery point and get back to business. This is your recovery time objective. A day of downtime used to be painful. But against AI-speed attacks, it's not something most businesses can absorb. The organizations that come through a breach as a brief interruption, rather than a catastrophe, are the ones that already know where their clean data is before the attack even happens.
That's the foundation. It's necessary, but it isn't sufficient anymore because the risk inside your walls has changed too.
Assume Agent Overreach: Rewind the Mistake
Inevitably, agents are going to overreach. Give an autonomous system enough access to be useful and eventually it will take an action nobody wanted: changing a critical M365 configuration, writing bad transactions into a production database, deleting an entire production instance because it misread its own instructions.
Solving for this requires three capabilities working together: discovery, runtime protection, and the ability to rewind an agent's mistakes.
Discovery answers a question most organizations cannot answer today: what are agents actually doing in your enterprise, right now? Agents arrive through IT, through developer tooling, and through employees who found something useful on their own. This inventory of agents is rarely one anybody writes down.
Knowing an agent exists is the beginning. What matters most is knowing what systems it can interact with and whether the things it can reach are recoverable if it makes a mistake.
Runtime protection is the layer that decides, at the moment an agent reaches for a tool or a system, whether that action is within scope. Where those calls run through a governed path, the decision happens before the action executes. That timing matters because not every agent action can be undone. A bad write to a database or a misconfigured setting can be reversed. But an agent that reads customer records and hands them to an external service has done something that no recovery process reaches. You cannot un-disclose it. The same is true of the email that went out, the payment that cleared, the record that was published. For that entire class of action, the only control that works is the one that applies before the action runs.
Runtime protection stands between you and the mistakes that cannot be taken back. Rewind is what you need for everything else. A year ago, we introduced Agent Rewind. At the time, it was a forward-looking bet on where agentic AI was headed. Today, as agents move from pilot projects into production systems with real write access, it's becoming a baseline requirement—the same way backup and recovery became a baseline requirement once ransomware moved from novelty to inevitability.
But rewinding an agent action for real (not just restoring a whole system and hoping for the best) requires answering three questions:
What did the agent actually do, and how do you tell its activity apart from everyone and everything else touching the system? Humans, other agents, and automated processes are all making changes at the same time. Without a clear causal chain—from the originating prompt, through memory state, to the specific action taken—you can't isolate what one agent did. Audit logs and telemetry record an API call, not the reasoning that produced it, so they can tell you a change happened but not which agent decision caused it. Reconstructing that lineage, prompt to memory state to action, is what makes the real roll back possible. Without this, telling one agent action from another (on a database, for example), is impossible.
Which of those actions were legitimate and which need to be undone? Not every action an overreaching agent takes is wrong. An agent might make 200 changes in an hour, 199 of them fine and one catastrophic. Treating all 200 the same way—keeping them all, or rolling them all back—is the wrong answer either direction.
Can you roll back only the unwanted changes without touching anything else? This is the hard part. A blunt restore that reverts an entire system takes out the good work along with the bad, and reintroduces the very downtime you were trying to avoid. What's needed is granular, surgical rollback—reversing the one bad write to a database table, or the one misconfigured setting—that leaves everything else intact. Zero data loss recovery isn't a nice-to-have here; it's the whole point.
The Two Assumptions, Together
Assume breach and assume agent overreach aren't separate strategies. They are the same discipline applied to two sources of the same kind of risk: fast-moving actors, human or artificial, operating inside systems you need to keep running.
The organizations that will handle the next decade of AI-driven risk well aren't the ones betting they can stop every bad action before it happens. They're the ones that have already built the ability to see everything that happened, tell the good from the bad, and put things back—fast, precisely, and without losing a thing along the way.
Ready to build resilience for both human and AI-driven risk? Learn more about Rubrik Agent Rewind or talk to our team about protecting your critical applications across on-prem, cloud, and SaaS with Rubrik Security Cloud.