What is a non-human identity?

For most of computing history, security was designed around people. You had users, each user had a password, and access control asked one question: is this the right human. That model was always incomplete, because software has been acting inside systems for decades under borrowed credentials. It became urgent the moment AI agents started doing real work, because an agent is software that decides and acts, and the old habit of letting non-human actors ride on a human's access suddenly carries much higher stakes. This post explains what a non-human identity is, why the category is growing, and why giving an AI agent its own scoped identity is safer than the shortcut most people reach for.

The definition is simple. A non-human identity is any actor that authenticates and acts inside a system but is not a person. The oldest examples are service accounts, the logins that let one system talk to another, and API keys, the tokens that let a script or an integration make requests on their own. Scheduled jobs and automations belong here too. What they share is that they hold access and take actions with no human clicking a button at the moment they run. That is precisely what makes them powerful and what makes them easy to forget.

Why the category is suddenly urgent

Non-human identities have quietly outnumbered human ones in many organizations for years, because every integration, every deployment pipeline, and every background job needs credentials of its own. The trouble is that they are often managed far more carelessly than human accounts. A person leaves and their account is disabled, at least in a company that offboards properly. But an API key created for a one-off script three years ago often lives on forever, with wide access, owned by nobody, remembered by no one. Attackers know this, and stolen or forgotten machine credentials are a well-worn path into systems.

AI agents pour fuel on this. An agent is not a static key sitting in a config file; it is an actor that reasons about a goal and takes a sequence of actions to reach it. That is genuinely useful, and it is also a new kind of exposure. If an agent runs with sweeping access and does something wrong, whether through a flawed instruction, a bad inference, or a manipulated input, the blast radius is whatever that access allowed. So the question of what an agent is allowed to do, and how you would know what it did, stops being academic. It becomes the core of whether the agent is safe to deploy at all.

The tempting shortcut, and why it backfires

When you first wire up an agent or an automation, the fastest path is to give it a human's credentials, or a copy of a human's access, and let it act as that person. It works immediately, which is exactly the problem. Now an automated actor is indistinguishable from the human in every record, holds whatever that human could reach, and inherits access that was granted for a person's job rather than the software's narrow task. The audit trail says the person did it, which is false, and the permissions are far wider than the work requires.

The consequences show up later, always at the worst time. When something goes wrong you cannot tell whether the human or the software acted, so accountability collapses. When the human changes roles or leaves, the automation silently inherits their new access or breaks entirely. And because the access was never scoped to the task, a compromise of the agent is a compromise of everything the borrowed human could touch. This is the same failure I describe in a post on least privilege: access granted broadly for convenience becomes a liability the moment anything goes wrong, and a non-human actor with a human's blanket rights is that liability in its purest form.

What a non-human identity actually needs

Treating an agent, a service account, or a key as a first-class identity means giving it three things it usually lacks. The first is a scoped set of permissions, granted to the task rather than the person, so the actor can do exactly what its job requires and nothing beyond it. The second is its own attribution in the record, so that when it acts, the log says the agent did it, not some human it was impersonating. The third is a lifecycle: an owner, a reason it exists, and a point at which it is reviewed and retired. An identity that nobody owns and nobody reviews is the one that becomes a hole in the wall.

Why identity is the safer frame for AI agents

Put those pieces together and the argument becomes clear. If an AI agent has its own scoped identity, then the question "what can this agent do" has a precise, reviewable answer instead of "whatever some person can do." If it has its own attribution, then the audit trail tells the truth about which actions were automated, which is the only way to trust an agent with anything consequential. And if it has a lifecycle, it does not linger as a forgotten set of wide permissions after the project that created it is over. None of this slows the agent down. It simply makes the agent something you can reason about, which is the precondition for handing it real work. I explore where that trust should and should not extend in a piece on delegating judgment to AI.

How the Atlas assistant is built around this

I will tie this to something concrete, honestly, because the Atlas assistant is built on exactly this principle rather than the shortcut. The assistant does not get its own blanket access to everything. It acts under the acting person's permissions, so it can never reach data or actions that the person could not reach themselves, and consequential actions go through an approval step rather than happening silently. Every action it takes is written to the audit log, attributed and timestamped, on the same footing as a human action. That last part is the point of this whole essay in practice: an automated action is held to the same standard of accountability as a person's, so you can always answer what the assistant did and confirm it stayed within bounds.

I want to be careful about what that does and does not claim. Acting under a person's permissions is a deliberate safety boundary, and it is a different design from a machine identity that holds standing rights of its own. It means the assistant is constrained by a human's access rather than granted an independent, wider set, which for an assistant that works across your own data is the more conservative and, I think, the more honest choice. wrxstack is an AI work platform, not an identity provider, and it does not sell non-human identity management as a product. What it does is apply the principle to its own assistant, and you can read exactly how the permission and logging model works on the security page.

Secrets are the part everyone underestimates

A non-human identity proves who it is with a secret, usually a key or a token, and that secret is where most machine-identity failures actually begin. A password lives in a person's head; a machine credential has to live somewhere a program can read it, which means it ends up in config files, environment variables, and, far too often, pasted into a shared document or committed into source code by accident. Once a secret leaks, it grants exactly the access it was issued, to anyone holding it, with none of the friction a stolen human password meets. There is no second factor to slow an attacker down, and the credential rarely announces that it has been copied.

The disciplines that contain this are unglamorous and worth insisting on anyway. Give each identity its own secret rather than sharing one across many actors, so a leak can be traced and revoked without breaking everything at once. Rotate secrets on a schedule, so a copy taken quietly still expires. Keep them out of source code and out of chat, in a store built to hold them. And treat the day a person with access to those secrets leaves as a reason to rotate, because a secret they could read is a secret they may still hold. None of this is exotic, but it is skipped constantly, and the forgotten key with wide access is the classic way a machine identity becomes the weakest point in an otherwise careful system.

What to ask before you deploy an agent

If you are about to give an AI agent or an automation access to real systems, a few questions save a great deal of regret. Ask what identity the agent acts under, and if the answer is "a person's," ask what happens when that person changes roles or leaves. Ask exactly what the agent is permitted to do, and whether that access is scoped to its task or inherited wholesale. Ask how its actions are recorded, and whether the log distinguishes the agent from the humans around it. Ask who owns the identity and when it will be reviewed. If a vendor cannot answer these cleanly, the agent is not ready for anything that matters, no matter how impressive the demonstration looks.