Welcome to LISA
KELLY YIP from LISA
Last week, OpenAI disclosed that one of its internal AI security evaluations resulted in its models’ exploiting vulnerabilities beyond their intended test environment, compromising Hugging Face’s infrastructure. The incident has sparked fresh debate about how AI systems should be governed.
OpenAI was running an internal evaluation with its most advanced models, within a sandbox environment. It’s suggested that the usual production safeguards were deliberately switched off to see the true capability of the latest models. During that test, the models found a zero-day vulnerability, and used it to escalate privileges, and eventually reached the open internet.
Once online, the model likely reasoned that Hugging Face was hosting the answers it needed to solve its benchmark. So, with the same zero-day approach, it chained stolen credentials to find a remote code execution path into Hugging Face’s production infrastructure.
The incident, which occurred without any human interaction, has been labelled as “unprecedented” by OpenAI, and has raised a number of concerns around the conversation of AI. Furthermore, recent investigations suggest that Hugging Face might not have been the only company exposed.
Let’s strip away the AI framing for a second and ask ourselves what actually happened here. Ultimately, it seems that a piece of software was provisioned with compute, credentials, and network access – it operated well outside the boundary anyone had defined for it before its owner noticed.
When you look at it from that perspective, you realise that this isn’t really a new thing. In fact, that’s probably the oldest story in ITAM.
We’ve spent years chasing unlicensed installs, orphaned service accounts, and shadow SaaS that nobody remembered to switch off. In many ways, an AI agent with excessive permissions and access to vulnerable systems is simply the latest version of a problem ITAM has been dealing with for years.
It’s currently estimated that 88%* of organisations have a confirmed or suspected AI agent security incident in the past year. This is a risk that the technology world needs to acknowledge and address.
SecOps is built to catch threats once they’re moving. But nobody can secure an asset they don’t know exists, or don’t own. That’s ITAM’s job, and it always has been. The difference now is that the “asset” in question can make its own decisions about where to go next.
If the last two years were about bringing SaaS sprawl under control, the next two are about doing the same for AI agents, and the stakes just got a lot higher. In practice, that means:
For a while now, those of us in ITAM have been saying that AI needs to be tracked, licensed, and governed like any other asset. This month, that argument was made for us, by an AI that found the edge of its own sandbox and kept going.
The question isn’t whether AI agents need proper governance anymore, It’s whether ITAM steps up to own that discipline. If you want to get ahead of this rather than react to the next headline, our AI Asset Management Fundamentals course is a good place to start bringing AI under proper ITAM control.
