lgkm.org

Field notes · 19 October 2026 · Identity and access

Is an AI agent just another non-human identity?

In plain words: Whether an AI helper counts as its own kind of account depends on one thing: does it carry a badge of its own, or borrow yours? Identity and access, explained simply

In short

Three ways to give an AI agent credentials, its own, delegated from a person or borrowed from a person, compared on what the credential says, what kind of identity it is, what the log shows and what you can limit
Three ways to give an AI agent credentials, its own, delegated from a person or borrowed from a person, compared on what the credential says, what kind of identity it is, what the log shows and what you can limit

Three kinds, side by side

Human. One person, who joins, moves and leaves, signs in interactively and answers for what they do. Most identity processes were built around this one.

Non-human, in the classic sense. Software acting as itself. The code is fixed, so the behaviour is predictable: a backup job backs things up. The risk sits in the credential, as I wrote in machine identities outnumber people: static secrets, no owner, too much access, never rotated.

Agentic. Software that decides what to do. Given a goal, it picks tools, calls services and may start other agents, usually for a person or a team. The word describes the behaviour. It does not say which credential the agent is holding.

Which credential does the agent present?

1. Its own. The agent is issued a service account, key or workload identity, and acts as itself. This is a non-human identity at the credential layer, with every old problem attached: an owner, an expiry, the least access that works.

2. Delegated. The agent exchanges a person's authority for a token that names both. OAuth token exchange (RFC 8693) separates impersonation, where the agent becomes the user and is indistinguishable from them, from delegation, where the agent keeps its own identity and the token records who it acts for. This is neither a plain human nor a plain non-human identity. It is the agent, carrying the person's authority. Microsoft's Entra Agent ID, for example, has separate Conditional Access templates for agents acting alone and for agents acting on behalf of users.

3. Borrowed. The agent runs with a person's own login, session or personal token. The credential is a human one, and the log says the person did it. The Cloud Security Alliance's June 2026 research note recommends separating agent identities from human ones, starting with the agents that run under human credentials. (The note describes itself as AI-assisted and not formally reviewed, so I treat it as a view, not as evidence.)

In 2025 Apurva Davé of Aembit gave the same split in different words in a Cloud Security Alliance article: a non-human identity for an agent that runs on its own across sessions, a human one for an agent acting for a particular person, and "it depends" in between. He also argued that agents deserve a third category of their own.

What the classic definition misses

Even in the first route, "non-human identity" describes the credential and not the behaviour. Agents add three things that a service account never did:

What PAM, recertification and IGA make of it

These three programmes were built for people, and each rests on an assumption that agents quietly break.

IGA (identity governance and administration). IGA runs the life of an identity: created, changed, removed, with HR as the source of truth for people. An agent has no HR record, so a named owner has to be the anchor, as with any other non-human identity. Microsoft's Entra ID Governance now has sponsor workflows that reassign an agent when its sponsor changes roles or leaves, "to prevent orphaned agents". NIST's February 2026 concept paper on agent identity (a draft for comment, not guidance) points at the same machinery, suggesting SCIM to create, update and revoke agent identities across systems, and asking whether agent identity data should be ephemeral and tied to a task.

Recertification. The periodic review asks a manager to confirm that each entitlement is still needed. That suits a person with a stable role. It suits an agent badly: agents "tend to retain those permissions long after the task has ended", and a reviewer cannot tell from an entitlement name whether a model will need it next week. The CSA note's answer is usage-based reviews with no standing privilege, so the question becomes "what did it use, and for what?" The route matters here too. With a borrowed login, the manager certifies the person's access without knowing an agent exercises it. That is my own reading, not something the sources say. With delegation, the person's access caps the agent, but the agent's own access still needs a reviewer, and the sponsor is the natural one.

PAM (privileged access management). PAM vaults secrets, rotates them, grants elevation just in time and records sessions. All of that carries over to an agent with its own credentials, with a shift in emphasis: the CSA note recommends short-lived, task-scoped credentials and workload identity (SPIFFE or SPIRE) over vaulting static keys. Two questions are new. Privilege is about what an agent can do, so an agent that can run commands or call administration interfaces is privileged whatever its account is called, and NIST asks how to apply least privilege when an agent's actions "might not be fully predictable". And a "session" for an agent is a run of tool calls, so each action must trace to the agent's own identity record, which is what NIST's paper means by linking actions to "the identity of the non-human entity". On a borrowed login, a person's just-in-time elevation becomes the agent's elevation, and the PAM record names only the person. Again, that is my reading.

My view

Asking which box the agent belongs in is the wrong question. Ask which route it takes, and whether you can see the agent in the log. Routes one and two keep the agent distinguishable and can be limited, and delegation can also be capped by what the person is allowed to do. Route three loses both, and it also hides the agent from the governance tools: NIST's concept paper says access systems should "distinguish between agent and human identities", which a borrowed login defeats. That is why I would treat it as the one to remove first. For work with no person behind it, route one is the right fit, with all the discipline that non-human identities already need.

What to do on Monday

Sources

Follow with the feed

Personal work and my own view, not my employer's. Sources are public.