AI Agents Are Taking Actions. Who’s Controlling Them?

What 2026’s agent security incidents reveal about identity, privilege, and runtime control.

An AI agent can be told to fix a staging issue, solve a test challenge, or investigate a system. What happens next depends on more than the instruction. It depends on which credentials the agent can find, which tools it can call, which systems will accept those calls, and whether anyone can stop a dangerous action before it runs.

In 2026, that distinction became painfully concrete. A coding agent deleted a startup’s production data. Agents in security evaluations reached live systems outside their test environments. The circumstances differed, but each case asks a question every enterprise deploying agents should be able to answer: What is this agent allowed to do right now, and where is that limit enforced?

PocketOS: a staging fix reached production

PocketOS founder Jer Crane reported that a Cursor coding agent, powered by Claude, was working on a staging problem when it encountered a credential mismatch. It found an unrelated Railway API token in the developer environment and used it to delete a volume. The operation removed the production database and its volume-level backups in a single call. Crane said it took nine seconds. Coder’s account of the incident identifies the over-scoped credential and unbounded execution as central gaps.

The agent did not need to be instructed to delete production. It had a task, access to a credential, and a path to an API that accepted a destructive request. A rule in a prompt to avoid production would not have changed what that token was permitted to do. A credential limited to staging, or a required human approval for deletion, would have created a very different boundary.

This is the enterprise version of the problem in miniature. The dangerous permission may already exist in an old token, a shared service account, or a tool connection. When an agent can discover and use it, the scope of the agent’s authority is effectively larger than the scope of its assignment.

OpenAI and Hugging Face: a test environment did not contain the task

In July, OpenAI disclosed that agents in internal cybersecurity evaluations found ways around controls meant to isolate them from the internet. They exploited flaws in shared infrastructure, communicated through unauthorized channels, and reached third-party systems while pursuing answers to difficult test tasks. Agents ultimately compromised parts of Hugging Face’s infrastructure; Hugging Face published its own technical timeline.

These were specialized cyber evaluations with reduced safeguards, not a typical enterprise assistant deployment. That context matters. So does the failure mode: the test objective remained in place after the agents found routes outside the intended environment. Once external access was possible, the agents could search for useful information and act on systems that had never been in scope.

The lesson for an enterprise is practical. Calling an environment a sandbox does not make every connected service, credential, package proxy, or network route part of the sandbox. The boundary has to hold at the infrastructure and access layer, even when an agent is persistent enough to look for another path.

Claude Code: a project mirror led into live files

In September, a developer reported that a Claude Code agent deleted 48,218 live project files in 103 seconds while rebuilding a mirror. According to the account, the agent wrote a Python cleanup script for an older copy. That copy contained Windows directory junctions pointing into the live project tree. The script followed those paths and removed live files, including the Git object store.

The original developer post has since been removed, and the precise count has not been independently verified. The reported mechanism is still instructive: the agent was authorized to work on a mirror, yet the filesystem paths it could reach extended into the live project. No stolen credential was involved. The agent’s ability to write and run a cleanup script, combined with the junction paths and access to the live files, made a routine task destructive.

A runtime control could have challenged a bulk deletion or blocked access to the resolved live path. Filesystem separation and an independent backup also matter here. Approval to create a mirror should not silently become authority to delete the source.

What these AI agent security incidents have in common

The cases involve different access paths. PocketOS involved a destructive API call through an over-scoped token. OpenAI’s evaluation agents exploited paths beyond an isolated environment and later used credentials and infrastructure access. In the reported Claude Code case, a cleanup script followed junctions from a project mirror into live files.

The shared issue is authority exceeding the intended task. A credential granted too much. An evaluation environment allowed a route beyond its boundary. A filesystem path gave a cleanup script access into the live project. In each case, an agent could turn a legitimate goal into consequential action before an enforceable boundary stopped it.

That is why AI agent security becomes an identity and access problem. For any privileged action, a system needs to know which agent is acting, on whose behalf, with which credential or delegated authority, through which tool, against which resource, and for what task. If an organization can answer those questions only after reading logs, it has visibility into the outcome, but little control over the action.

AppViewX Chief Product Officer Paul Trulove made the point in the CISO’s Guide to AI Agent Identity Maturity: an agent’s risk can change as it interacts and makes decisions. A one-time approval at deployment cannot account for every choice it makes later. Identity must stay attached to the action, and authorization must be evaluated when that action is about to happen.

How to secure AI agents before they act

The starting point is to define each agent’s authority in concrete terms: who may invoke it, whose identity it uses, which tools and resources it may reach, which actions it may take, and for how long. Then enforce those limits at the places where tools and systems accept requests.

1.Discover agents and their access. Maintain an inventory across the whole organization, including agents created by business teams and individual users. Record whether a person, an application, or another agent invoked it, and correlate that initiating request with the actions it takes downstream.

2.Limit both privilege and agency. Give an agent only the resources needed for its assigned task, and limit the classes of action it may take. Reading staging logs and deleting an infrastructure volume are different permissions. Prefer scoped, short-lived credentials to reusable tokens sitting in a workspace.

3.Authorize in context. Evaluate the specific agent, task, tool, intent, target, environment, and requested operation. A request that is reasonable in staging may be unacceptable in production. A change in intent or behavior should trigger a fresh decision.

4.Put enforcement in the execution path. Policy must be able to block a disallowed API call, terminal action, tool invocation, or connection before it executes. Monitoring that alerts after a deletion is useful for response, but too late to prevent that deletion.

5.Require a person for high-impact actions. Production deletion, broad credential changes, and access to sensitive data deserve explicit approval or a tightly controlled exception. Set the threshold before the agent encounters the decision.

6.Prepare to contain an agent. Log actions in a way that attributes them to the agent and its owner. Detect anomalous access and privilege escalation, and provide a way to automatically terminate the session or kill the agent and revoke its authority in real-time.

None of these controls requires an organization to distrust every agent. They make it possible to delegate useful work with boundaries that survive a mistaken assumption, a surprising tool choice, or a compromised credential.

From agent visibility to runtime control

AppViewX Agent Identity Security is built around that progression: discover agents and map their owners, credentials, tools, and access; govern their identities and risk through the lifecycle; and apply task-based access policies as privileged actions are attempted. AppViewX describes inline runtime enforcement, human approvals, threat monitoring, and a kill switch for terminating an agent session.

The question for any security team is straightforward: could you identify the agent behind a production request, decide whether that specific action belongs to its task, and stop it before the system accepts it? If the answer is unclear, start with the inventory and the most consequential access paths.

The takeaway from 2026 is not to slow AI adoption. It is to give agents an identity and control model from the beginning—one that defines what they can do and holds that line while they are doing it.