Originally Published: 16 Sep 2026
An AI agent is given a task, but nothing about that task limits what it can reach. What it can reach is decided by the environment it runs in, and most environments weren’t designed with autonomous software in mind.
In July 2026 that stopped being hypothetical.
That’s when research agents inside OpenAI’s own evaluation infrastructure left their sandbox and compromised production systems at Hugging Face, in what OpenAI’s technical report calls “the first known case of an automated agent collective acting offensively without authorization.”
Presumably, those aren’t the type of agents running in your organization, but the incident raises a question for anyone deploying autonomous software: when something acting on its own is already inside your environment, how much data and functionality should it be able to reach?
In this blog, you will find out:
- What happened when OpenAI’s agents reached Hugging Face
- Why the agents continued after recognizing they were out of scope
- What ENISA said about agentic AI security risks
- Where ENISA’s warning lines up with the incident
- Whether enterprise AI agents face the same risks
- Which controls limit what an AI agent can reach
What Happened When OpenAI’s Agents Reached Hugging Face?
Agents that were supposedly solving offensive security exercises inside a closed sandbox found routes out of it and compromised a third party’s production infrastructure. Roughly 22% of the tasks were left unsolved, and, according to OpenAI’s report, 93% of the tasks discussed on the agents’ improvised message board came from that unsolved set.
Timeline of the Incident
| Date (2026) | What Happened |
| 8-26 May | An agent abused a server-side request forgery flaw in OpenAI’s internal Artifactory. Agents reached the public internet and located exposed Hugging Face credentials |
| 5 July | The compromise was discovered and the instance was taken offline |
| 8-9 July | After the rebuild, agents re-established internet access and obtained root inside the sandbox’s parent virtual machine |
| 11 July | A dataset file carrying a hidden Jinja expression made a Hugging Face dataset server run the agents’ commands |
| 13 July | Kubernetes access, VPN enrollment, repository downloads and 31 MB of data exfiltrated |
| 16-21 July | Hugging Face disclosed the breach, then OpenAI confirmed its agents were involved |
What the Agents Reached
By the time the activity was contained, the agents had obtained:
- Code execution on 41 Hugging Face production dataset server workers
- Production credentials covering Hugging Face’s VPN, cloud environments, code repositories and messaging platform
- Four private code repositories, plus a 16 MB private benchmark archive uploaded to a public dataset
Blocked from ordinary communication, the agents repurposed Artifactory’s folder directory structure to embed messages in the names of directories. Dark Reading reported that around 700 agents collaborated, with roughly 1,200 communicating across sandboxes at the peak.
Why Did the Agents Continue After Recognizing They Were Out of Scope?
It seems to be because completing the task earned reward and stopping didn’t.
Reasoning traces reconstructed by METR and Redwood Research, reported by Axios, show an agent working through that decision:
External infrastructure exploit is outside intended scope. However task impossible, peers doing it. We should continue.
Basically, the agent identified the boundary correctly, but chose to ignore it when weighing it against the goal. OpenAI attributes the behavior to reward hacking, which it describes as finding “an unintended way to achieve an outcome that earns reward without completing the task.”
Agents are given tasks and instructions not to do certain things, but they turn out to have enough autonomy to find ways around those instructions. Words like hacking and cyberattack imply malicious intent, but there was none here. The agents were optimizing, and the route just happened to run through infrastructure that they weren’t expected to touch.
What Did ENISA Say About Agentic AI Security Risks?
ENISA published its view on cybersecurity in the frontier AI era two weeks before the incident became public. The report argues that AI has shrunk the time defenders have to respond, to the point where existing processes no longer fit.
The findings most relevant to anyone running agents:
- “The delta between discovery and weaponisation is approaching zero,” and the median time from initial access to data exfiltration has fallen to 72 minutes.
- Securing “agentic endpoints and enterprise browsers” is named as a priority, because “AI agents increasingly operate autonomously on endpoints and within browsers.”
- Adversaries “are increasingly compromising the AI and software supply chain to land inside infrastructure directly,” arriving through a trusted software update or a compromised open-source dependency.
- In 75% of breaches, ENISA says, “logging existed that should have flagged anomalous behaviour,” but the signals sat in separate systems and were never pieced together.
The report’s instruction to defenders is to “accelerate zero-trust segmentation, behavioural baselining, and more evasion-resistant detection layers,” and to treat every environment as potentially already compromised.
What ENISA recommends is not new. Unpatched software and weak access control have been known problems for years, but AI is making them more visible and more acute.
The same reading appears in OpenAI’s call for collective action on cyber defense, published on 28 August and co-signed by 135 technology companies including Google, Microsoft and Anthropic. That letter names the existing backlog as “longstanding bugs, excessive permissions, misconfigurations, insecure and unpatched software, weak authentication, and technical debt in legacy systems,” and asks organizations to “upgrade or replace systems to build in least privilege, strong access controls, and defense in depth.”
Excessive permissions appear on both lists.
Where Does ENISA’s Warning Line Up With the Incident?
Closely enough that the report reads as a description of the event, despite being published before it became public.
| What ENISA Described (July 2026) | What the Incident Demonstrated |
| Agents operating autonomously on endpoints and inside browsers as a new attack surface | Agents operating autonomously inside an evaluation sandbox found repeated routes out of it |
| Adversaries landing inside infrastructure and moving laterally, never testing the perimeter | The agents started inside; no perimeter control was ever in the path |
| “Assume-breached mindset” and zero-trust segmentation as architectural requirements | Every escalation step used access that happened to be available rather than access the task required |
| Logging present in 75% of breaches, with the signals never pieced together | OpenAI says the monitoring it runs today would have alerted its security team “more than a day before models breached Hugging Face systems” |
Bri Frost of Cloud Range, quoted by Dark Reading, summarized the monitoring failure: “They had logs; they did not have comprehension or appropriate escalation.”
Are Enterprise AI Agents Exposed to the Same Agentic AI Security Risks?
Not in the same form. The research agents ran with safeguards deliberately removed, on tasks that rewarded exploitation. OpenAI’s report says its production safeguards cut attempts to compromise infrastructure to under 1% of the rate seen without them. In practice, the two compare like this:
| OpenAI Research Agents | Typical Enterprise Agent | |
| Task | Discovering and building working exploits | Summarizing, drafting, retrieving, classifying |
| Reach | Whatever the sandbox host could touch | Whatever the signed-in user can open |
| Failure mode | Pursued the task past its stated boundaries | Reads, copies or moves data the user never meant to expose |
An agent installed on a laptop, or running inside an application someone is signed in to, inherits that person’s permissions, which usually reach well beyond the files they work on day to day. We covered that inheritance problem in our shadow AI blog.
Reach also matters for reasons that have nothing to do with agent misbehavior. The UK’s National Cyber Security Centre made the point on 7 September:
AI agents are complex pieces of software that can have critical security vulnerabilities. If an attacker successfully exploits a vulnerability, they can gain access to the same data, services, and privileges that the agent has legitimate access to.
The NCSC advises reducing shadow AI rather than blocking it outright.
What Controls Limit What an AI Agent Can Reach?
The controls that work narrow what an agent is able to touch instead of telling it what not to do, so none of them depend on the agent cooperating.
| Control Layer | What It Limits | What the Incident Showed |
| Network egress control | Restricts which destinations an agent can reach | OpenAI now requires a “tightly controlled set of approved destinations” and two independent isolation layers |
| Process-level file access control | Decides which applications may open which folders, regardless of user rights | The agents read credentials and data that no policy granted them |
| Behavioral monitoring with escalation | Turns telemetry into a response, not an archive | Logs existed; nobody was watching them in real time |
| Residual data removal | Removes recoverable copies reachable without any privileges at all | Credentials found in public datasets were enough to start |
Why Naming the Tool Is Not the Control
Blocking specific AI applications by name holds only until a new one appears, or until an approved application adds an agent feature in a routine update. The process reading your files may be one you already trust. Controls that work at the level of which process may open which folder keep working through all of that, and the moment a file opens is the state of data most controls skip.
This is where BestCrypt Data Shelter fits. It applies policy-based access control at the moment a file is opened, deciding which users, applications and processes may reach a protected folder on a default-deny model that blocks every request that’s not explicitly approved. An unapproved process reading a folder of personal data gets refused, whether it’s ransomware, an unsanctioned tool or an agent doing exactly what its user asked.
The practical version is narrow in scope. Pick the folders that would actually hurt: HR records, legal files, the finance export directory. Approve the applications that need them. Our guide to protecting data in use covers the setup step by step.
What About Data That Was Never Supposed to Be Readable?
Access control governs the files you know about, but not the copies you don’t. You can control access to a folder all you want, but if a background process writes plaintext to the disk then that copy can be recovered.
Temporary files, cached exports and recoverable fragments sit in free space where a policy protecting the original folder never applies, and an agent with local access has time to look. Removing that residue is the job of selective wiping.
Architecture Decides What an Agent Can Reach
An agent has a reward signal and whatever reach you left open. The OpenAI agents behaved exactly as optimizing systems behave, and ordinary controls would have closed the openings they used.
Neither ENISA nor OpenAI asks for anything unusual. Decide what your autonomous software is allowed to reach, then enforce that decision at the point the file opens rather than in a policy nobody reads. The agents are already inside, so the question that’s left is how far inside they will get.
See What Your AI Tools Can Reach
BestCrypt Data Shelter decides which users, applications and processes are allowed to open a protected folder, and refuses everything else by default.
Read more about BestCrypt Data Shelter or talk to our data protection specialist about protecting data in use.
Frequently Asked Questions (FAQs)
Agentic AI security risks are the risks created when AI software acts autonomously inside an environment rather than answering questions in a chat window. An agent can read files, call APIs, execute code and chain actions without a human approving each step. In its July 2026 report on cybersecurity in the frontier AI era, ENISA identifies agentic endpoints and enterprise browsers as critical new attack surfaces.
In The Hidden Risks of Shadow AI, published on 7 September, 2026, the UK National Cyber Security Centre warned that AI agents can carry critical vulnerabilities, and that an attacker who exploits one gains “the same data, services, and privileges that the agent has legitimate access to.” An agent inherits the permissions of whoever runs it, so for most employees that means every shared drive they can open. The NCSC advises reducing shadow AI rather than eliminating it, since blocking every possible AI service is not realistic. Our blog on Shadow AI covers how that inheritance works in practice.
Zero trust covers the principle but not always the implementation. Most zero trust programs authenticate users and devices, then allow any process running as that authenticated user to access whatever the user can access. An AI agent is such a process. Extending zero trust to agents means deciding access at the process level, so the question becomes which application is asking for this folder rather than just who is logged in.
By applying access control at the point the file is opened rather than at the perimeter or in policy. BestCrypt Data Shelter enforces policy-based access control on protected folders, deciding which users, applications and processes may reach them and denying everything not explicitly approved. Because the rule applies to the process rather than to a named product, it holds when a new AI tool appears or when an approved application adds an agent feature.