A few days ago, a story started circulating in the security community about a Claude Code agent that reportedly deleted 48,218 live files in 103 seconds. Here is what happened, in plain terms, and why it matters for every organization deploying AI agents today.
What the Agent Actually Did
A developer gave a Claude Code agent a legitimate task: create a mirror of a project. That is a routine maintenance job. The agent was authorized to do it. No one hacked anything. No credentials were stolen.
The agent ran into a problem. The mirror could not be refreshed in place, so it wrote its own Python script to clean up an older copy stored in a temporary location. That location contained Windows directory junctions, which are essentially shortcuts pointing back into the live project tree. The script followed those junctions and deleted files in the live project tree as part of its cleanup. According to the account, 48,218 live files were deleted in 103 seconds. The Git repository’s object store was also wiped, leaving Git unable to restore the deleted files.
This was not a rogue agent. It was an authorized agent whose actions during a legitimate task caused serious damage.
Why This Is Exactly the Problem We Have Been Talking About
The agent was authorized to complete a task, but that authorization did not adequately limit the actions it could take to complete it. The agent interpreted that authorization as permission to do whatever it determined was necessary to complete the task. That gap, between the intent of the authorization and the actual blast radius of the permissions granted, is the core problem in agentic AI security today.
This is a least privilege failure. The agent should never have had the ability to write and execute arbitrary Python scripts, traverse directory junctions, and perform bulk deletions while creating a mirror. Its access needed to be limited to the resources required for that task.
This is also a least agency failure. Least agency is not just about what an agent is allowed to access. It is about constraining what an agent is allowed to decide. An agent operating under least agency would not have the autonomy to write its own cleanup script and execute it without a human checkpoint. Every destructive action, especially irreversible ones, needs a human in the loop or a hard cryptographic constraint that prevents execution without explicit re-authorization.
Additionally, the incident exposes a runtime governance gap. Authorization was granted once, at the start of the task. There was no continuous enforcement of what the agent was actually doing. A runtime policy could have limited access to the intended mirror location and stopped deletions that reached the live project tree. Intent-based policy adds another layer of security by evaluating whether the agent’s actions remain aligned with the objective of creating a mirror, even when an individual tool call appears permissible on its own.
And here are the questions an organization would need to answer afterward:
- What tools did the agent have access to
- What permissions were active
- What code did it generate and run
An AI Bill of Materials, paired with activity logs, helps establish what the agent could do and what it actually did. That record is essential for investigating an incident and explaining it to auditors.
What AppViewX Agent Identity Security Does About This
The problem in this incident is not that AI agents are dangerous or can make mistakes. The problem is that AI agents were treated as trusted automation without the identity and access controls that any other privileged system actor would require. Incidents like this are preventable, and AppViewX Agent Identity Security is designed to give organizations visibility into their agents and control over what those agents can access and do as a task unfolds.
AppViewX helps organizations identify agents and understand the credentials, tools, and resources connected to them. Our AI Bill of Materials provides an inventory of Users, Credentials, Endpoints, Skills, MCP Servers, Models, Packages, DNS calls, Terminal commands, API calls and more. Combined with activity logs, it gives security teams the context to investigate what happened and review whether access and policy decisions worked as intended. That visibility provides the foundation for setting policies around each agent’s purpose and access.
Privileged access control for agents works the same way it does for humans accessing production systems. You do not give a contractor the master key because they need to paint one room. You scope access to the room, for the duration of the job, with audit logging throughout. Our just-in-time access policies grant an agent access only when a specific task requires it and remove that access when the task or approved period ends, and the scope is cryptographically enforced. For a project mirror, the agent could receive access to the necessary source and destination, without standing access to unrelated locations. This limits the damage if an agent is compromised, manipulated, or behaves unexpectedly.
Runtime security means that authorization is not a one-time handshake at the start of a task. It is a continuous enforcement layer that validates what the agent is doing against what it was authorized to do, in real time. Our intent-based controls understand what an AI agent is trying to accomplish and evaluate whether its actual actions remain aligned with that objective. We detect when the agent acts outside the intended scope, including unexpected, risky, or potentially malicious behavior, and govern or stop the activity at runtime. If a cleanup operation begins deleting files in the live project tree, the activity has moved outside the intended scope and should be stopped.
The lesson from this incident is straightforward: authorizing an agent to complete a task is not the same as authorizing every action it might choose along the way. Organizations need to define the task’s boundaries, grant access only when needed, and enforce those boundaries while the agent is working.
Conclusion
The reported Claude Code incident shows how quickly an authorized agent can cause damage when it has more freedom to act than its task requires. The developer asked the agent to mirror a project, but it deleted live files instead.
AppViewX Agent Identity Security helps organizations understand which agents are operating, what tools and credentials they use, and where they have access. Teams can then apply task-based policies, just-in-time access, approvals for sensitive actions, and runtime checks for behavior that drifts from the agent’s intended objective. When those controls are integrated with the actions an agent takes, they can limit what the agent can reach and help stop out-of-scope activity before it spreads.
The AI Bill of Materials capability gives you a complete inventory of every agent in your environment: what model version it is running, what tools it has access to, what credentials it holds, what tasks it has been authorized to perform, and a full audit trail of what it actually did. When something goes wrong, you have a forensic record. When a regulator asks, you have an answer.
The Claude Code incident, if verified, is not an indictment of AI coding agents. It is an indictment of deploying AI agents as if they were conversational assistants rather than privileged machine identities. The developer in that story was not negligent. They were working without the right infrastructure.
That infrastructure exists. And organizations that are serious about deploying agents at scale need to build it in before the 103-second clock starts.
Tags
About the Author
