Your Agents Are Non-Human Identities. You Are Managing Them Like Service Accounts.

There is a number that should reframe how every security team thinks about agents. In its 2025 Identity Security Landscape report, CyberArk found that machine identities now outnumber human identities by more than eighty to one. Service accounts, API tokens, CI runners, bots — the non-human population of your environment has quietly become the overwhelming majority of the things that can authenticate and act. Agents are the newest entrant in that population, and the fastest-growing. They are also the only members of it that decide for themselves what to do next.

The discipline that governs the rest of that population is non-human identity management, and the field has matured fast enough that OWASP published a Non-Human Identities Top 10 in 2025 — a ranked list of the ways machine credentials get over-provisioned, leaked, left orphaned, and abused. Read it with agents in mind and the document reads less like a checklist and more like a forecast. Every failure mode it describes for a static service account is worse for an entity that reasons, chains tools, and acts on its own initiative.

A Service Account Does Not Decide; An Agent Does

A traditional service account is a credential attached to a fixed script. It does one thing, the same way, every time. Its blast radius is whatever that script was written to do, and a human wrote the script. You can reason about it because its behavior is bounded by code that does not change between runs. Over-provision it and the risk is latent — it only matters if the script is compromised or the code has a bug.

An agent holding the same credential is a different kind of principal entirely. It does not run a fixed script; it generates its plan at runtime, in response to inputs you do not fully control. Over-provision it and the risk is not latent — it is active, every time the agent decides the broad grant is the efficient path to its goal. The credential is identical. The thing behind it has stopped being deterministic. We carried over the identity model for service accounts and applied it to a principal that violates the one assumption that made that model safe: that behavior is fixed.

Borrowed Identity Is the Default, and It Is the Problem

Most agents in production today do not have an identity of their own. They authenticate with a human user's OAuth token or a shared service account, and they inherit whatever that identity is permitted to do. From the perspective of every downstream system, the agent is invisible — there is only a valid credential making valid calls. This is the same observation behind the authorization gap, viewed from the identity side: you cannot authorize what you cannot name, and you cannot prove what an agent did if its actions are indistinguishable from the human or service whose token it borrowed.

Distinct agent identity is the precondition for everything else. Before you can scope an agent's permissions to its task, before you can record who delegated its authority, before you can prove after an incident that a boundary held, you have to be able to say which agent acted — not which token it used, but which agent, accountably and on its own. An agent without its own identity cannot be held to a least-privilege grant, because the grant belongs to the human it is impersonating. It cannot be audited, because the log shows the human. It cannot be revoked without revoking the person.

Least Privilege Was Already the Hard Part

The OWASP NHI list keeps returning to one root cause: over-permissioned identities that no one scoped down because scoping is tedious and broad grants just work. That failure is endemic even for static service accounts, which at least behave predictably. Hand the same over-broad grant to an autonomous agent and you have built the exact precondition for the incidents the industry is now living through — an entity with operator-level reach, no boundary distinguishing a permitted action from an authorized one, and the autonomy to take the permitted action the moment it judges it efficient.

The fix is not novel in principle; it is the oldest principle in security applied to a new principal. Each agent gets its own identity. That identity is granted the narrowest set of capabilities its task requires, decided on purpose by someone who can be named. The grant is enforced at runtime, where the action actually happens, not assumed from the fact that a credential validated. And every enforcement decision is recorded so the delegation chain can be reconstructed. Which agent, authorized to do what, delegated by whom, and provable after the fact.

Start by Counting the Agents You Cannot See

You cannot apply non-human identity discipline to agents you have not enumerated, and most teams have not. The first move is the same as everywhere in this thesis: look. The Agent Environment Review inventories the agents operating in your environment, the identities they authenticate as, the capabilities each one holds through that identity, and where a single borrowed credential has handed an autonomous principal more reach than anyone decided to grant. It does this from metadata — local-first, without uploading source or secrets. It does not produce a score. It produces the one artifact non-human identity management has always depended on and agents have so far escaped: an accurate count of the principals you are responsible for, and what each of them is permitted to do.

Read the Full Argument

The Authorized Agent: Identity, Authorization, and Audit for AI Agents in Production is Book One in the DeepSweep.ai Thesis series. It develops agent identity from the existing discipline of non-human identity management into a runtime authorization model for autonomous principals.

Available now on Amazon: https://www.amazon.com/dp/B0GWV9FGDF

DeepSweep is the productized thesis. The book is where it begins.