AI Agent Identity and Non-Human Identity

Give every AI agent its own identity. One agent, one credential, one owner, one set of logs. Do not run agents on a shared service account.

A shared account fails audits for a simple reason. When something goes wrong, nobody can say which agent did it, for whom, or why it had access.

This is the builder view of AI agent identity: how agents should authenticate, when to use a user’s credentials, and what to log.

Why agents need their own identity

An AI agent is software that picks its own next action. It calls tools, reads data, and sometimes writes. Each of those calls needs a credential. The question is whose.

The identity world has two familiar boxes: human users and non-human identities such as service accounts and API keys. Microsoft lists AI agents among non-human identities, next to apps, bots, and scripts. It names the usual risks: permissions that pile up over time, and identities that stay active after the system they served is gone.

Agents stretch both boxes. NIST’s NCCoE published a concept paper in early 2026 on identity and authorization for software agents. It focuses on identification, authorization, auditing, and non-repudiation, plus controls against prompt injection. The Cloud Security Alliance’s summary of the paper lists four areas: identification, authorization, access delegation, and logging. Note that the paper was a concept paper that asked for public comment. It is not a finished standard.

Here is the practical version. An agent is not a person, so it can’t use judgment about scope. It is not a static service either, because its behavior shifts with context and tool output. That means it needs an identity that is its own, with limits that match its job.

Shared accounts and their failure

The common shortcut is one service account for “the AI stuff.” Three agents, one credential. It fails in four ways.

No attribution. The log says svc-ai deleted a record. Which of the three agents? On whose request? You can’t answer.
Standing, broad permissions. The CSA summary points out that treating an agent as a service account grants indefinite standing permissions with no way to scope them to a task or time window. One account must carry the union of what all three agents need.
No clean shutdown. To stop one agent, you rotate the shared secret and break the other two. So nobody does.
Blast radius. One leaked secret exposes every agent behind it.

OWASP’s Non-Human Identities Top 10 for 2025 names the same problems. Its list includes overprivileged identities, long-lived secrets, improper offboarding, secret leakage, “NHI reuse,” and “human use of NHI.” A shared agent account often hits several at once.

What does an auditor want?

Auditors apply their existing rules. The PCI DSS rule on shared accounts is a good example. As summarized by Microsoft Learn, group, shared, or generic accounts are allowed only on an exception basis, with every action attributable to an individual. A shared AI service account is a generic account. It fits the exception only if you can document the need and attribute every action.

Your auditor will ask some version of these:

Who or what performed this action?
On whose authority?
What was it allowed to do, and who approved that?
When was the credential issued, and when does it expire?
Can you show me every action it took last quarter?
How do you turn it off?

If you have one credential per agent, an owner on record, and logs keyed to that credential, each question has a short answer. If you have a shared account, each one takes a week.

Delegated versus dedicated credentials

There are two ways an agent can hold access.

Delegated credentials. The agent acts on behalf of a specific user. It gets a token that carries that user’s rights, usually capped to a smaller scope. The agent can never do more than the user can.

Dedicated credentials. The agent has its own identity and its own permissions. It acts as itself, not as a person.

The IETF’s OAuth Token Exchange standard, RFC 8693, draws a useful line between impersonation and delegation. With impersonation, the actor is indistinguishable from the user. With delegation, the actor keeps its own identity, and it is understood that it acts on the user’s behalf. The standard defines an act (actor) claim in a token to say that delegation happened and who the actor is. I’d always pick delegation over impersonation for agents. Impersonation erases the evidence you need.

Which one should I use?

Use this table.

Situation	Use	Why
Agent works inside one user’s own data (their inbox, their calendar)	Delegated	Access can’t exceed the user’s. Revoking the user revokes the agent.
Agent runs on a schedule or event with no user present	Dedicated	There is no user to delegate.
Agent serves a team and needs shared system access	Dedicated	No single user owns the task. Use least privilege and a named owner.
Agent needs access the requesting user does not have	Dedicated, behind an approval step	Do not borrow a more powerful person’s login.
Action must be traced to a person’s decision	Delegated, and log both user and agent	Accountability points to a human.
High-risk write (payment, deletion)	Either, plus human approval	Identity does not replace approval.

The CSA summary describes the tradeoff well. A pure service account gives an agent standing permissions with no scoping. A pure delegated-user model merges agent actions into the human’s identity record, which blurs accountability. In practice, the cleaner design is often a hybrid: the agent has its own identity, and a delegation record links a particular action to the user who asked for it.

This is my recommendation, not a standard. I’d start with a dedicated identity for every agent, and add delegation only where the agent works inside a single user’s data.

Short-lived tokens and scopes

Whatever the identity type, the token should be small and brief.

The IETF’s OAuth security best practice, RFC 9700 from January 2025 gives the baseline:

Token privileges should be restricted to the minimum needed.
Access tokens should be audience-restricted to one resource server, or a small set of them.
Tokens should be restricted to certain resources and actions.
Tokens should be sender-constrained, using mutual TLS or DPoP, to limit misuse of a leaked token.
Refresh tokens add safety because they let the server issue short-lived, reduced-scope access tokens. They should be bound to scope and rotated or sender-constrained, and expire after inactivity.

Apply that to agents:

Scope per tool, not per agent. If the agent reads invoices and writes comments, issue read on invoices and write on comments. Not “full access to the ERP.”
Expire in minutes. Let the agent request a fresh token per task or session. A stolen token then ages out fast.
Bind the audience. A token for the invoice API should not work on the HR API.
Never pass tokens along. The MCP specification (June 2025 version) says MCP servers must validate that tokens were issued for them, and must not pass through the token they received from a client. If your agent calls tools through MCP, this matters. My MCP security guide goes deeper.

How do I scope and expire tokens?

Start from the task. List each call the agent makes. For each, write the narrowest scope that allows it and the shortest lifetime that doesn’t break the task. Start narrow, test, and widen only when a real call fails. My guide to least-privilege agent permissions has a step-by-step method.

Secrets storage and rotation

Some agents still need a long-lived secret, such as an API key for a vendor that has no OAuth. Treat those as the exception.

Store secrets in a secrets manager. Not in code, prompts, config files, or the agent’s context window. If a secret enters the model’s context, it can leak through output or a prompt injection.
Inject at call time. The tool layer attaches the credential. The model never sees it.
Rotate on a schedule and on events. Rotate when an owner leaves, when a vendor reports a breach, and when you retire the agent. OWASP lists “improper offboarding” first in its NHI list.
One secret per agent per system. Reuse turns one leak into a wide incident.
Name an owner. Every agent identity needs a human owner on record. When the owner leaves, the identity gets reassigned or shut down.
Set an expiry. Give each agent identity a review date. If nobody renews it, it turns off.

The prompt injection risk is why this matters. An agent that reads untrusted text can be tricked into using its access in ways you did not plan. Narrow scopes limit how much a tricked agent can do.

Tying actions to an identity in logs

An identity is only useful if every action carries it. The CSA summary names the goal for logging: audit records attributed to non-human entities, so you can investigate agent behavior without rebuilding it by hand.

Log these fields for each tool call:

Field	Example
Agent ID	`ap-exception-agent`
Agent version	`2026-08-01`
Credential ID	The token or key identifier, never the secret
On behalf of	User ID, or `none` if autonomous
Tool and action	`erp.invoice.update`
Target	Invoice ID
Input hash or reference	Pointer to the stored input
Result	Success, error, denied
Approver	Person who approved, if any
Timestamp	UTC

Write logs somewhere the agent can’t edit, and log denials as well as successes. A burst of denied calls is an early warning.

Who can see what the agent did? Decide this up front. A reasonable default: the agent owner sees their agent’s logs, security sees all of them, and auditors get read-only access. My post on what to log for an AI agent audit trail covers the full field list and retention. If an agent misbehaves, you also want a quick off switch, covered in the AI agent kill switch.

Decision table

Use this as a one-page review for each agent.

Question	Good answer	Red flag
Does the agent have its own credential?	Yes, one per agent	Shared with other agents or humans
Who owns it?	A named person	”The team” or nobody
Delegated or dedicated?	Chosen on purpose, written down	Whatever was easiest
How long do tokens last?	Minutes to hours	Months or never
What can it do?	Listed scopes per tool	Admin or “full access”
Where do secrets live?	Secrets manager, injected at call time	In code, prompts, or chat
Is the audience bound?	Token works on one API	Token works anywhere
Do logs show agent, credential, and user?	Yes	Only a service account name
Can you disable it alone?	Yes, in one step	Rotating breaks other agents
When is the next review?	A date is set	None

If you see two or more red flags, fix identity before you add features. For the broader concept, see the glossary entry on non-human identity.

Bottom Line

Give each agent its own identity, an owner, narrow scopes, short-lived tokens, and logs keyed to that identity.

Use dedicated credentials by default. Use delegation when the agent works inside one user’s data, and log both the user and the agent.

Next step: list every credential your agents use today. Any that is shared, long-lived, or ownerless goes to the top of the fix list.

FAQ

How should AI agents authenticate? Each agent should have its own credential, preferably an OAuth client or workload identity that issues short-lived tokens. Avoid shared service accounts, personal logins, and long-lived API keys. Scope every token to the specific tools and actions the agent needs.

Delegated or dedicated credentials? Use delegated credentials when the agent acts inside one user’s own data, so it can never exceed that user’s access. Use dedicated credentials when the agent runs without a user or serves a team. Log both the agent and the user when delegation is used.

How do I scope and expire tokens? List each call the agent makes and grant the narrowest scope that allows it. Restrict each token to one audience. Issue access tokens that last minutes, and rotate or bind any refresh tokens. Widen scope only when a real call fails.

Who can see what the agent did? Decide before launch. A common setup is: the agent owner sees that agent’s logs, security sees all agent logs, and auditors get read-only access. Logs should be stored where the agent can’t change them.

What does an auditor want? They want attribution, authority, and evidence. That means a unique identity per agent, a named owner, documented permissions and approvals, credential issue and expiry dates, and a log of every action. They also ask how you can turn the agent off.

Why do shared service accounts fail audits? They break attribution. One account hides which agent acted and on whose behalf. They also tend to hold broad standing permissions, and a single leaked secret exposes every agent behind them. Frameworks such as PCI DSS allow shared accounts only as documented exceptions.

Three Ways to Work With TMA

Need an agent built? We deploy production AI agents in your infrastructure. Working pilot. Real data. Measurable ROI. → Schedule Demo

Want to co-build a product? We’re not a dev agency. We’re co-builders. Shared cost. Shared upside. → Partner with Us

Want to join the Guild? Ship pilots, earn bounties, share profit. Community + equity + path to exit. → Become an AI Architect

AI Agent Identity: Why Shared Service Accounts Fail Audits