Earlier this year, in March 2026, attackers stole an artificial intelligence (AI) provider key from the nonprofit METR (which evaluates the capabilities and risks of advanced AI systems). They established persistence and consumed credits worth roughly $600,000 over three weeks. The abuse blended into METR’s legitimate high-volume activity, so nobody immediately noticed. No clandestine hooded figure defeated a retinal scanner, just a simple working API key.
That incident is, in a nutshell, one of the biggest dangers of non-human identities: legitimate credentials, legitimate permissions, illegitimate purpose, and very little friction.
What’s a non-human identity?
The Cloud Security Alliance’s 2026 definition of non-human identity is laser precise. A non-human identity (NHI) is an entity that can authenticate and receive authorization to access resources. Service accounts, applications, workloads, application programming interface (API) clients, devices, automation, and AI agents all qualify.
The identity isn’t the credential. A token, certificate, or key proves the identity and may authorize an action. Rotating a key doesn’t fix a badly governed machine identity, and putting an overprivileged credential in a vault doesn’t magically create service account security.
Invisible identities don’t retire
Human access usually begins with hiring and ends with departure. NHIs are born from deployments, pipelines, integrations, and autoscaling. There’s often no authoritative event to remove them.
The result is orphaned accounts with no clear owner, purpose, or expiration. Nobody disables them because nobody knows what will break. They accumulate into identity debt: risk we understand vaguely and postpone professionally.
Every NHI needs a business owner, technical owner, purpose, environment, creation source, credential inventory, and retirement trigger. If we can’t explain even just one, it shouldn’t retain production access.
Credentials escape and remain useful
A 2026 academic study analyzed ten million webpages and found 1,748 distinct exposed credentials across nearly 10,000 pages, sometimes exposed for years. JavaScript build processes were a common cause.
Once leaked, compromised credentials can bypass controls designed for interactive users. Bearer tokens also invite token replay: possession becomes permission, with no phishing conversation required.
- Independent SANS research found that only 8% of respondents rotated more than 75% of NHI credentials every 90 days. It also found 75% reporting growth in service accounts and API keys. The 2026 SANS findings make the mismatch plain: the population is growing faster than its hygiene.
We should prefer workload federation, managed identities, and short-lived tokens. Where static secrets remain unavoidable, centralize storage, scan build and runtime environments, rotate automatically, and test revocation. “We rotate annually” isn’t a control; it’s just a reminder in a Google calendar.
Excessive access turns one key into an attack chain
NHIs often receive broad permissions because troubleshooting narrow access is inconvenient. Temporary grants then become access creep, giving one compromised workload a route to production data, cloud control planes, and new credentials.
Effective cloud infrastructure entitlement management must connect identity, credential, effective entitlement, and actual use. We must enforce the principle of least privilege, separate development and production identities, and challenge unused access before an attacker does.
Shared identities erase accountability
Logs may show that a service account changed a policy without showing which application, pipeline, person, or agent initiated it. Shared accounts turn incident response into archaeology.
Organizations need to preserve identity provenance across every delegation: original sponsor, workload, credential, authorization decision, and downstream action. Then, pair it with continuous identity security, because a quarterly certification won’t catch a token being abused at machine speed right now.
AI agents raise the stakes
An agent isn’t merely a credential holder. It selects tools, interprets untrusted content, changes plans, and may delegate to other agents via agent-2-agent protocol (or equivalent).
- NIST’s 2026 agent identity concept paper highlights identification, authorization, auditing, non-repudiation, and prompt-injection resistance as unresolved implementation concerns.
- Joint 2026 guidance from CISA, NSA, and international partners recommends limiting autonomy, avoiding broad access, strengthening identity management, and monitoring continuously. That guidance should shape every AI agent security review.
We have to give each agent a unique identity, narrow tool allowlists, task-bound authorization, transaction limits, and a kill switch. We must require human approval for destructive, financial, or high-impact actions. Agents are remarkably productive colleagues, but root access shouldn’t be an automation gift during onboarding.
Reducing the dangers of non-human identities
Start by inventorying every NHI and linking it to an owner, workload, credentials, and effective permissions. Remove unused access, replace persistent credentials, monitor behavior, and automate retirement through deployment workflows. Map the program against the OWASP Non-Human Identities Top 10 so lifecycle, third-party, and incident-response gaps aren’t forgotten.
Organizations need to move privileged NHIs toward zero standing privileges and just-in-time access wherever the workload permits. Track ownership coverage, credential age, unused permissions, shared accounts, time to revoke, and whether every action can be traced to a responsible sponsor.
NHIs aren’t “inherently dangerous.” Anonymous, permanent, and overprivileged access is. The machine won’t resign, complain, or ask whether it still needs administrator rights. That’s still our job.
Find the identities nobody remembers creating
Download our free product trial to uncover orphaned service accounts, unused entitlements, and excessive standing privileges across cloud environments. Trustle helps us see who, or what, has access; ask plain-English questions; remove what isn’t needed; and move appropriate permissions toward controlled, just-in-time access.
