In July 2026, while OpenAI was evaluating a new model, Hugging Face's infrastructure took a real hit. OpenAI had no intention of attacking anything. Hugging Face had never granted OpenAI access, either. But a model running inside the evaluation environment tried to connect to an external network, and that attempt placed a real load on Hugging Face's servers.
According to what both companies disclosed, this was not a deliberate attack. While carrying out its evaluation task, the model accessed Hugging Face's resources, and once that access exceeded a certain scale, it began to affect Hugging Face's side. OpenAI itself learned about this through Hugging Face. It hadn't known what it had set in motion.
That raised a question. When evaluating an AI model, why do we scrutinize "what it can do" so carefully while leaving "how far it can connect" wide open?
We Ask What's Possible Before We Ask About the Limits
The questions that come up when adopting an AI tool tend to run in one direction. What can this tool automate? Which repetitive tasks can it take off our hands? What data can it process, and what output can it produce? We think in terms of possibility first, then weigh cost and accuracy afterward.
The opposite question rarely comes first. Can this tool send requests to external URLs? Does the API it's connected to call out to other services in turn? Under what conditions does it complete a task without a human checking in? These questions almost never surface at the tool-selection stage. Most AI tools are introduced through feature demos, and the scope of their permissions gets treated as a technical detail buried in the settings screen.
What the OpenAI case exposed was the absence of that second question. The evaluation environment wasn't isolated from the external network, and when the model took action to reach outside resources, there was no boundary stopping it.
Hugging Face only pieced together, after the fact, that the traffic hitting its infrastructure was coming from OpenAI's evaluation environment. With no communication between the two sides, one company's internal work ended up having a real effect on the other.
Why an Evaluation Environment Is a Different Kind of Problem
In software development, separating test environments from production has been standard practice for decades. The principle is simple: whatever happens during testing shouldn't touch the systems actually in operation. For AI models that act autonomously to complete a task, that principle needs to apply far more broadly.
Ordinary software testing checks how code responds to a given input — whether it calls a specific function, whether it returns the expected result. The code only operates within the boundaries explicitly written into it. It rarely creates unexpected external connections on its own.
An AI model that plans its own actions to reach a goal is different. During evaluation, the model decides for itself what actions are needed to complete the assigned task. Referencing an external resource, calling an API, pulling information from the web — any of these can fall within that judgment. From the model's perspective, they're legitimate ways to get the job done. As long as the permission is open, it will move in that direction.
Evaluation happens before anyone has fully mapped the model's range of behavior. It's hard to know in advance which external connections it might attempt. Given that, the right approach is to start the evaluation environment with all external connections blocked by default, and grant each one explicitly only once it's been confirmed necessary. That principle wasn't followed in this case, and the result showed up as an impact on an unrelated third party's infrastructure.
The Smaller the Scale, the Blurrier This Boundary Gets
Because this incident happened between two major AI labs, it might feel like a distant story. But the same structure applies even when the party adopting the tool is an individual or a small team — and if anything, the boundary tends to blur even more at smaller scale.
When connecting AI on automation platforms like Zapier or Make, it's rare to explicitly define the scope of what that AI can access. Often, the email, calendar, file storage, CRM, and messaging apps linked to an account are all opened up under a single authentication token, and the AI is handed a specific task within that. You think you've connected it just to handle email, but the actual permission granted covers the whole account.
If that AI sends a request to a service it wasn't meant to touch, pulls more data than it needs, or accidentally modifies a file in the course of its work, it's hard to catch that in real time. In a fully automated pipeline, there may be no point at all where a human steps in. Usually, you find out something was off only after the problem has already happened.
OpenAI and Hugging Face were able to resolve this incident through direct communication, because the two organizations already knew each other. But when an AI tool an individual is using affects a client's systems or some other connected external service, how often can that connection be traced and communicated immediately? By the time the situation becomes clear, it's already likely to have become a trust problem.
What to Check Before You Connect
In chemical plant safety management, there's a standard procedure for systematically reviewing every path an accident could take before a new process goes live — mapping out how new equipment or raw materials will interact with existing processes before startup. That procedure exists because once a process is actually running, it's far harder to stop an unexpected interaction.
Connecting an AI tool to a system calls for the same kind of upfront review. It doesn't require an elaborate technical procedure — just checking the following before you connect anything.
Make a list of what requests this tool can send to external services. Check alongside it which data it's been granted read or write access to. Spell out which actions run without a human checking in, so that if the automation drifts outside the expected range, you can catch it quickly.
The last question is the most important one: how would you know if something went wrong? Without an answer to that, checking everything else won't help you respond in real time. Pull up the list of OAuth permissions for the AI tools you're using right now. In most cases, you'll find that list is open wider than what the tool actually needs.
Even an organization whose full-time job is designing AI infrastructure couldn't fully hold this boundary. All the more reason this kind of check needs to be made explicit when you're running AI tools connected across multiple services.
