Analysis frame
Mixed evidence
Compare the history reported by employees with the repairs the company says it tested. Distinguish changing the code from changing access on the machines that run it.
- Engineers who need access to shared code but not every project
- Security teams responsible for checking access across running services
- Organizations whose work depends on these services
- No public list links each warning raised internally to a date, owner and independently verified fix.
- The reports do not establish that a foreign government obtained model weights through the shared repository.
- Restricting access by project can limit the damage from a compromised account but slow legitimate work across teams.
- A dashboard that counts approved changes can overstate protection when some services still run the earlier version.
A useful question for a buyer
Ask a supplier for a redacted example of an access change: which class of accounts lost a privilege, how the company tested that loss on a live system, and what happened where an exception remained. None of that requires a map of the company’s source code. It tells a customer whether the follow-up test can fail honestly.
Go to the source
Read the evidence behind this analysis. External links open in a new tab.
Reuters — employees’ accounts and OpenAI’s response Reuters, accessible syndication via Investing.com OpenAI — November 2 plans for its next security sprint OpenAI — field notes on verifying repairs after deployment


