The hackers never stole a password! They took over an employee's AI assistant instead
&imwidth=600&imheight=450&format=webp&quality=medium "The hackers never stole a password! They took over an employee's AI assistant instead")
The hackers never stole a password! They took over an employee's AI assistant instead Photograph: (OpenAI)
The most instructive step in the OpenAI breach was the pivot. Having taken over an employee's account, the researchers did not hunt for credentials to the internal code. They simply instructed the employee's AI coding assistant, which was already connected to OpenAI's private repositories, to act — proving that AI connectors are a new and under-guarded attack surface.
Every account takeover has a moment where the attacker turns access into damage. In the OpenAI breach, that moment is the one worth studying, because it did not involve stealing anything in the usual sense.
The researchers had compromised an OpenAI employee's account. To reach the company's internal code, they did not go looking for repository passwords or secret keys. They used the employee's AI coding assistant, which was already linked to OpenAI's private code, and told it to act on their behalf.
The Pivot
The employee's Codex — an AI coding tool — was connected to OpenAI's GitHub organisation, the home of its internal source code. That connection existed for a legitimate reason: it is what lets an AI assistant help a developer with real work.
Once the researchers controlled the account, that same connection became theirs to use. They sent the assistant a prompt asking it to open a change request inside the internal code repository, and it did — demonstrating access to code named in the company's private monorepo without ever having to crack the repository's own defences.
Why This Is A Different Kind Of Risk
Trending Stories
)
)
)
&im=FitAndFill=(700,400))
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
&im=FitAndFill=(700,400))
)
)
)
)
)
)
)
)
)
)
&im=FitAndFill=(700,400))
)
)
)
&im=FitAndFill=(700,400))
Traditional security thinks in terms of credentials: passwords, keys, tokens. Protecting a system means protecting the secrets that unlock it.
An AI connector does not fit that model. It is a standing, authorised bridge between a user's assistant and the real systems the user works on. The assistant holds the access so the human does not have to keep handing it over. That is convenient precisely because it removes a step — and it removes the same step for an attacker who takes over the account.
You do not need the key to the building if you can instruct someone already inside it. An assistant wired into a company's code, email or chat is exactly that someone.
The Surface Nobody Sized
Companies have spent years learning to protect credentials. Almost none have a mature answer for the question this raises: what is every AI assistant in the organisation connected to, and what can it do if the account behind it is taken over?
The researchers noted that the same foothold could plausibly have reached the employee's chat and email tools as well, through the same pattern of connected assistants. Each integration a company adds for productivity is another system an assistant can reach, and therefore another system a hijacked assistant can reach.
The Fair Counterpoint
None of this means connectors are a mistake. The productivity case for letting an AI assistant act on connected systems is real, and stripping it out would remove much of what makes the tools useful.
The problem is not that the bridges exist. It is that they have been built faster than the controls around them — the limits on what a connected assistant may do, the monitoring of when it does something unusual, and the assumption that a compromised account now means compromise of everything that account's assistants can touch.
What To Watch
Whether companies start inventorying AI connectors the way they inventory credentials and privileged accounts. Whether assistant integrations gain their own limits and alarms, rather than inheriting the full access of the human behind them. And whether account-takeover defences are rebuilt on the assumption that the prize is no longer the password, but the authorised assistant sitting behind it.
