Every account takeover has a turning point the moment an attacker converts access into actual damage. In the recent OpenAI breach, that moment stands out because it didn’t involve stealing anything in the conventional sense.
The researchers had already taken over an OpenAI employee’s account. But instead of hunting for repository passwords or secret keys to reach the company’s internal code, they simply used the employee’s AI coding assistant and told it to act on their behalf.
The Pivot
The employee’s Codex, an AI coding tool, was linked to OpenAI’s GitHub organisation, home to its internal source code. That connection existed for a perfectly legitimate reason: it’s what allows an AI assistant to help a developer with real, everyday work.
But once the researchers gained control of the account, that same connection became theirs to exploit. They sent the assistant a prompt instructing it to open a change request inside the internal code repository — and it complied, demonstrating access to code within the company’s private monorepo without ever needing to break through the repository’s own security defences.
Why This Is a Different Kind of Risk
Traditional security thinking revolves around credentials — passwords, keys, tokens. Protecting a system, in this model, means protecting the secrets that unlock it.
An AI connector doesn’t fit neatly into that framework. It functions as a standing, authorised bridge between a user’s assistant and the real systems that user works with. The assistant holds onto that access so the human doesn’t have to keep re-authorising it — a convenience that works precisely because it eliminates a step. Unfortunately, it eliminates that same step for an attacker who takes over the account.
You don’t need the key to the building if you can simply instruct someone who’s already inside it. An assistant wired into a company’s code, email or chat systems is exactly that insider.
The Surface Nobody Sized
Organisations have spent years learning how to protect credentials. Almost none have a mature answer to the question this incident raises: what is every AI assistant across the organisation connected to, and what could it do if the account behind it were compromised?
The researchers noted that the same foothold could plausibly have extended to the employee’s chat and email tools too, through the same pattern of connected assistants. Every integration a company adds for the sake of productivity becomes another system an assistant can reach and therefore another system a hijacked assistant can reach as well.
The Fair Counterpoint
None of this suggests that connectors themselves are a mistake. The productivity case for letting an AI assistant act across connected systems is genuine, and removing that capability would strip away much of what makes these tools valuable in the first place.
The real problem isn’t that these bridges exist it’s that they’ve been built faster than the controls needed to govern them: limits on what a connected assistant is allowed to do, monitoring for when it behaves unusually, and a working assumption that a compromised account now effectively means compromise of everything that account’s assistants can reach.
What to Watch
Whether companies begin inventorying their AI connectors the same way they inventory credentials and privileged accounts. Whether assistant integrations start receiving their own dedicated limits and alerts, rather than simply inheriting the full access of the human behind them. And whether account-takeover defences get rebuilt around a new assumption — that the real prize for attackers is no longer the password, but the authorised assistant sitting quietly behind it.