As part of theCUBE Research’s AI Cybersecurity and Resilience Summit, which airs October 27and 28, we partnered with Qualitate on an in-depth study of 25 enterprise technology and security leaders. We wanted to understand how organizations are securing AI as it moves into production, how much authority they are giving AI agents, and whether their resilience practices are keeping pace.
The research exposed a significant gap between adoption and recovery readiness. Nineteen of the 25 leaders reported AI agents in production, yet only four had tested or exercised an AI or agent incident scenario.
That gap matters because an AI incident may look very different from a conventional technology failure. The infrastructure can remain available, the data intact, and the agent properly authenticated. An agent can use legitimate permissions to make a bad decision, execute it across several systems, and leave the business in a state no backup can fully unwind.
Protecting infrastructure and data is still foundational, but agentic systems create a new recovery problem. Organizations need to reconstruct what an agent did, trace the effects across systems and business processes, determine which resulting actions can still be trusted, and establish where the business can safely resume.
Most enterprises in our research are not yet prepared to do that. In addition to limited incident testing, organizations showed gaps in their ability to reconstruct agent activity, remediate changes across multiple systems, and establish a last known trusted state at the business-process level.

Legitimate agent activity can still produce the wrong outcome
One of the first problems is recognizing that an incident has occurred. Security teams look for compromised identities, malicious activity, policy violations, and other signs that something is wrong. An agent can be properly authenticated, use approved tools, stay within its permissions, and still create unintended risk.
Detecting anomalous agent behavior was among the least mature capabilities in our study. Twelve of 25 organizations had not addressed it or were not planning to. The underlying systems may continue operating normally while the agent changes a record, initiates a transaction, sends a communication, or triggers activity elsewhere.
Once the problem is detected, the organization has to reconstruct what happened, determine which systems and processes were affected, decide what needs reversal or remediation, and establish where operations can safely resume. One respondent said AI adoption will force the organization to revisit recovery time objectives, since AI-driven processes move faster and recovery will be more complex.
Few organizations have tested that sequence under realistic conditions. As agents gain authority, they can chain actions across systems much faster than people, creating downstream effects while detection, investigation and recovery are still underway.
Human approval is carrying the load
For now, organizations are leaning heavily on human oversight and control to compensate for gaps in detection, reconstruction and recovery. Human approval and bounded autonomy put a control point between an agent’s decision and higher-impact actions while the operational capabilities around those agents are still developing. People can review consequential actions before they occur, and organizations can limit the scope of activity agents are allowed to perform independently.
Among the 19 respondents with agents in production, none reported allowing agents to execute high-risk actions without human involvement. Eleven use bounded autonomy, allowing agents to execute lower-risk actions independently while requiring human approval for higher-impact activity. Eight require human approval for every action.
As agents take on more work, relying on people as the primary control point will become difficult to sustain. The speed and volume of agent activity will increase faster than the organization’s capacity to review individual decisions.
There is a lot of work to be done, but our research indicated some optimism. The bounded-autonomy organizations were more likely to report investment in logging, monitoring, and recovery infrastructure, and more likely to have exercised agent incident scenarios, than organizations requiring human approval for every action. In other words, organizations granting agents more authority may also be more proactive and further along in building the operational controls required to support it.
The kill switch only gets you to containment
Human approval can prevent an agent from taking some consequential actions, but organizations also need ways to limit activity when an agent is already operating independently.
Circuit breakers and automated shutdown mechanisms were among the capabilities respondents identified as priorities for the next 12 to 24 months. They can limit further activity, but they cannot undo actions an agent has already taken.
One respondent questioned whether the benefit of hitting a kill switch could be outweighed by the recovery effort or broken processes the intervention creates. An immediate shutdown may prevent additional actions while leaving transactions, communications, and downstream processes in different states.
Availability adds another consideration. One organization is building model fallback so users and business-critical processes can move to another model when the primary model is unavailable. But continuity does not resolve the effects of an agent’s prior actions.
Circuit breakers can contain activity. Model fallback can maintain availability. Recovery still requires the organization to understand and address the state left behind.
Agent identity and logging are recovery infrastructure
Once an agent is stopped, recovery depends on establishing what happened. That starts with knowing who, or what, took an action.
Agent identity is still immature across many of the organizations we studied. Respondents generally recognized the need for agents to have identities distinct from human users, but implementation ranged from planning to selected deployments.
Several said agents should operate through separate service accounts. One described the difficulty created when an agent inherits a user’s permissions: logs may show that an account made a change without making clear whether the user or the agent performed the action.
Teams investigating an incident need to identify the agent, the authority it held, the systems it touched, and the actions performed under that authority. Authorization and least privilege were more mature among respondents than agent identity and monitoring, but, while they can constrain what an agent is able to do, an agent can still stay within those constraints and make a bad decision.
Authorization and least privilege were more mature among respondents than agent identity and monitoring. Those controls can constrain what an agent is able to do, but recovery also depends on being able to distinguish the agent’s activity from the human identities and permissions around it.
Visibility gets harder as agents cross systems
Attribution is only the beginning. Organizations also need to reconstruct the sequence of activity as an agent moves across the enterprise.
Monitoring and reconstruction were among the least mature AI security capabilities in the study. Nine of 25 respondents were confident or partially confident they could reconstruct agent actions across systems. Eleven lacked confidence or acknowledged a gap.
Some organizations are strengthening their capabilities through changes to logging procedures, immutable storage, rollback, anomaly monitoring, and AI-specific incident playbooks. One more mature organization had tested separation among human, non-human and agent identities through penetration testing and red-team scenarios.
One of the most challenging tasks is maintaining visibility as an agent moves across endpoints, applications, model providers, networks and external services. One respondent described “so many disparate logs and audit trails” across those environments that getting to the core of what happened becomes difficult.
Another respondent who expressed confidence in reconstruction qualified it based on the limited blast radius of the organization’s current agents. Existing logging was sufficient largely because those agents could do very little damage. That calculation changes as agents gain authority and touch more systems.
Business-process trust is the largest recovery gap
Reconstructing what happened still leaves a harder question: can the resulting state of the business be trusted?
Only six of 25 respondents were confident or partially confident they could establish a last known trusted state at the business-process level. Sixteen acknowledged a gap or uncertainty.
Consider an agent that changes a customer record, initiates a payment, sends a notification, and starts another workflow. If the original decision proves wrong, restoring one application or rolling back one transaction does not resolve everything that followed. Some actions may remain valid, others may need reversal, and some may have triggered activity that cannot be rolled back.
One respondent described the desired capability as reconstructing exactly what an agent did across multiple systems, disabling it, reversing inappropriate actions, and proving to the business that everything is safe before resuming operations.
The scope of recovery now stretches across several layers:
Infrastructure → Data → Application state → Business-process state → Decision context
Infrastructure, application, and data recovery provide the foundation. Agentic operations add the need to trace actions and dependencies across the business process, determine which resulting states remain valid, and remediate those that do not. Identity and logging provide the evidence for those decisions, but they cannot make the trust determination themselves.
Some agent actions will require remediation, not rollback
Even establishing a trusted state does not mean every inappropriate action can simply be reversed.
Eleven respondents reported some capability to remediate agent-driven changes across multiple systems. Ten acknowledged gaps or significant difficulty.
Database changes can often be reversed, infrastructure and data restored, and some transactions offset with compensating transactions. Other actions leave effects outside the system where they originated. A customer communication that has been read cannot be unsent. Information disclosed externally cannot be undisclosed. A shipment may already be moving, and another agent may already have acted on the first agent’s output.
Recovery in those cases requires tracing downstream effects, stopping further propagation, determining which changes remain valid, and coordinating remediation across affected processes.
The reversibility of an action therefore needs to factor into how much authority an agent receives. Some actions can be rolled back, some require compensating actions, and some create effects that cannot be reversed.
Data protection and recovery remain central. They provide the ability to restore underlying systems and information, preserve trusted recovery copies and establish technical recovery points. Agentic recovery has to reconcile that technical state with the business activity that occurred around it.
Most organizations still have time to prepare
AI is not yet a critical operational dependency for most organizations in the study. Manual fallback remains available across most of the environments respondents described, although several expect that to change as AI becomes more deeply embedded in business processes.
That gives organizations a window to test agent failures while established processes and human expertise can still provide fallback, exposing gaps in detection, attribution, reconstruction and recovery before those processes become dependent on AI.
Test the whole recovery chain
Agentic recovery pulls identity, observability, data protection, infrastructure resilience, business continuity, and incident response into the same recovery process. Testing can show where that process breaks before agents become critical to the business processes organizations are trying to recover.
The priorities respondents identified for the next 12 to 24 months include stronger end-to-end monitoring, agent-specific reconstruction, circuit breakers, AI scenarios in continuity exercises, recovery requirements built into AI governance and onboarding, and operational capacity for incident assessment and remediation.
An important exercise would give an agent legitimate credentials and authorized access, then have it make a bad decision across several functioning systems. Teams would have to identify the agent, contain further action, reconstruct its activity, trace downstream effects, recover affected infrastructure and data where necessary, reverse or compensate for inappropriate actions and establish a trusted business-process state.
The exercise should test the recovery infrastructure itself. Logs need to remain available and trustworthy. Recovery data needs protection from alteration. Identity records need to preserve attribution. Teams need visibility across the systems an agent can touch.
Be sure to join us Oct. 27 and 28 for theCUBE’s AI Cybersecurity and Resilience Summit.
