Directories for Non-Human Identities
Every agent needs its own identity, and permissions, expiration, and audit records all attach to that identity.
A Support Agent Goes to Work
Imagine a team deploys an AI agent that reads incoming support tickets, looks up order records, and drafts refunds for a human to approve. Before the agent touches any system, someone has to answer a basic question: when this agent uses a system, which identity is it using, and who answers for what it does?
What do you think happens?
Suppose the agent quietly runs on a developer's personal login. When someone reviews the logs afterward, whose name appears against each action the agent took?
Reveal answer
The developer's name
The source explains that if the agent runs on a developer's personal login, every action it takes looks like something that developer did. Accountability breaks, access is hard to limit, and nobody is clearly responsible when something goes wrong.
This article follows an agent from the moment it is deployed to the moment its access is reviewed. At each step you will meet one requirement that the agent's identity must satisfy. By the end, you should be able to look at a proposed agent deployment and check whether its identity answers the questions that matter.
Why a Borrowed Login Breaks Accountability
Most identity systems were built around people and, later, around software accounts. AI agents do not fit neatly into either category. They act on their own within limits that people set, but they are not human, and their behavior can change as the models and tools behind them change. That is why the question of what an AI agent is, from an identity and access management point of view, has become urgent.
An agent running under a shared service account, or under a person's login, is not really identified at all. Its actions are attributed to whichever account it borrowed, so the agent cannot be granted, limited, or reviewed as its own thing. The comparison below sets the two approaches side by side.
| Question | Agent uses a borrowed human login | Agent has its own identity |
|---|---|---|
| Whose name appears in the logs? | The account owner's name, for every action | The agent's own identity, so its activity can be found in one place |
| Can its access be limited on its own? | No, limits would also affect the human who owns the login | Yes, permissions attach to the agent's identity |
| Who is responsible when something goes wrong? | Unclear, since the activity looks like the account owner's work | A named sponsor, tied to the agent's identity record |
| Can it be reviewed as its own thing? | No, it has no record of its own | Yes, through its identity, permissions, and audit records |
Agent identity versus borrowing a human's credentials
Tracing an Agent's Access Through Its Lifecycle
Access is not perpetual. Once granted, it does not stay valid indefinitely. The sponsor grants a scope, and the access stays active while the agent operates within that scope. Renewal happens on a cadence that matches the customer's standard access-review process. At each renewal point, the sponsor makes a deliberate choice: renew the access, which returns it to active use, or let it lapse. The diagram traces these states.
The renewal point is the moment to ask whether the agent still needs what it has. An agent that was correctly scoped a year ago may no longer need the same tools or data. Because the identity is managed across this whole cycle, the review is a built-in checkpoint rather than an afterthought.
The Four Identity Requirements
A deployed agent needs four things from its identity. Each depends on the one before it. The identity itself is the anchor, because permissions, expiration, and audit records all attach to an identity. If the agent does not have one, there is nothing for those controls to hang onto. The diagram shows how the four requirements relate to that single identity.
The four requirements are examined one at a time below. The support agent from the opening scenario appears in each, so you can see the same deployment being checked against every requirement.
Following One Action into the Audit Trail
Now trace what happens when the agent takes a single action. The agent acts under its identity. The action, its result, and its context are each recorded against that identity in the audit log. The diagram follows one action through that path.
Reconstructing a refund decision from the log
A reviewer wants to know how a draft refund came to be in the queue. Using only the audit trail, what can they reconstruct?
- 1Find the identity
Search for activity by the support agent's identity. All of its records are findable in one place.
- 2Read the action
The entry records that a draft refund was created.
- 3Read the context
The entry records which ticket the draft was for.
- 4Read the result
The entry records that the draft was saved to the queue for a human to approve.
The reviewer can state what the agent did, on which ticket, and where the outcome went, and can confirm the sponsor is the person to ask about approval.
Mistakes Teams Make with Agent Identity
Common mistake Letting the agent run on a developer's personal login because it is quicker to set up
What it looks likeThe support agent reads tickets using the developer who built it, so every refund draft appears to be that developer's action.
Why it failsAccountability breaks. The activity cannot be separated from the developer's own work, and access cannot be limited for the agent alone.
Do this insteadGive the agent its own identity so that permissions, expiration, and audit records attach to it.
Common mistake Treating the sponsor as the person who wrote the code
What it looks likeThe engineer who built the agent is listed as its sponsor, and no one with authority over refunds is named.
Why it failsThe source says the sponsor is a human who is accountable for the agent's behavior, which is not necessarily the code's author.
Do this insteadName the person with the authority and context to answer for what the agent does.
Common mistake Granting broad access and planning to tighten it later
What it looks likeThe agent receives access to all customer archives 'for now'.
Common mistake Granting access once and never reviewing it
Why it failsAccess is renewed on a cadence rather than granted permanently, so an unreviewed grant drifts away from what the agent actually needs.
Do this insteadUse each renewal point to check whether the agent still needs the same tools and data.
Common mistake Logging actions without tying them to the agent's identity
What it looks likeThe log says 'a draft refund was created' with no identity, ticket, or outcome.
Why it failsA log entry is only useful if it points back to an identity and records the action, result, and context.
Checking a Proposed Deployment
A team proposes deploying an agent that summarizes customer emails and drafts replies. It will run under a shared service account that three developers use. It has read access to the whole customer mailbox, and no one has been named to answer for it. Using the four requirements, list what is missing and what you would change before approving the deployment.
Hints
- Ask whether the agent has its own identity or borrows a shared account.
- Ask who would answer for the agent's behavior if a draft reply went wrong.
- Compare the mailbox access with what the agent actually needs to summarize and draft replies.
- Consider when the access should be renewed and what the audit records would capture.
Key Takeaways
- An AI agent needs its own identity. Running under a shared service account or a person's login hides who is acting and makes the agent impossible to limit or review on its own.
- A deployed agent needs four things from its identity: a dedicated identity, a sponsor who is accountable for it, scoped permissions that list exactly what it can read, write, invoke, and escalate to, and an expiration with an audit trail.
- Access is renewed on a cadence. At each renewal point, the sponsor either renews the access, returning it to active use, or lets it lapse, so the identity is managed across its whole lifecycle.
- Every action is logged against the identity with its result and context, which lets a reviewer reconstruct what the agent did and why.
- Agent identity is still an evolving area, so directories built for non-human identities are a current, changing response rather than a settled standard.