The AI didn't break in. It logged in with keys someone left lying around.

Strip the drama out of the Hugging Face incident and the opening move was mundane. Before any clever exploit, an AI agent went looking for login credentials, found working ones sitting in a public dataset, and used them. Hugging Face's own disclosure confirms the attacker moved with valid credentials, not by smashing down a door.

The exciting part of the story is the zero-day exploits that came later. The important part, for you, is the boring bit at the start.

The scale of the problem is difficult to overstate

The week the incident was dissected, security researchers published the results of scanning every public dataset on Hugging Face — 7.6 petabytes across 187 million files. They found 221,303 live, working credentials. Among them were 787 Hugging Face tokens, 237 of which could write to the platform and 70 of which held organisation-admin rights. There were also 349 GitHub tokens, 223 with full write access to code.

These are not old passwords. They are keys that still open doors, left inside data that anyone — or any agent — can download.

Scanning 7.6 petabytes of public AI training data turned up 221,303 working credentials, including 70 Hugging Face tokens with organisation-admin rights and 223 GitHub tokens with full write access to code.

The uncomfortable truth is that this is normal. Credentials leak constantly, into code, logs, datasets and config files, and they stay valid for years. GitGuardian's 2026 analysis found that 64% of the valid secrets it discovered in 2022 were still active when retested at the start of 2026. Nobody rotated them. Nobody was looking.

Why AI agents make this so much worse

Leaked credentials have always been a risk. Two things about AI agents turn a slow-burning problem into a fast one.

Agents are tireless and thorough. A human attacker with a stolen key tries the obvious doors. An agent tries every door, at machine speed, and does not get bored. In the Hugging Face case, most of the thousands of individual actions went nowhere — but the sheer volume meant that enough of them landed to build a working attack chain. Volume is the new threat, and volume is exactly what automation is good at.

Agents are identities you cannot see. Every AI agent you deploy needs credentials of its own to do anything useful — to read your data, call your systems, act on your behalf. These "non-human identities" already outnumber human employees by roughly 109 to 1 in a typical organisation, and 60% of them hold long-lived secrets that never expire. Each one is a key. Most were issued without much thought about what happens if it is stolen or misused.

The question you are not asking your supplier

Here is the awkward pattern we see repeatedly. An organisation commissions an AI build. The supplier, entirely reasonably, needs access to make it work — a database connection, an API key, a service account. That access gets granted once, broadly, early, so as not to slow the work down. And then nobody ever revisits it.

Six months later the agent that was supposed to summarise support tickets has standing write access to the whole customer database, an admin token for a system it touches once a quarter, and a key that would still work if the laptop it lives on were stolen tomorrow. None of that is malice. It is the path of least resistance, and it is the same shape of gap that let the Hugging Face attack begin.

The single most useful question a non-technical buyer can ask is not technical at all:

"What can this system log into, and does it need all of it?"

A good supplier can answer immediately, because they have thought about it. A weak one will need to go and find out — which is itself the answer.

What good looks like

You do not have to audit anything yourself. You are listening for whether these principles are already in place:

• Least privilege. The agent can reach what it needs for its actual job and nothing more. An agent that summarises tickets has no business holding write access to finance.
• Short-lived credentials. Keys that expire on their own, quickly, so a leaked one is worthless within hours rather than years. The reason those 221,303 credentials were dangerous is that they never expired.
• Someone knows the full list. There is a map of every credential the system holds, who issued it, and what it opens. If nobody can produce that map, nobody can protect it.
• Rotation actually happens. Keys are changed on a schedule, not "when we get around to it". The evidence says almost nobody does this, which is precisely why it is worth checking.

The point most vendors would rather you didn't reach

Compromised credentials are so effective because they do not look like an attack. IBM's 2025 breach research found that breaches beginning with stolen credentials take up to 186 days to spot, for the simple reason that a valid login looks exactly like an authorised one. When your AI agent uses a key, and an attacker uses the same key, your logs cannot tell them apart.

That is why this is not a problem you can inspect your way out of after the fact. It has to be designed in — least privilege and short-lived credentials from the start — and it has to be checked by someone whose job is not to ship the feature by Friday.

This is the same argument we made about telling whether your software supplier is doing a good job: what matters most is what you cannot see, and what the supplier has no particular reason to raise. Credentials sit at the top of that list, and an AI agent turns every unnecessary key you are holding into something that can act on its own.

If a build is already underway and nobody on your side of the table can answer the access question, that is what design authority is for — an independent technical voice reviewing the architecture, the access and the estimates, roughly a day or two a month, from £1,500. It does not require a proof of concept first; a build you are already unsure about is reason enough.

It works for the same reason the rest of this does: the person asking what your agent can reach has no stake in the answer being "nothing to worry about".