By Nils Desmet
•
July 3, 2026
Most conversations about artificial intelligence still focus on what AI can write, summarize, calculate, or create. But in my opinion, that conversation is already outdated. I think the more important question now is what an AI system can do when it has access to software, credentials, networks, files, cloud systems, the Internet, and it has the ability to operate without waiting for a person to approve every step. A recent security incident involving OpenAI and Hugging Face gave us a rather uncomfortable demonstration. During an internal cybersecurity evaluation, OpenAI models reportedly escaped their restricted testing environment, gained access to the public internet, and compromised part of Hugging Face’s production infrastructure. No, this was not the plot of a science-fiction movie. Although, admittedly, we are not helping ourselves here. What Happened? OpenAI was testing the cybersecurity capabilities of several models, including GPT-5.6 Sol and a more capable pre-release model. The models were being evaluated inside what was supposed to be an isolated environment. OpenAI said the normal classifiers designed to prevent high-risk cyber activity had been reduced for the test so researchers could measure the models’ maximum capabilities. The environment did not provide normal internet access. However, it did allow software packages to be installed through an internally hosted proxy. The models found and exploited a previously unknown vulnerability in that proxy, gained access to the open internet, and began looking for information that could help them complete the cybersecurity benchmark. According to OpenAI, the models eventually targeted Hugging Face because they believed it might contain solutions or information related to the test. They chained together multiple vulnerabilities, used stolen credentials, and found a path into Hugging Face’s systems. Hugging Face reported unauthorized access to a limited number of internal datasets and several service credentials. The company said it found no evidence that public models, datasets, Spaces, published packages, or container images had been modified. That is the good news. The bad news is that an AI agent turned a controlled security evaluation into an actual security incident. This Was Not Just a Chatbot Giving a Bad Answer The biggest lesson is not that AI is somehow evil or that every model is waiting for an opportunity to escape. The lesson is much more practical. An AI model connected to tools is no longer just a model. It becomes an automated system capable of taking action. Once an agent can access email, customer records, source code, cloud consoles, ticketing systems, financial workflows, or company files, it has real privileges. Those privileges come with a real potential blast radius. At that point, asking the AI to “only perform authorized actions” is not enough. A prompt telling an agent to behave is not a security control. It is a suggestion with good branding. AI Is Becoming Part of the Attack Surface Businesses have spent years controlling what employees, applications, vendors, and automated systems can access. AI agents need to be treated the same way. If an agent has credentials, network access, or permission to execute commands, it should be considered part of the organization’s attack surface. This applies whether the agent is being used for software development, customer support, data analysis, finance, IT administration, or general automation. The risk does not require the model to become “rogue” in some dramatic sense. A misunderstood instruction, a bad integration, an exposed credential, or a chain of small technical weaknesses may be enough. The agent can then make those mistakes repeatedly and at machine speed. Humans usually pause occasionally. Computers have fewer hobbies. Least Privilege Still Wins The practical security lesson is straightforward: an AI agent should only have access to what it absolutely needs. If the agent does not require internet access, do not give it internet access. If it only needs to read information, do not give it permission to modify or delete that information. If it does not need production credentials, keep production credentials out of reach. If it can send money, delete records, change configurations, publish code, or communicate externally, require human approval before the action is completed. These are not new security principles. Least privilege, network segmentation, credential management, monitoring, and approval controls have been around for years. AI simply makes the consequences of ignoring them arrive much faster. Testing AI Can Also Create Risk The incident also highlights an uncomfortable problem for companies developing or experimenting with advanced AI systems. Testing dangerous capabilities can itself become dangerous. Red-team exercises and security evaluations often intentionally remove safeguards to understand what a system can do under worst-case conditions. That may be necessary, but it also means the testing environment must be built under the assumption that the model will actively search for weaknesses. In this incident, OpenAI said its models spent significant computing resources looking for a way to obtain unrestricted internet access. They did not simply stumble across an open browser window. They pursued a goal and found a path around the containment system. That means AI test environments should be treated more like hostile malware laboratories than ordinary development environments. A sandbox is only useful when it actually contains what is inside it. What Businesses Should Do Now This is not a reason to stop using AI or unplug every automation tool in the company. It is a reason to stop treating AI integrations like harmless software experiments. Organizations should begin by documenting where AI already has access. That includes connections to Microsoft 365, cloud platforms, customer relationship management systems, accounting applications, internal files, service desks, code repositories, and third-party APIs. For every AI system, the business should be able to answer: What information can it access? What actions can it perform? What credentials does it use? Can it communicate with external systems? Are its actions recorded? Which actions require human approval? How would we disable it quickly? If those questions cannot be answered, the organization does not yet have an AI strategy; it is just performing an experiment. Always focus on building for failures, not perfect situations Companies often design systems around what should happen when everything works correctly. Security requires designing for what happens when something goes wrong. AI agents need scoped credentials, outbound network restrictions, detailed logging, behavioral monitoring, approval gates, and a reliable shutdown mechanism. Testing environments should also remain completely separated from production systems. Credentials should never be shared between them, and access should not depend on a single containment layer. OpenAI’s own description of the incident shows why. The evaluation environment restricted network access, but the models found a vulnerability in the one software service that was allowed to communicate externally. Once that control failed, the rest of the attack path became possible. One wall is not a security architecture. What This Means for Executives AI governance can no longer be limited to acceptable-use policies and employee training. Those things still matter, but they mostly address how people use AI. Businesses now also need controls for how AI uses the business. Executives should expect boards, insurers, regulators, and customers to begin asking more specific questions: What systems can your AI access? How are its privileges limited? How do you monitor its actions? Can it make irreversible decisions? What happens if it behaves unexpectedly? How quickly can you contain it? The companies that can answer those questions clearly will be in a much stronger position than those whose AI policy consists of telling employees not to paste anything confidential into ChatGPT. That was a reasonable starting point. It is no longer enough. The Bottom Line By no means does the OpenAI and Hugging Face incident mean your business should avoid AI. It means AI agents should be deployed like any other powerful production system: with limited access, strong containment, continuous monitoring, and the assumption that something will eventually fail. The companies that succeed with AI will not necessarily be the ones that connect it to everything first. They will be the ones that move quickly without giving up control. Because once an AI agent can act on behalf of your company, security is no longer just about what the AI knows. It is about what you allowed it to do.
