Back to insights

AI & Automation

Before You Let AI Agents Run Your Failovers: A Governance Checklist

When AI agents handle disaster recovery, who takes the blame if something goes wrong? Intuit's new agent deployment reveals why governance, not speed, should…

Solis Automation Editorial
A transparent glass safe with visible internal gears and levers sits open, revealing a single brass key resting on a velvet cushion inside, while a hand pauses mid-reach toward it.

When your on-call engineer gets paged at 2 a.m. because your primary database region is down, every minute of manual failover costs money and sleep. The temptation to hand that playbook to an AI agent is obvious: faster recovery, fewer human errors, less 3 a.m. adrenaline.

But here's what keeps operations leaders awake after the incident resolves: if the agent makes the wrong call—fails over to a compromised region, skips a validation step, triggers cascading failure—who takes the blame? The engineer who typed "fix it"? The team that deployed the agent? The vendor whose model hallucinated a step?

This accountability gap is the real blocker for AI agents in production infrastructure. Intuit's recent deployment of an "EWOK Agent" for disaster recovery illustrates both the promise and the governance pattern that makes it viable—though the claims about its performance and safety come from Intuit and AWS's own account, not independent verification.

The Speed vs. Auditability Trap

Manual disaster recovery is slow and error-prone. Engineers follow runbooks, copy commands, wait for validations, make judgment calls under pressure. It's miserable but legible: every keystroke is attributable, every decision traceable to a human with a name and a manager.

AI agents flip this. An on-call engineer at Intuit can now request a production failover in plain language—no need to remember command syntax or navigate multiple systems. The technical barrier drops dramatically, which means more people can trigger infrastructure changes, including those with less deep system knowledge.

That's the governance complexity hiding inside the convenience. Lower technical barriers mean higher governance stakes.

What Intuit Did Differently

According to Intuit and AWS, their agent doesn't just execute—it enforces. Every action is audited, checked against policy, and constrained by safety guardrails built into the system. The agent can't wander outside its permissions or skip compliance steps because those boundaries are architectural, not procedural.

This matters because retrofitting audit trails after deployment is where most governance efforts die. By the time an incident reveals the gap, you're already in regulatory crosshairs or explaining yourself to your board.

Intuit's framing—that disaster recovery at scale has been historically hard due to complexity and risk—is worth sitting with. The problem wasn't that engineers lacked tools. It was that the tools demanded heroic effort and perfect execution under stress. The agent is positioned as a way to make the right thing the easy thing, but only because the governance was designed in from the start.

The Procurement Shift You Need to Watch

Vendors are already packaging "safe agent frameworks" as differentiators. This is moving fast from experimental to expected. If you're evaluating AI agents for infrastructure operations, you're now in the position of having to assess governance claims you may not have the internal expertise to verify.

The competitive pressure is real. When peers at comparable companies are running pilots, sitting out feels like accepting slower recovery times and higher error rates. But rushing in without matching governance investment trades one risk for another: instead of slow, auditable failures, you get fast, unexplainable ones.

Insurance carriers and regulators are watching. After an agent-initiated incident, "we didn't know it could do that" won't satisfy anyone. The question will be: what controls existed, how were they enforced, and where's the evidence?

What to Require Before Greenlighting

You don't need Intuit's exact architecture to apply their pattern. You need to verify that any agent handling production changes meets these conditions:

Mandatory human-in-the-loop for irreversible actions. The agent can prepare, validate, and recommend. Someone with authority and context approves execution. This isn't about distrusting the technology—it's about maintaining accountability chains that your organization, insurers, and regulators recognize.

Policy enforcement as architecture, not documentation. If compliance rules live in a wiki that engineers are supposed to follow, your agent will eventually find the edge case where the wiki is ambiguous. The constraints need to be code-level, not culture-level.

Immutable audit trails that capture intent, not just action. "Database failed over at 02:14" is insufficient. You need: who requested it, what they asked, what the agent interpreted, what alternatives were considered, what policy checks passed, and who approved execution.

Scoped permissions with no escape hatches. The agent should not be able to reconfigure its own constraints, escalate privileges, or operate outside its designated domain. This sounds obvious until you see how many agent frameworks are built with general-purpose tool access.

Failure mode transparency. When the agent can't complete a request, does it halt with a clear explanation, or does it attempt partial execution? The latter is how you get 3 a.m. pages about systems in inconsistent states.

The Honest Assessment

AI agents for disaster recovery are coming to your infrastructure decisions whether you're ready or not. The technical capability is already here. The differentiator—between a pilot that earns trust and one that gets shut down after an incident—is governance maturity.

Intuit's case, as they describe it, shows what's possible when governance is treated as a first-class requirement. But it's one company's self-reported implementation, not a standard you can adopt blindly. Your regulatory environment, insurance requirements, and internal risk tolerance may demand stricter or differently structured controls.

The practical next step isn't to build an EWOK Agent. It's to audit your current disaster recovery procedures against the governance requirements above, identify where your existing human-driven process already falls short, and use those gaps to inform what you demand from any agent vendor.

Speed without accountability isn't a feature. It's a liability that moves faster.

Before You Let AI Agents Run Your Failovers: A Governance Checklist | Solis Automation