Why Agentic AI May Join Security and Resilience Planning

A company in Spain reportedly told its regulator that an AI agent found a flaw in a live application and modified personal data and billing records. The SiliconANGLE guest column does not describe a completed restoration or establish exactly what the agent changed. Instead, it centers the questions responders would need to answer: which records changed, what they changed to, and what their prior state was. ¹

The argument is a useful prompt, not proof that every agent deployment carries the same risk. The practical work is to identify which agents can touch important systems, what evidence exists of their actions, and whether the organization can restore the right state without undoing legitimate work.

Why agentic AI security and recovery are converging

Security teams try to keep bad actors out; resilience teams focus on restoring the business after an incident. The column argues that agents bring these concerns closer together because they can act on data at machine speed. ¹ Zeus Kerravala’s column, published October 16, 2026, proposes “assume drift” alongside the older assumptions of failure and breach. ¹ Here, drift is a planning concern: an agent may alter data or system state over time. That does not mean every agent will, or that all deployments carry equal risk.

The Spain incident anchors the piece, but the column does not name the company or provide independent corroboration of the account. ¹ Treat it as a reason to ask recovery questions, not as evidence about how often agents cause this kind of damage.

Scope changes the assessment. An agent that drafts a reply for human review poses a different potential recovery problem from one with write access to production records. The column does not provide a detailed risk taxonomy by deployment type or permission level. ¹ One reading is that “uses an agent” is not a risk category by itself; what an agent can access and change matters.

What breaks when identity controls are the whole AI incident recovery plan

Knowing who—or what—was authorized to act is a security question. Knowing what state the data ended up in is a recovery question. The column’s point is that identity controls can address who may act, but do not restore what has already changed. ¹

Kerravala distinguishes a recovery point from a recovery map. A recovery point tells you what can be restored; a recovery map helps determine what changed, what to restore first, and what not to bring back. ¹ That reframes the question from “can we bring the data back?” to “can we bring back the right records without dragging unwanted changes along with them?”

This is where rollback can get messy. A broad restore could bring back unwanted agent changes alongside valid updates made in the same window. A narrow restore could leave connected records out of sync. These are potential operational failure modes implied by the recovery-map idea, not outcomes reported in the column. ¹ The practical move is to test, before an incident, whether the team can trace a change and make a selective restore decision under pressure. Errors that spread across chained agents are a related research problem; ARIA’s runtime repair proposal targets the error-propagation gap in multi-agent systems.

Which AI agent deployments to assess first

Prioritize by consequence, not by the presence of AI. A starting screen:

What to assess	Why it matters
Data access	Sensitive or business-critical data raises the stakes of an unintended change.
Write permissions	Modifying records creates a different recovery problem from reading them.
Connection to live systems	As an operational consideration, changes in production may affect dependent systems.
Ability to reconstruct prior state	Selective recovery depends on knowing what the data looked like before.

This table is a proposed assessment lens, not a model supplied by the column. The source raises questions about changed data, prior state, and selective restoration, but does not rank deployment patterns for organizations. ¹ A read-only or advisory agent may warrant a lighter recovery assessment than one that can write to live business records; that is an assessment choice for the organization to document, not an assumption to leave unexamined. For a checklist-style look at agent credentials and no-code builders, see what to check before turning on ServiceNow’s agent controls.

Unknown agents belong in the inventory too. The column cites Veeam’s Data Trust & Resilience Report 2026, which found that more than 82% of organizations had unknown agents in their environments. ¹ That is a vendor-reported figure; the excerpt does not provide the report’s methodology or sample. ¹ An inventory gap is grounds to investigate, not proof that an unknown agent is malicious.

Questions for AI security governance and recovery teams

These questions connect an agent’s behavior to a recovery decision:

• Can you identify which data the agent accessed or changed, including relevant connected data and systems? ¹
• Can responders reconstruct the prior state well enough to restore selectively? ¹
• Can the team choose what to restore and what to exclude, rather than relying on an all-or-nothing rollback? ¹
• Can the organization account for agents that never made it into the official inventory? ¹

Then assign ownership—a step the column raises but does not prescribe. Someone needs to declare an agent-related incident, validate that restored records are correct, and decide whether the agent should be re-enabled. Technical restoration is only part of recovery; the organization also has to judge whether the restored state is fit for the business.

Testing an AI agent recovery plan without assuming the worst

Run a bounded tabletop: choose an agent, define a set of business records it changed, and work through the scenario. This exercise applies the column’s recovery-map concept; the column does not provide a procedure. ¹

Have participants establish which agent acted, what records and connected systems may have been affected, what change history exists, and which processes should be restored first. Then test whether available logs show what the agent touched and whether the available history can distinguish intended changes from unwanted ones. The core questions remain: can you identify changes, recover prior state, and choose what to restore or exclude? ¹

Record each gap as a weakness to address, not proof that the deployment is unsafe. A team might find that it cannot trace an agent’s full write path, or that a record’s prior state is not retained. Assign an owner to each gap and decide whether to change the agent’s permissions, improve change logging, or add another control. The column offers no universal recovery standard, so do not assume one recovery target fits every workflow. ¹

What the reported agent-adoption numbers do and don’t tell you

The column reports several figures from Veeam: 88% of organizations were using or piloting agents, 7% qualified as “truly AI-ready,” and more than 82% had unknown agents in their environments. ¹ These are figures attributed to Veeam, not independently verified findings in the column; the excerpt does not disclose methodology or sample size. ¹ Read them as signals to check against your own environment, not as a basis for forecasting your specific risk.

Veeam also reported findings from its preview customers: a quarter of a 40-terabyte estate did not need to be in production, and one tenant had 25 agents, two of them actively modifying data. ¹ These are findings described from particular preview environments, not general benchmarks; the column does not say how far they generalize. ¹

The column describes Veeam’s response: Intelligent ResOps, generally available for Microsoft 365 as an add-on to Veeam Data Cloud for Microsoft 365. ¹ It is described as able to discover Copilot and other agents, show what sensitive data they can access, flag redundant, obsolete, and trivial data, and undo agent changes file by file. ¹ Intelligent ResOps for Veeam Data Platform and Okta was in private preview, with previews for GitHub, Azure DevOps, and Google IAM planned for the fourth quarter. ¹ These are examples of one vendor’s response to the problem, not evidence that a product closes the full recovery gap for every organization. ¹

What to do next

Bring security, continuity, and AI governance owners together to build a shared inventory of agents, permissions, connected systems, and the paths that let an agent write to data. For workflows with meaningful consequences, require a recovery map before go-live: what evidence identifies changes, what prior state is retained, what gets restored first, and what gets excluded. Exercise the plan before it is needed. For lower-stakes uses, document why a lighter check is sufficient rather than skipping the question.

If agents call models through a shared layer, an enterprise AI gateway with audit logs, spend controls, and source-address allow-lists on API keys can help with the inventory and access side of this work. It does not record or restore changes an agent makes to your business data, so the recovery map still has to come from your own systems.

The column argues for connecting incident response and recovery planning. Its account of the Spain incident is not independently corroborated in the excerpt, and it does not offer a general implementation framework or compare risk across deployment types. ¹ The planning question still stands: for every agent that can touch business data, if it changes something, can you tell what changed—and restore the state the business actually wants?