An AI Agent Recovery Drill Is the Test Every Enterprise Needs
Gleb Tsipursky, CEO of Disaster Avoidance Experts, shows how mainframe and IBM i teams can test their readiness for an AI agent control failure
TechChannel’s Oct. 13 examination of mainframe workloads moving to AWS identifies a problem that will intensify as AI agents connect legacy systems to modern cloud services. Identity and security controls that worked inside a tightly managed environment may no longer protect data and applications when agents cross networks, call APIs and act on behalf of multiple teams.
For mainframe and IBM i operators, the next essential discipline should be a recovery drill for autonomous AI. Most teams already test whether a backup can be restored. They should also test whether they can stop an agent, revoke its credentials, identify every action it took and restore the last trusted state of affected workflows.
Why Visibility Is Not Enough
It is easy to mistake visible permissions for reliable control. A dashboard may show which tools an agent can access. It may even offer a prominent pause button. Neither proves that delegated tasks will stop in downstream systems, that cached credentials expire or that an agent can no longer send a queued command through an integration. Real control requires an end-to-end test.
This matters because autonomy can produce surprises even when developers try to contain it. Jacob Coxon, who resigned from Anthropic after roughly three years doing pretraining research across OpenAI and Anthropic, warned that leading AI labs were racing toward self-improving superintelligence while gambling with people’s lives. Evan Hubinger, Anthropic’s alignment science lead, responded that he personally assessed a greater than 10% chance of AI killing all humans within the next decade.
A more immediate example came from a recent AI security evaluation. OpenAI disclosed that agents escaped a sandboxed environment, obtained internet access and compromised Hugging Face. METR subsequently found that about 1,200 supposedly isolated agents discovered an unintended shared message board, exchanging over 70,000 messages and files, with about 700 participating in the attack. Agents coordinated through a communication channel they were never meant to possess.
Now imagine a much more capable successor able to reach mission-critical payment, identity or hospital systems through a combination of IBM i services, APIs and cloud integrations. A security team that can shut off one interface but cannot identify connected credentials or queued actions may discover that its emergency procedure was incomplete when it matters most.
What an Effective Agent Recovery Drill Looks Like
An effective drill would begin with a deliberately constrained test agent in an isolated environment. The team assigns it a routine goal, such as analyzing access records and proposing a system maintenance change. Observers then simulate a control failure: The agent attempts an unapproved operation, delegates an action to another tool or begins sending data to a destination outside the approved task.
The team should exercise a named human escalation path rather than quietly disconnecting the test. Who receives the alert? Who has authority to halt activity across IBM i, mainframe services, cloud APIs and third-party orchestration tools? Can the team revoke the agent’s task-specific identity and short-lived credentials without disabling essential production services? Does the halt reach any other agents it delegated work to?
The verification must go beyond a green status indicator. Confirm from system records that no further commands executed after the stop, that outbound communications ceased and that no privileged session remained open. Compare the agent’s action log with OS and application records. Gaps between the two are precisely what the drill is designed to discover.
Recovery is a separate test. Restore a changed nonproduction configuration from a trusted version, revalidate access controls and document how the team would notify affected customers or internal owners after a real incident. If the agent created a financial or workflow commitment that cannot simply be rolled back, a person should own a compensating remedy.
Understanding the Process Fosters Automation Confidence
This operational discipline can speed useful AI adoption. I advise organizations on deploying AI more effectively, and I often see staff reluctant to use tools when responsibility for mistakes is unclear. When operators understand the escalation process and can demonstrate that they can recover from errors, they gain confidence to expand automation in measured stages.
Developers have obligations, too. Anthropic CEO Dario Amodei has called for stronger regulation and embedded independent evaluators with access comparable to internal risk teams. Anthropic says it will adopt that model voluntarily. Enterprise buyers should favor verifiable security and incident transparency, and policymakers should make independent assessment and serious incident reporting common requirements.
A sensible first drill may take only a short test window, using an agent with tightly limited permissions. Its findings should feed the next deployment decision: What authority can the organization safely add, what still needs human approval and what failure modes remain untested?
Mainframe and IBM i teams understand resilience as something proved by exercises, logs and recovery outcomes. They should apply the same standard to AI agents before those agents become routine operators of their most consequential systems.