---
title: "AI Agent Identity and Non-Human Identity Security: A Complete Guide"
description: "Every agent control depends on knowing which agent acted, for whom. This guide covers identity designs, the credential lifecycle, OWASP's NHI risks and what to ask vendors."
author: "Mara Voss"
category: "Defensive Architecture & Security Controls"
date: 2026-10-30T06:00:09.025Z
canonical: "https://agenticcyber.co/blog/ai-agent-identity-and-non-human-identity-security-guide"
---

# AI Agent Identity and Non-Human Identity Security: A Complete Guide

![passport, identity, identification](https://cdn.pixabay.com/photo/2020/03/30/16/37/passport-4984783_1280.jpg?w=1200&q=75)

> Every agent control depends on knowing which agent acted, for whom. This guide covers identity designs, the credential lifecycle, OWASP's NHI risks and what to ask vendors.

Pull up the access log for last Tuesday and find one write to a customer record. Which agent made it, on behalf of whom, under what approval? If the entry shows only a service account name shared by a dozen automations, you have found the weakest point in your agent programme, and it is not a model problem.

Consider this page the entry point to our coverage of agent identity and non-human identity (NHI) security. It says what an agent's credential must establish, compares designs, follows a credential from issue to retirement, maps published risks and closes with vendor questions. Nothing here is an audit. Vendor assertions and our own opinions are labelled as such.

## What an agent identity has to prove

A credential has four jobs: name the actor, name the principal behind it, bound its permissions and bound its lifetime. Agents blur every one.

- **Actor.** Many agents authenticate through one shared account, so the log cannot separate them.

- **Principal.** An agent may act for a person, for a team or for no one, and the system often cannot say which.

- **Permissions.** Scopes are granted once, broadly, and reused as the work changes.

- **Lifetime.** Tokens and keys survive past the task, occasionally past the whole project.

Standards bodies have started to notice. On 17 February 2026 NIST's Center for AI Standards and Innovation announced an AI Agent Standards Initiative aimed at secure, interoperable agents that can act on behalf of users ([NIST announcement](https://nist.gov/news-events/news/2026/02/announcing-ai-agent-standards-initiative-interoperable-and-secure)). Builders can find the practical reading in the initiative explainer. No final guidance on agent identity existed in the sources read for this guide, so treat any claim of a settled standard with suspicion.

## How platforms now describe the problem

Vendor documentation shows where the industry is heading. Microsoft's Entra Agent ID documentation says existing identity constructs fit agents poorly. It contrasts agent identities with application identities, which assume long-term stability and known ownership, and with human identities, which rely on passwords and passkeys. Agents may live for minutes or be created thousands of times a day, so the model aims at scale and short lifetimes ([Microsoft Entra, what are agent identities](https://learn.microsoft.com/en-us/entra/agent-id/what-are-agent-identities)).

The same page describes two access modes. In autonomous access the agent uses rights granted directly to its own identity. In delegated access it acts on behalf of a user, using rights that user controls. That split is the useful part, and it holds beyond one vendor: decide, per task, whose authority is being exercised. It is one vendor's design, so check how your own platform draws the line. For the incident-led version of this argument, read why an agent fits neither the user nor the service mould.

## Choosing among identity designs

DesignHow the agent authenticatesFitsCost

Borrowed user identityDelegated rights of a personShort tasks done for one individualBroad scopes and blurred audit
Own machine identityA narrow credential belonging to the agentAutonomous, repeated workCredential handling at scale
HybridDelegated rights for some steps, its own rights for othersAgents whose mode changes mid-workflowPicking the mode per step and recording the pick

Most production agents should land in the second or third row. The first row is acceptable for a personal assistant and a weak choice for anything shared.

## The life of an agent credential

### Issue it to an owner for a purpose

Attach three things to every agent identity: an accountable owner, a stated purpose and an end date. If nobody will own it, do not create it. The routines for expiry and departures are in [owners, expiry and offboarding](/non-human-identity-lifecycle-for-agents-owners-expiry-and-offboarding).

### Authenticate without a stored secret

Workload identity hands running software a verifiable identity with a short life, so nothing durable has to sit in a config file. SPIFFE is the best-known open specification family for this ([SPIFFE overview](https://spiffe.io/docs/latest/spiffe-about/overview/)). Applied to agents, see [workload identity for agents](/workload-identity-spiffe-for-ai-agents).

### Authorize one job at a time

Limit each token to one task. When an agent acts for a person, the token exchange defined in RFC 8693 lets a service trade one token for another and attach an actor claim, which keeps both parties visible in the record ([RFC 8693](https://www.rfc-editor.org/rfc/rfc8693.html)). Servers should also verify the audience of every token presented, a rule the MCP specification states outright, and [this confused deputy write-up](/mcp-server-authorization-token-audience-confused-deputy) explains the reason. For the wider OAuth picture, see [OAuth for AI agents](/oauth-for-ai-agents-scopes-token-exchange-delegation).

### Keep secrets out of reach

Keep credentials away from configs, prompts and chat transcripts. Prefer an operating-system credential store or a broker that issues brief leases. Details in [secrets management for agents](/secrets-management-for-ai-agents-keep-credentials-out-of-configs).

### Watch, rotate, revoke

Record every use: agent, delegating user, scope, outcome. Rotate on a timetable and after any incident. Practise cutting off one agent completely, with a stopwatch running.

### Retire it cleanly

Once the agent or its owner departs, disable the identity and remove grants and keys. Credentials left behind show up in review after review.

## Known risks, grouped from OWASP's list

The OWASP Non-Human Identities Top 10 for 2025 gives ten numbered risks ([OWASP NHI Top 10](https://owasp.github.io/www-project-non-human-identities-top-10/2025/top-10-2025)). Read them in four groups and the agent angle becomes clear:

GroupOWASP entriesHow agents make it worse

LifecycleImproper offboarding (NHI1), long-lived secrets (NHI7)Agents are created fast and rarely retired, and their tokens keep working
ExposureSecret leakage (NHI2), vulnerable third-party NHI (NHI3)Agents read tokens from files and environment variables, and tool servers hold credentials of their own
AccessInsecure authentication (NHI4), overprivileged NHI (NHI5), NHI reuse (NHI9), human use of NHI (NHI10)One broad credential serves many agents, and people paste personal tokens into them
EnvironmentInsecure cloud deployment configurations (NHI6), environment isolation (NHI8)Test agents often run beside production data with production keys

## Build the inventory before you buy anything

Nobody can govern identities they cannot list. Collect from three places: your identity provider and cloud accounts, which hold service accounts, OAuth clients and API keys; agent and tool configuration in repositories and on developer machines; and network logs that show calls to model providers and tool servers.

Join the three on owner and purpose. Whatever stays unowned after the join is your first cleanup list, and the inventory guide shows what to store per entry.

## What to log so attribution survives

Identity is only as good as the record it leaves. At minimum each tool call should capture the agent identity, the human or system it acts for, the tool and target, the scope used, the decision (allowed, denied, escalated) and a correlation identifier that links the steps of one run. Keep these records somewhere the agent cannot edit. Without the correlation identifier, an investigator reconstructs a run from timestamps, which is slow and error-prone.

## A ninety-day path from shared keys to per-agent identity

- **Days 1 to 30, see everything.** Build the inventory, tag an owner on every entry, and list every credential that more than one agent uses.

- **Days 31 to 60, separate and shorten.** Split the shared credentials so each high-impact agent has its own, and set an expiry on each. Move secrets out of configs into a store.

- **Days 61 to 90, exchange and rehearse.** Introduce short-lived exchanged tokens for the agents that act for users, run a revocation drill for one agent, and write the retirement rule into the owner's checklist.

The schedule is a suggestion, not a standard. Compress it for agents that touch money or regulated data.

## One nightly agent, three ways to identify it

Consider an invoicing agent that reads purchase orders each night, drafts payment batches and posts a summary to finance. Compare what each design leaves you after a bad run.

DesignIdentity usedAfter an incident

Shared automation accountThe account that other jobs also useYou cannot separate this agent's actions from others. Rotating the key breaks every job at once.
Own client, secret kept in a fileA dedicated OAuth clientYou can attribute actions and disable the client, but the standing secret on disk can still be stolen.
Workload identity plus exchanged tokensRuntime attests itself and receives a token valid for one jobAttribution works, the token has expired, and no standing secret existed.

The third design costs the most to build. For an agent that can approve payments the investment recovers its cost the first time someone asks what the agent touched last week. The middle row is a respectable stepping stone.

## Fix attribution before you fix secrets

Security teams tend to start with secrets: scan for keys, rotate them, vault them. That work matters, but it is the wrong first move for agents. Rotating a shared key leaves you with a fresher shared key. After the next incident you still cannot say which agent acted, so you cannot scope the damage, notify the right owner or decide which agent to disable.

My advice is to give each agent a distinct identity first, even a crude one such as its own service account with an owner tag, and to attack secret hygiene second. Attribution is the precondition for every later control: scoping, anomaly detection, revocation and audit all key off it.

The reasoning has a limit. If your agents already hold unique credentials, or if a live leak is in progress, secrets come first, and rotation is urgent. The ordering also assumes your platform can issue many identities cheaply. If it cannot, batching a few low-risk agents under one account is a defensible temporary tradeoff, provided the high-impact agents stand alone.

## Where each kind of agent differs

- **Laptop-based coding assistants.** They inherit the developer's rights and park tokens in local files, which makes the workstation the boundary to defend. Use the OS credential store and brief token lifetimes, and read the coding agent guide.

- **Home-built server agents.** The strongest candidates for workload identity plus token exchange. The runtime, every tool server and the gateway each get their own identity.

- **Browser agents.** They ride the user's sessions, so the open question is which accounts are signed in where they can reach.

- **Purchased SaaS agents.** The vendor's identity model becomes yours. Learn how it signs in to your systems, whether it uses delegation, and how you pull the plug.

- **Partner or third-party agents.** Handle them as outside parties: their own register entry, a contract, and a cut-off route.

## Failure patterns that repeat

- **The pasted personal token** that outlives the demo it was pasted for.

- **The master key** shared by several agents, which turns any leak into a total one.

- **The credential in a config file** that infostealers and careless sharing can both reach.

- **The orphaned agent** whose owner left and whose approval nobody can trace.

- **The foreign token accepted and forwarded** by a server that never checked who it was meant for.

## Questions for a vendor selling agent identity

- Which objects does it discover: agents and tool servers, or cloud service accounts alone?

- Does the record show on whose behalf an agent acted, beyond which key signed?

- What replaces the old long-lived secret, and is the replacement long-lived too?

- How quickly can a single agent be cut off, and does that disturb the others?

- What coverage exists for laptops and SaaS-embedded agents?

The tool categories comparison places such products in the wider market.

## Open questions

- No settled schema or claim set for agent identity exists yet in the sources read here, and NIST's work is still in progress.

- Support for token exchange and workload identity in agent frameworks is uneven and changes quickly.

- Dependable counts of agent credential theft are scarce, and most published numbers come from one vendor's telemetry.

This guide does not replace a security review. For production decisions about money or regulated data, involve qualified identity and security engineers.

## Questions about agent identity and NHI security

## FAQ

### What is a non-human identity?

An identity for software rather than a person. OWASP's NHI Top 10 uses service accounts and access keys as examples.

### Should an agent use a service account?

Only a dedicated one per agent, with narrow scope, an owner and an expiry. A shared service account hides which agent acted.

### When is a human identity right for an agent?

When it acts for one person. Use delegated access with the person's consent and an actor claim, never their password or live session.

### What should we fix first?

Give each agent its own identity so actions can be attributed. Then find shared and long-lived credentials in agent configs and replace them.


---
Source: https://agenticcyber.co/blog/ai-agent-identity-and-non-human-identity-security-guide