What are non-human identities, and why AI agents make them the biggest hole in your security

A non-human identity is any credential that lets software, rather than a person, do something: a service account in your cloud, an API key for a model provider, an OAuth token a SaaS app holds for your GitHub organisation, a CI runner's deploy token, a certificate a microservice presents to another, and increasingly the identity an AI agent carries when it calls tools on your behalf. Most organisations have far more of them than they have employees, often by a factor of ten or more, and almost none have an owner, an expiry date or a record of what they are allowed to do.

Why they are different from people

Human identities get the controls: multi-factor authentication, single sign-on, an offboarding process, a manager who notices when someone leaves. Non-human identities get none of that by default. They are created by whoever needed them, pasted into an environment variable or a CI secret, and forgotten. They do not rotate when the person who made them leaves. They cannot do a second factor. And they are usually over-privileged, because the fastest way to make a deployment work at 2 a.m. is to grant the token everything.

The Railway incident report published this week is a textbook case. A credential meant only for build work was accepted by an internal workflow service as a trusted client; a cloud role binding was defined too loosely; and a long-lived decryption credential sat on a machine the attacker could reach. None of those were human accounts. The result was about 100,000 workspaces' secrets potentially exposed and $740,000 of fraudulent AI charges on the keys that were decrypted.

What AI agents add

An agent is a non-human identity that makes decisions. When you give an agent a tool, you give it a credential, and the agent will use that credential in ways you did not script, because that is the point. Three new problems follow. Delegation: an agent acting for a user carries the user's authority, so a prompt injection in a document the agent reads becomes a request made with that user's rights. Blast radius: an agent with a broad key can reach every system that key reaches, and it will explore. Attribution: when something goes wrong, the audit log shows the service account, not the user who asked or the input that steered it. The Operation Snowball reconstruction last week showed an open-weight agent pulling dozens of credential sets from a telecom's network over two weeks; every one of those was a non-human identity nobody was watching.

The market for stolen keys

A stolen AI provider key is now cash. Railway and Wiz observed keys tested within 30 minutes of theft and flooded with traffic days later, used for coding agents and training pipelines and, Railway believes, resold for distillation. Google calls the pattern LLMjacking. The economics are simple: compute is the expensive input to AI, your key buys it on your account, and the thief needs no exploit beyond the key.

How to get control

Start with an inventory, because you cannot scope what you cannot count. Cloud IAM exports, secret-manager listings, CI variable stores and the OAuth app pages of your SaaS tools are the four places most keys hide. Give every identity an owner and a purpose written down. Then scope: a build token talks to the build system and nothing else; a model key is restricted to the models and regions the application uses and has a hard monthly spend cap; an agent gets a credential per task, not per agent. Prefer short-lived credentials issued at runtime through workload identity or OIDC over static keys in environment variables, and review the trust bindings that issue them as carefully as you review IAM policies, since a loose binding is what gave Railway's attacker a cloud credential. Log every decryption and every use, not just every login, and alert on usage that does not match the owner's stated purpose. Finally, make revocation a button: the ability to kill every key an app holds in one action is the control that turns a breach from a week into an hour.

Where this is going

Identity vendors are rebranding around 'agent identity', standards bodies are drafting ways for agents to present verified credentials to merchants, and United Airlines this week banned agents from its site largely because customers hand their logins to tools it cannot see. The direction is that agents will carry their own identity, separately from the human who delegated to them, with its own scope and its own audit trail. Until that exists in your stack, the practical rule is the one Railway learned: treat every non-human credential as stolen until you know what it can do, and make sure the answer is 'not much'.