OpenAI’s security warnings show what an internal AI tool can find
Reuters reports that OpenAI staff warned for years about broad code access and internal tools that weren’t reviewed, and a court filing says a former engineer used an internal AI tool to find documents on executive travel. The lesson for every firm is that an AI search tool makes excess access easy to use. Authorization has to be checked at the data for each request.
What happened
Reuters reported on 3 November, citing five people, that OpenAI employees had warned for years about operational security lapses, starting before ChatGPT launched in late 2022. Some concluded that management put keeping pace with rivals ahead of security.
Two details stand out. Because most code sat in a single repository, anyone with code access could see details of many projects. OpenAI says that repository doesn’t hold all its code or the model weights. Three sources said internal tools such as research sandboxes weren’t regularly reviewed for security flaws, which OpenAI says it now does. One source said a senior product executive reassigned a quarter of production engineers to security infrastructure in August.
The story follows the October arrest of a former OpenAI engineer, who is accused of hiding a recording device in an executive conference room. According to a court filing cited by Reuters, he used an internal AI tool to find documents about executive travel to Saudi Arabia and about which officials would meet Saudi ministers. OpenAI told Reuters it is one of the most targeted organizations in the world, that it invests heavily in security and that protecting its technology, data and people is “a matter of national importance.”
My view
The striking part isn’t the recording device. It’s the search.
Every large firm has people whose access is broader than their job. I’ve run data governance at large banks and insurers, and access reviews were always the control everyone signed off and few fully trusted. It accumulates through role changes, project work and the path of least resistance when someone needs a folder today. For years that excess was partly protected by effort. Finding a sensitive document meant knowing it existed, knowing where it lived and spending time looking. Most people never did.
An AI tool removes the effort
An internal AI assistant removes that protection. Ask it a question in plain language and it searches everything the person can open, ranks it and summarizes it in seconds. If the permissions underneath are broad, the assistant makes the breadth usable. Nothing about the tool is malicious. It does exactly what it was built to do, on the access it was given.
That is why “the tool respects existing permissions” is a weaker assurance than it sounds. It is true and it doesn’t help if the existing permissions were never designed for a machine that reads everything at once. The control that matters is narrower: for this person, doing this task, which data should be reachable right now?
Shared repositories and sandboxes are the same problem
The monorepo point is the same pattern in engineering. A single repository is a reasonable design choice, and the reporting doesn’t say it was misused. But when code access is all-or-nothing, an AI coding assistant working for one engineer can read across every project in it. Internal tools and research sandboxes that aren’t reviewed add a second path, because they often run with broad service credentials and nobody owns their access.
None of this is unique to an AI lab. It is how most enterprises are set up today. The difference is that AI labs adopted internal AI tools first, so they meet the consequences first.
Why it matters
For the industry. Firms rolling out enterprise search, copilots and coding assistants are, in effect, running a live audit of their own entitlements. Whatever is over-shared will be found, by curious staff, by a compromised account or by an insider. Cleaning up access before rollout is slow, and few firms finish. The more reliable answer is to stop relying on the user’s full access and check each request against what the task needs.
How it connects to our work. Context Before Query is built around this: authorization is checked at the data for each request, before anything is retrieved, using who is asking, for what purpose and under which policy, rather than everything the account can open. Patterns and Product Fit covers the other side: labels that travel with the data, so a sensitive document stays restricted when an assistant quotes it. Three practical steps:
- Scope assistants by task. A support assistant reaches support content; it doesn’t search the whole drive because the user could.
- Treat internal tools as systems. Sandboxes and research tools get an owner, their own credentials and a security review on a schedule.
- Log retrieval, not just access. Record what an assistant retrieved for whom, so an unusual pattern of questions is visible.
Sources
- OpenAI employees warned about operational security lapses for years, sources say, Deepa Seetharaman, Reuters (republished by WMBD), 3 November 2026
Linked sources are the record. Check them for the full reporting.