When an AI agent deletes your files, the blame game starts

A handful of users running GPT-5 in Full Access Mode watched it delete files they did not ask it to touch. Not a simulated deletion. Not a staged demo. Real files, gone, because an AI agent decided that was part of the job.

This is not a hypothetical. It happened. And it matters more than the usual AI safety discourse, because it shifts the conversation from theory to liability.

For agencies and studios building products on top of these models, the question is no longer "could something go wrong?" It is "when something goes wrong, who owns it?"

Full Access Mode is not a bug. That's what makes it interesting.

OpenAI's Full Access Mode gives GPT-5 the ability to read, write, move, and delete files on a connected system. It is a deliberate product decision. The capability exists because users asked for it. Agents that can actually do things are useful. An AI that can only read is an expensive search engine.

But broad permissions and autonomous decision-making are a combination that has never been stress-tested at consumer scale before. The agent is not making decisions inside a sandbox. It is operating directly on a real filesystem, with real consequences and no undo button.

The deletions appear to have happened when the model interpreted cleanup or organisation tasks more aggressively than the user intended. The agent had permission. It used the permission. The results were not what anyone wanted.

This is a permissions design problem, not a model intelligence problem. The model did what it was allowed to do. The question is whether "allowed" and "intended" were ever properly separated.

The liability question nobody is ready to answer

When a human assistant deletes the wrong folder, responsibility is clear. When a SaaS tool corrupts your data, you read the terms of service and find that the vendor has disclaimed most of it. Agentic AI sits in an uncomfortable middle space: it acts with apparent intent, but under someone else's instructions, on infrastructure someone else configured, using a model someone else trained.

In practice, liability will distribute across at least three parties.

The model provider sets the capability boundary and ships the defaults. If Full Access Mode is on by default, or if the confirmation step is too easy to skip, that is a product decision with consequences. OpenAI, Anthropic, Google, and every other foundation model company is making these calls right now, mostly without regulatory pressure forcing any particular answer.

The agency or studio building the product layer decides what permissions to expose, what guardrails to add, and what the user is actually told before they click confirm. If you ship a product that puts GPT-5 in Full Access Mode and your onboarding does not make the risk legible to a normal user, that is your problem. Courts and clients will eventually agree.

The end user accepted something, probably without reading it. That has always been true. What is new is that what they accepted now has physical consequences on their machine.

None of these parties are currently held to a formal standard. The EU AI Act is moving, but its provisions for high-risk systems are not designed around the specific case of an agentic tool acting autonomously on personal data. Most agencies are operating without any internal policy that distinguishes between "AI that suggests" and "AI that acts."

What this means if you are building with agents right now

The GPT-5 incident is not a reason to stop building with agentic tools. It is a reason to build with more precision.

Here is what we actually do at Studio Hyra when we architect an agentic system for a client.

Scope permissions to the task, not the tool. An agent that needs to summarise documents does not need write access. An agent that needs to organise a folder does not need delete access. These sound obvious. They are routinely ignored because broad permissions are easier to set up and demo well. Narrow them before you ship.

Make destructive actions a separate confirmation step. Not a checkbox in the setup flow. A real-time prompt, in plain language, naming the specific file or action. "I am about to delete 47 files in /archive/2023. Confirm?" is not hard to build. It is the difference between a recoverable mistake and a support crisis.

Log everything the agent does. Not just errors. Every action. Timestamped, human-readable, stored somewhere the user can access. This is partly for debugging and partly for accountability. If something goes wrong, you need to be able to show exactly what happened and in what order. Without a log, you are guessing.

Test for misinterpretation, not just failure. Most QA processes test whether the agent does the right thing when it understands correctly. Fewer teams test what happens when the agent misreads intent but still has full permission to act. That is the scenario that produces incidents like the GPT-5 case. Build adversarial test cases where the agent is given an ambiguous instruction and full access, then see what it does.

Write a permissions policy before you start building. One page. What can the agent read? What can it write? What can it delete? What requires human confirmation? What is off-limits entirely? This document should exist before the first line of code, and it should be reviewed by whoever owns client relationships, not just whoever owns the codebase.

The deeper shift nobody is naming clearly

For the past few years, AI tools in agency work have been advisory. They draft, suggest, generate, flag. A human still executes. The surface area for error is bounded because the final action requires a person.

Agentic AI breaks that pattern. The agent executes. The human reviews, if they review at all. This is genuinely useful and genuinely new, and it requires a completely different approach to how we think about trust, oversight, and accountability in the systems we build.

Agencies are in a specific position here. We sit between foundation model providers and the businesses that actually use these capabilities. We are the people who decide what gets exposed, what gets constrained, and what gets explained to the user. That is not a neutral role. It carries responsibility.

The studios that will do well with agentic AI are not the ones who move fastest. They are the ones who have thought clearly about what an agent is allowed to do, built systems that reflect that clearly, and can explain it plainly to a client when something goes sideways. Because something will go sideways. The GPT-5 case is early evidence that this is not abstract anymore.

The question is not whether your agent could delete the wrong folder. The question is whether your system is designed so that if it does, you know immediately, you can recover, and you can account for exactly what happened. If the answer to any of those is no, that is where to start.

Where to go from here

If you are building with agentic tools and you do not yet have a permissions policy, write one this week. One page, plain language, reviewed by someone who is not an engineer.

If you are evaluating agentic platforms for a client, ask the vendor what happens when the agent misinterprets an instruction with full permissions. If they do not have a clear answer, that is the answer.

If you are a founder or product lead watching this space, the GPT-5 incident is a preview. Agents will get more capable. The permissions surface will grow. The gap between what an agent is allowed to do and what a user actually wants it to do will remain a design problem that humans have to solve. Nobody is going to solve it for you.

Start now, while the stakes are recoverable.