Could You Recover If Your AI Agent Deleted Production?

If an AI agent with production access made a destructive mistake in the next hour, your recovery would depend on one thing: whether the credentials and procedures needed to regain control live somewhere the agent could not reach. Most teams have not checked. Agents are typically handed an operator's existing credentials or a long-lived service account, which means the agent's blast radius silently became the full permission set of whoever set it up — including, in many cases, access to the very secrets manager holding the emergency credentials.

Agents do not fail like people

The standard objection is that this is not new — humans have been running destructive commands against production for as long as production has existed. That is true about the category and wrong about the shape.

A human who deletes the wrong resource typically does it once, notices, and stops. There is a pause before the destructive step, a moment of hesitation that acts as an informal circuit breaker. Agents have no such pause. An agent operating in a loop applies the same reasoning to every resource it can enumerate, at API speed, and the interval between the first bad action and the hundredth can be shorter than your alerting threshold.

Confirmation gates behave badly here too. Asking an agent to confirm a destructive action is not the safety control it appears to be, because agreement is usually the most probable continuation of the exchange. A gate that a human would treat as a genuine decision point, an agent may treat as a formality. Safety has to come from what the credential can do, not from what the agent is asked before it does it.

Agents also fail in ways that are hard to reconstruct afterward. When a human operator causes an incident, you can ask them what they were trying to do. When an agent does, the reasoning may exist only in a transcript — one that is often stored inside the same system that is currently broken, and that may never have been retained at all.

The dependency loop nobody draws

Here is the diagram most teams have never sketched: the agent has credentials to your cloud account. Your secrets manager runs in that cloud account. Your break-glass credentials are in that secrets manager. Your incident channel authenticates through the identity provider that the agent can also administer.

Every arrow in that picture points back at the same failure domain. An agent that misbehaves inside that account is not just causing an outage — it is operating inside the recovery path. This is the same structural problem as hosting a break-glass tool on the cloud it exists to recover, which we covered in designing break-glass that survives a cloud outage. Agents make it sharper, because unlike a regional outage, an agent is an active participant that can keep making changes while you are trying to respond.

What actually reduces the risk

Three controls, in descending order of value:

1. Scope the credential, not the prompt. The most effective control is the permission set the agent holds. Give agents purpose-scoped, short-lived credentials rather than an operator's inherited access or a permanent service account. Instructions in a system prompt are guidance; IAM policy is enforcement.
2. Separate the environments. An agent with write access to staging and read-only access to production cannot delete production, regardless of how badly it reasons. This sounds obvious and is routinely skipped for convenience during setup, particularly for agents that started as read-only tools and accumulated write permissions over time.
3. Keep the recovery path outside the blast radius. Whatever the agent can reach, your emergency credentials must not be in it. Different cloud, different identity provider, different control plane.

The third is the one that survives the failure of the first two. Scoping is a judgment call that can be wrong; environment separation can be undermined by a single misconfigured role. An independent recovery path is what remains when those assumptions turn out to be false.

What independence means in practice

An emergency credential that meets this bar has a specific shape. It cannot be reachable with the agent's credentials, which rules out storing it in the same cloud account or the same secrets manager. It cannot depend on the identity provider the agent can administer. It should require more than one person to release, so that a single compromised operator account — human or automated — cannot unilaterally reconstruct it. And it should produce a tamper-evident record when used, because after an agent incident the first question from auditors and insurers is who accessed what, and when.

That is the model behind Glassbreak's break-glass access: credentials are split so no single holder can reassemble them alone, the split and reassembly happen client-side in the browser so plaintext never reaches a server, and the platform itself runs on independent cloud stacks so it does not share a failure domain with the systems it recovers. How it works walks through the mechanics.

The question to ask this week

You do not need an agent incident to test this. Take the credentials your agents currently hold and ask: if these were used destructively, right now, which of my recovery steps would still work? Trace each step to the account it depends on. Any step that resolves back to an account the agent can touch is not a recovery step — it is part of the same blast radius.

If you have not written the underlying procedure down yet, start with what a break-glass procedure is and the security architecture that a credible one depends on. Agents did not create the requirement for an independent recovery path. They removed the luxury of getting to it later.