{"id":9087,"date":"2026-06-02T14:14:42","date_gmt":"2026-06-02T14:14:42","guid":{"rendered":"https:\/\/gitprotect.io\/blog\/?p=9087"},"modified":"2026-06-18T13:37:55","modified_gmt":"2026-06-18T13:37:55","slug":"ai-agent-security-strategy-backup-and-recovery","status":"publish","type":"post","link":"https:\/\/gitprotect.io\/blog\/ai-agent-security-strategy-backup-and-recovery\/","title":{"rendered":"Why backup and recovery must be part of your AI agent security strategy"},"content":{"rendered":"\n

The terminal output was still scrolling when Jer Crane, the founder of PocketOS<\/a>, realized what had happened. <\/p>\n\n\n\n

Nine seconds. That is how long it took a coding AI agent to delete his production database, his backups, and three months of operational records.<\/p>\n\n\n\n

PocketOS was using Cursor for what should have been a routine task in a test environment. When the agent encountered a credential mismatch, it decided to “resolve” the issue by deleting a production database volume hosted by the company\u2019s infrastructure provider. To perform the deletion, the agent used an API token it found in a file unrelated to the task. That token had permissions broad enough to execute a volume-delete command.<\/p>\n\n\n\n

The gravity of this incident was not limited to the fact that the AI agent took destructive action without being ordered to do so. The deeper problem lay in the recovery architecture.<\/p>\n\n\n\n

According to Crane<\/a>, the provider\u2019s volume-level backups sat inside the same blast radius as the production data. When the agent deleted the database volume, the backups disappeared too. The most recent recoverable backup was three months old. More than 30 hours later, the provider still could not confirm whether infrastructure-level recovery was possible.<\/p>\n\n\n\n

For PocketOS it was a catastrophe. The company serves rental businesses that use its software to manage reservations, payments, customer profiles, and vehicle assignments. After the incident, customers were missing records for recent reservations, new signups, and operational data they needed to serve people arriving to pick up vehicles. The team had to reconstruct what they could from Stripe payment histories, calendar integrations, and email confirmations.<\/p>\n\n\n\n

It is easy to read this as another story about an AI agent going rogue. But I see it as a lesson about how weak recovery architecture and overreliance on provider-native backups turned one destructive action into a prolonged business disruption.<\/p>\n\n\n\n

AI agent security cannot stop at access controls, approvals, sandboxing, and monitoring. They\u2019re important, no doubt. But they do not answer the question that decides the business impact of a destructive action: if an AI agent with legitimate access damages critical data today, how fast can you get it back?<\/p>\n\n\n\n

That question now belongs in every AI agent security strategy, especially in DevOps environments where code, CI\/CD configurations, work history, and project metadata carry the memory of how software gets built, shipped, and audited.<\/p>\n\n\n\n

The PocketOS incident was a backup and recovery warning<\/h2>\n\n\n\n

In the PocketOS case, the database deletion was just the warm-up. The second blow was that recent backups disappeared with the data they were supposed to protect and the only available backup was three months old. As a result, customers and the PocketOS team had to reconstruct missing business records manually.<\/p>\n\n\n\n

They barely survived that incident because, as an organization, they weren\u2019t resilient enough and entrusted their safety to others without even checking what exactly was being offered to them.<\/p>\n\n\n\n

What lesson should we learn from this? Certainly not that every AI agent will destroy your databases. However, we should definitely realize that backup and recovery must become an integral part of the AI agent security strategy.<\/p>\n\n\n\n

AI agents turn legitimate access into a larger blast radius<\/h2>\n\n\n\n

AI agents change the risk model because they do more than generate text or code. Their autonomous nature is both an advantage and a drawback. The UK\u2019s National Cyber Security Centre<\/a> warns that agentic AI can increase risk through broader access, less predictable behavior, and actions happening faster than humans can meaningfully review.<\/p>\n\n\n\n

The uncomfortable part for the security teams is the fact that AI agents do not need to be malicious. They can be approved and assigned to a legitimate task. <\/p>\n\n\n\n

A human with admin access can cause damage. An automated agent with the same access can cause damage faster, across more systems and with fewer chances for a human to notice in time. This is one of the reasons why the guidelines developed by the ACSC, CISA, NSA, Canada\u2019s Cyber Centre, NCSC-NZ, and NCSC-UK<\/a> warn organizations against granting agentic AI broad or unrestricted access, especially to sensitive data or critical systems.<\/p>\n\n\n\n

This issue affects DevOps because AI is already deeply embedded in software work. Software engineering teams account for nearly 50% of AI use<\/a> and AI agents are likely to play a major role in future software development workflows.<\/p>\n\n\n\n

No matter how extensive your preventive measures are, they won\u2019t protect you 100% against incidents. When an AI agent misuses its autonomy, it will simultaneously put your recovery plan to the test.<\/p>\n\n\n\n

\ud83d\udca1 Agentic AI can be an attack surface multiplier. See our list of 7 novel AI security threats in DevOps. Learn more<\/a><\/p>\n\n\n\n

Prevention and detection lower the odds. Recovery limits the loss.<\/h2>\n\n\n\n

After the PocketOS incident, the AI agent explained that it deliberately violated safety and project rules, didn\u2019t read the provider\u2019s docs on volume behavior across environments and  \u201cdid not understand what it was doing before doing it\u201d. <\/p>\n\n\n\n

In other words: The AI agent wasn’t lacking in intelligence, but it had trouble assessing the situation. It can complete a task flawlessly while missing a piece of context that turns a valid action into a mistake.<\/p>\n\n\n\n

System prompts, approval flows, scoped credentials, monitoring and human review mitigate risk. However, none of the measures will be effective if an agent chooses to ignore them. And none of them will reverse the damage that has been done.<\/p>\n\n\n\n

A functional AI agent security strategy needs three layers: prevention, detection and recovery.<\/p>\n\n\n\n

\"A<\/figure>\n\n\n\n
Security layer<\/td>Control measures<\/td><\/tr>
Prevention
(Reduce the chance of damage)<\/td>		Least privilege, scoped credentials, sandboxing, human approvals<\/td><\/tr>
Detection
(Note the damage or abnormal behavior)
<\/td>		Logs, alerts, anomaly detection, change monitoring<\/td><\/tr>
Recovery
(Undo the damage and restore operations)
<\/td>		Isolated backups, immutable storage, granular restore, tested DR<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

In addition to implementing human approval checkpoints for high-impact actions and procedures to detect and contain agent compromise, CISOs should also ask themselves: \u201cWhat happens if prevention fails?\u201d.<\/p>\n\n\n\n

That question becomes more urgent when an AI-agent can touch DevOps environments. What’s at stake is not only the source code. Repositories, pull requests, issues, CI\/CD configuration, permissions, and project metadata, are the context teams need to ship, investigate, audit, and recover software.<\/p>\n\n\n\n

Old backup assumptions break under AI-agent speed<\/h2>\n\n\n\n

The PocketOS incident showed that simply having a backup does not mean you are prepared for a destructive event or able to minimize its business impact.<\/p>\n\n\n\n

There are still many misconceptions in DevOps that can prove costly, given the speed and scale of the damage that AI agents can cause.<\/p>\n\n\n\n

Old backup assumption<\/strong><\/td>Why it breaks with AI agents<\/strong><\/td>What recovery must prove<\/strong><\/td><\/tr>
Our Git provider keeps our data safe.<\/em><\/td>Native platform protection may not cover deletion, corruption, metadata loss, or account-level mistakes.<\/td>You can recover DevOps data outside the primary platform.<\/td><\/tr>
A recent-enough backup is good enough.<\/em><\/td>Agent-speed damage makes stale backups more expensive, especially during active development.<\/td>Backup frequency matches your RPO<\/a>.<\/td><\/tr>
Admins can fix it manually.<\/em><\/td>An agent can make changes faster than humans can review, trace, or reverse them.<\/td>Recovery should work at incident speed, not manual cleanup speed.<\/td><\/tr>
We back up the repo.<\/em><\/td>Source code alone does not restore the full delivery context.<\/td>You can restore more than source code.<\/td><\/tr>
The backup is safe.<\/em><\/td>The same credentials, integration, or admin path may reach both production data and backups.<\/td>Backups sit outside the same blast radius.<\/td><\/tr>
We\u2019ll restore it if needed.<\/em><\/td>Untested recovery is only an assumption.<\/td>
Teams know their real RTO<\/a> before the incident.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

\u201cOur infrastructure provider takes care of backup and restore\u201d was not a viable survival plan for PocketOS and does not constitute a sound strategy for any organization operating under a DevOps model. You need to know whether your backups are current, isolated, restorable, and tested.<\/p>\n\n\n\n

However, there are other issues to consider before agents receive broader access.<\/p>\n\n\n\n

AI agent access needs more than approval<\/h2>\n\n\n\n

Granting an AI agent access should not be treated as a simple permission request. Once an agent can act inside DevOps systems, Security needs to understand more than who approved it.<\/p>\n\n\n\n

Access and authority<\/strong><\/p>\n\n\n\n