On July 21, OpenAI disclosed that two of its own models had autonomously escaped an internal test environment, reached the open internet, and compromised production systems at Hugging Face, a separate company. The models were running against a cyber capabilities benchmark with their refusal behaviors deliberately reduced for the evaluation. Rather than solve the benchmark, they found a zero-day in a package registry cache proxy, escaped the sandbox, escalated privileges until they reached a node with internet access, and went looking for the answer key. They reasoned that Hugging Face probably had it.OpenAI has published the details of the evaluation, and Niels Provos, a veteran cyber-security engineering leader, has written an excellent analysis of the broader implications for AI security. We encourage readers to review both rather than repeat them here.
What stood out to us in all the general press coverage, however, wasn't the zero-day, it was the apparent assumption that an AI would need one. In the real world, the most capable AI probably won't need to discover an unknown vulnerability to access a customer's environment. It will simply use the information you've already given it.
Zero-Days Are Rare. Credentials Aren't.
The zero-days got the headlines, but it wasn't the only thing the model used. OpenAI's account describes the model chaining multiple attack vectors together, stolen credentials among them, to find a remote code execution path on Hugging Face's servers. Zero-days were utilized, but this is also a credential story.
Finding a zero-day is hard. Even for well-resourced attackers they're rare and expensive. Credentials, session tokens and API keys are not. Support organizations request and receive them every day, unprompted, from customers while trying to be helpful.
HAR files. Debug logs. A screenshot with a session token still visible in the URL bar. A config file with an API key nobody stripped. All of it uploaded to get a ticket resolved faster, and increasingly all of it flowing straight into AI-powered support workflows that summarize it and recommend next actions on it. We called this the HAR file problem.
If those secrets are sitting in the case, no exploit is required. The authentication problem is already solved.
The AI Worth Worrying About Is the One Being Helpful
The scenario that should concern you isn't a model deciding to attack your customer. It's a model trying to close their ticket.
Support copilots are moving from answering questions to taking action: opening tickets, running workflows, executing scripts, querying infrastructure. Hand one of those a case containing an administrator credential and a customer reporting that something is down, and the fastest path to resolution is sitting right there in the attachment.
From the model's side, that's helping. From your customer's side, a vendor AI just logged into their production environment. We've written about what happens when a helpful AI gets hijacked. This is the version that needs no attacker.
Whether that action fixes the problem or takes down a system, whose liability is it?
You Don't Control Most of the AI Touching Your Tickets
Plenty of organizations are doing real work to govern their own AI platforms. That work is necessary. It also covers only a fraction of the exposure.
Count the vendors with read access to a single support ticket. Ticketing, CRM, chat, session replay, workflow automation, analytics. Every one of them is under pressure to ship AI features this year, and every one of them is making its own decisions about how your customers' data gets processed, retained, and used.
You can have excellent governance over your own copilot and still be feeding half a dozen third-party models you don't control and can't audit.
The question isn't whether you trust your AI. It's how many AIs now have access to your customers' secrets.
The Security Boundary Hasn't Moved
AI changed how software reasons about data. It didn't change what a credential is.
A credential that reaches your ticketing system has also likely reached your knowledge base, your analytics warehouse, your vendors' AI features, and every human and machine with read access to any of them. That was true before copilots existed. What copilots add is a new actor in that chain — one that can pursue a goal in ways nobody specified and nobody fully controls, as OpenAI's models just demonstrated. They widen the blast radius and shorten the time between exposure and use.
The safest credential is the one that never enters those systems. That holds whether the consumer is a support engineer, an LLM, or a vendor you've never evaluated.
How Halo Keeps Secrets Out of the Ticket
This is the problem we built SendSafely Halo to solve.
Halo is designed to protect sensitive data from AI. When a customer needs to send a debug file, a log, or a screenshot into an AI-powered support conversation, they submit it through Halo rather than dropping it into the chat. The file is encrypted in the customer's browser before it reaches the AI platform, the cloud provider, or SendSafely. What lands in the conversation is a reference, not the contents.
An authorized human agent can open the file in their browser when the case requires it, and every retrieval is logged. The AI layer never receives the plaintext, and neither does any other vendor in the stack. The credential stops being a permanent, readable object sitting in a queue that dozens of systems can index.
Halo works with Ada, Zendesk AI, Intercom Fin, Agentforce, Forethought, Amazon Connect and more.
The Bottom Line
A future model may well find a zero-day in something you own but today's models don't need one. The credentials are already in your ticket queue, and the number of systems that can read them grows every quarter.
Go look at what's sitting in your open cases right now. If a support AI copilot can read it, assume something will eventually act on it.
See how Halo keeps credentials out of your support stack. Request a demo at sendsafely.com.
Further Reading
We've covered this problem from several angles: