HACKR.GG
API keys, service accounts and OAuth tokens now outnumber employees 45 to 1 — and almost none of them have MFA, rotation, an expiry date or an owner. Here's why machine credentials are harder to defend than passwords, and how one forgotten 2022 credential reached 200 organisations.
Ask a company how many employees it has and you will get an exact number. Ask how many API keys, service accounts, OAuth tokens, CI secrets, webhook signing keys and workload identities it has, and you will usually get a pause.
That pause is the vulnerability. Machine identities now outnumber human ones by roughly 45 to 1 in a typical enterprise, and by as much as 144 to 1 in cloud-native and DevOps-heavy environments. Every one of them is a credential that authenticates to something. Almost none of them have an owner, an expiry date, or anyone who would notice if a stranger started using them.
A stolen employee password is a bad day with a well-rehearsed response. MFA probably blocks it, the login looks anomalous, the account gets disabled, everyone moves on. A stolen API key has none of those brakes.
| Human credential | Machine credential | |
|---|---|---|
| Second factor | Enforced almost everywhere | Structurally impossible — nobody is there to approve |
| Rotation | Policy-driven, often automatic | Manual, disruptive, so usually never |
| Offboarding | Triggered by HR the day someone leaves | No equivalent event exists |
| Ownership | The person it belongs to | Frequently nobody — the author left years ago |
| Scope | Tied to one role | Often broad standing access no human would be granted |
| Anomaly detection | Odd location or hour looks wrong | It is automation. Odd hours are normal. |
That last row is the one defenders underestimate. Automated traffic at 3am from a datacentre IP is precisely what a service account is supposed to look like. An attacker using a stolen machine credential is not hiding in the noise — they are indistinguishable from the signal.
This is not a hypothetical exposure. SpyCloud's 2026 Identity Exposure Report recaptured 18.1 million exposed API keys and tokens from 2025 alone, spanning cloud providers, payment platforms and developer services. Stolen credentials remain the single most common initial access vector, appearing in around 22% of breaches, and 88% of basic web application attacks involve them.
The reason so many leak is that secrets end up in places nobody thinks of as published:
git history — deleted from HEAD, still in an old commit frontend bundles — an API key compiled into main.js CI/CD logs — echoed by a debug step, retained for a year container layers — ENV set in an early Dockerfile layer mobile apps — decompile the APK, read the strings public buckets — .env backed up next to the assets error pages — a stack trace with a connection string issue trackers — pasted into a ticket "temporarily"
June 2026 produced an almost perfect case study. Klue, a market intelligence SaaS provider, was breached between 11 and 24 June by a threat actor tracked as Icarus. The entry point was not a zero-day or a phished employee.
It was a credential Klue issued in 2022 for a limited pilot, which then sat live and unmonitored for roughly four years.
Nearly 200 organisations were affected, including security vendors — Huntress, Recorded Future, Tanium and Jamf among them. Salesforce disabled the Klue integration in response.
The part worth sitting with: none of those 200 companies were breached. Their controls worked. Their staff did nothing wrong. They had authorised an integration, which is a completely ordinary thing to do, and the token issued for it turned out to be reachable through somebody else's forgotten credential.
From an offensive perspective this is a recon problem before it is an exploitation problem, and it rewards patience over cleverness.
The honest answer is that this is an inventory problem wearing a security costume. You cannot rotate, scope or revoke credentials you do not know exist.
| Step | Why it matters |
|---|---|
| Inventory every non-human identity | Nothing else on this list is possible without it. Expect the count to be several times higher than anyone guesses. |
| Give every credential a human owner | Not a team — a person. The Klue credential survived four years precisely because it belonged to nobody. |
| Set an expiry on everything | A credential that expires by default converts "we forgot" from a breach into an outage. An outage is the far better failure. |
| Scope to the single task | Broad standing access is what turns one stolen token into 200 affected organisations. |
| Scan for leaked secrets continuously | Pre-commit hooks stop new leaks; history scanning finds the ones already shipped. |
| Audit third-party OAuth grants | Review what you have authorised, and revoke integrations nobody uses. Every live grant is standing access into your data. |
Because AI agents are machine identities, and organisations are deploying them fast. Every agent needs credentials to be useful, those credentials tend to be broad so the agent can handle whatever it is asked, and they are standing rather than per-task. That is the same pattern described above, being created at speed, in a context where the credential holder can also be talked into things by anyone who can put text in front of it.
The organisations that struggle with this over the next few years will not be the ones with weak cryptography or unpatched servers. They will be the ones that could not answer a simple question: what credentials do we have, what can each of them reach, and who would notice if one of them started behaving differently?
Everything in this post has a hands-on lab on hackr.gg. Exploit it yourself right inside the lesson — no setup, no install, runs in your browser.
Open Secrets & Credential Discovery course →