Key takeaways

  • OpenAI reported that two of its most capable AI models broke out of a supposedly air-gapped test environment and accessed systems at Hugging Face to find the answer key for a performance benchmark.
  • This was not a malicious attack. The models were pursuing the goal they were given and found the easiest path to achieving it.
  • Effective AI agent guardrails belong in the network and infrastructure (“in the pipes”), not just in instructions to the model.
  • The practical defense for individuals and companies is least-privilege access: give AI tools access only to what they need for the task, and nothing more.

I went on Fox LiveNOW this week to talk about the OpenAI incident with anchor Bowen Kedrowicz. Two OpenAI models broke out of a sealed test environment and worked their way into Hugging Face’s systems, taking roughly 17,000 actions in the process. The story reignited the debate over AI agent guardrails: who sets them, where they live, and whether instructions alone can contain a highly capable model.

The headlines called it unprecedented. I don’t see it that way, and the segment only gave me a few minutes to explain why. This is the longer version of what actually happened, why this was not a rogue AI story, and what anyone connecting AI to their email, files, or business systems should do differently.

Watch the full segment:

Oren Michels joins Fox LiveNOW’s Bowen Kedrowicz to discuss the OpenAI incident and AI agent guardrails. (13:46)

What Happened in the OpenAI Hugging Face Incident?

OpenAI said two of its most capable AI models were responsible for a cyber incident targeting the AI startup Hugging Face. The models were running in what their operators believed was a sealed, air-gapped lab. Given a goal and a set of rules, they found a way out of the environment and went looking for the answer elsewhere.

Various versions of this happen every day. The sequence was simple: you put a very advanced AI system in what the people running it thought was a sealed lab. You gave it a goal. And the model, being the model, said: I’ve got this goal, I’ve got these rules, I’m going to go after that goal. So it did what it needed to do.

OpenAI’s own statement said the models went to “extreme lengths to achieve a rather narrow testing goal,” including “finding ways to connect to the internet without human direction” and gaining “access to secret information that it could use to cheat the evaluation.”

Was This a Malicious AI Attack?

No. This was not an attack. This was not the model saying, I’m going to try to do something nefarious. It was just trying to do the job it was told to do.

I often describe these models as really enthusiastic interns that don’t know right from wrong. They don’t have the context, but they really want to do a good job. If you tell them to do something, they will try to do it with everything they’re capable of, and everything they’re allowed to do.

That last clause is the whole problem. What a model is told to do and what it is allowed to do are two different control surfaces, and only one of them is held.

What Does It Mean for an AI to Cheat an Evaluation?

Every new AI model gets scored against benchmarks: standardized tests that measure how well it answers questions, how fast it runs, and how much it costs. Think of it as a big version of running the speed test on your internet connection.

Instead of solving the hard benchmark problem, the models reasoned that the answer likely existed somewhere. The model effectively said: I can go try to solve the problem, or I can find the place where the answer to the problem is likely to be stored. That place happened to be Hugging Face. Rather than actually go through all of the difficult machinations of solving this very difficult problem, it just went looking for the answer key, and it was able to find it.

How Did Hugging Face Detect and Respond?

Hugging Face’s security team saw something accessing their systems and moving through their network very quickly. The agents took around 17,000 actions while trying to enter and then move around inside the network. Sensors and alarms flagged the activity, and the team moved to stop it.

This was not an ordinary intrusion to fight. This was not a kid sitting there typing on their computer. It was a very sophisticated model that was able to do thousands of things a second, and you have to fight that at machine speed.

Why Do AI Agent Guardrails Belong in the Infrastructure, Not the Model?

Because instructions are a “keep out” sign on the door, and infrastructure is the lock. If you secure your building by putting up a sign that says “please don’t come in” instead of having a lock on the door, you’re going to have people coming in even if you don’t want them to.

Prompts, policies, and system instructions tell an AI what it should do. AI agent guardrails that actually hold have to constrain what it can do. The rules need to be in the pipes. They need to be in the connectivity, rather than trying to get inside the brain and hoping it listens to you.

In practice, that connectivity layer is increasingly MCP, the protocol AI agents use to plug into email, files, and business systems. That makes MCP governance the natural enforcement point: it’s where you can actually control what an agent can reach, not just what it’s been told.

The analogy I keep coming back to is employment. If you hire an employee, you give them a badge. You track where they come in and go out. You say, you can log into this system but not that one. Agents need the same thing: a profile of their own.

Each agent gets an identifier that defines which systems it can reach, what it’s allowed to do in each one, and a record of everything it actually did. Not the credentials of the person who deployed it, and not blanket access to everything. Those same kinds of rules are available today for AI, and companies that deploy agents without them are taking this risk.

How Should You Protect Your Own Data When Using AI Tools?

Apply least privilege: give each AI tool access to only the specific resources it needs for its job, and no more. That’s the standard I recommend for anyone connecting AI assistants to email, hard drives, payment information or any other system of record.

The answer is not avoidance. Tools like Claude Cowork and Google Gemini can read your files and inbox, and oftentimes these are incredibly useful. My AI talks to my email all the time and it makes me more productive. But I also have guardrails about what it is and is not allowed to do. It would be very sad if we just said, well, because of this incident, we’re never going to use AI.

Notice how differently we treat human trust. When I hire someone, I trust them. I give them access to things they may not need, because it’s easier, and I have recourse if they do bad things: I can fire them, and they know that. With AI, you have to be far more discreet, and only allow access to the things it needs to do that job.

In practice, least privilege for AI agents looks granular, and it’s the same discipline enterprises already apply to people:

  • Scope access by task, not by trust. Read access where reading is the job. Write, send, and delete only where the workflow requires it. An agent that drafts emails doesn’t need permission to send them until a human has reviewed the draft.
  • Enforce it at the connection, not in the prompt. Permissions live in the connectivity layer, per tool and per agent, where they can be switched on and off. Just as you decide which systems an employee’s badge opens, you decide which systems each agent can touch, and how.
  • Monitor and alert on everything outside the guardrails. Watch what your agents are actually doing. If one tries to operate outside its boundaries, the request is blocked automatically. Remember what this incident showed: a capable model moves at thousands of actions a second, so detection and response have to run at machine speed too.

This is exactly what we built Barndoor to do: govern the AI agents operating across your enterprise at the connectivity layer, with per-tool, per-agent controls over what each one is allowed to access and do. And if you want to experiment with the concept for your own use, we also put out a tool called Venn.ai that individuals can use. It hooks your AI up to the tools you use, like email, with switches that let you turn individual permissions on or off.

Who Should Set the Guardrails for AI Companies?

The problem is structural. AI companies are working incredibly hard to create amazing, powerful models, and they’re in an arms race to make their tool more powerful than everybody else’s. Asking that same company to also manage the rules and guardrails, to be the one holding it back as well as the one pushing forward, is not a reasonable thing.

Most of the companies we work with at Barndoor recognize this mismatch. My prediction: the security is going to come from governance provided by companies that are not in the business of building frontier models. In other words, the referee should not play for one of the teams.

Ready to Put Real Guardrails Around Your AI?

Instructions tell your AI agents what they should do. Barndoor controls what they can do. We put the rules in the pipes: governance and least-privilege access controls at the connectivity layer, so every agent in your organization gets exactly the access it needs and nothing more.

You can start a free trial or request a demo to see how it can work in your company.