Non-Human Identity (NHI)

A non-human identity (NHI) is the credential software uses to prove who it is and act on a system. Service accounts, API keys, OAuth tokens, certificates, CI/CD secrets, and bots are all NHIs. So is an AI agent that logs in to a CRM or calls a database.

If a person is not typing the password, it is probably a non-human identity.

Why agents make this urgent

Companies already hold many more machine credentials than human accounts. I do not have a reliable public number to cite, so treat that as my observation, not a statistic. What I can say: every new agent adds more. Each one needs a way to call tools and read data, and each way is a credential somebody must issue, scope, rotate, and eventually remove.

Agents also differ from old service accounts. A script runs fixed code. An agent decides at runtime what to call, based on text it reads. If someone slips instructions into that text (see prompt injection), the agent’s identity becomes the attacker’s tool. The damage equals the permissions on the credential.

The OWASP list

OWASP publishes a Non-Human Identities Top 10 for 2025:

1. Improper offboarding
2. Secret leakage
3. Vulnerable third-party NHI
4. Insecure authentication
5. Overprivileged NHI
6. Insecure cloud deployment configurations
7. Long-lived secrets
8. Environment isolation
9. NHI reuse
10. Human use of NHI

Read that list as an agent checklist. Which agents have an abandoned key? Which share one credential across test and production? Which run on a long-lived token pasted into a config file? Which use a developer’s personal login?

Vendors are building agent identity

Microsoft announced Entra Agent ID in May 2025 as a public preview. The first release gave a unified directory of agent identities created in Copilot Studio and Azure AI Foundry. Microsoft said it would add access management and governance, support for third-party agents, and identity support for agent protocols including MCP and A2A.

The direction is clear: agents get their own identities, visible in the same admin tools as people. The Model Context Protocol spec points the same way on the server side. It tells servers to implement access controls and clients to log tool usage for audit. See Model Context Protocol.

How I would set up an agent identity

1. One identity per agent, per environment. No shared keys. No reuse between test and production.
2. Least privilege. Grant only the actions the agent needs, on only the data it needs. See AI agent permissions and least privilege.
3. Short-lived credentials. Prefer tokens that expire in minutes or hours over static keys.
4. Act on behalf of the user where possible. If the agent serves a user, pass that user’s permissions through so it cannot see what they cannot.
5. A named owner. A person is accountable for each agent identity.
6. An inventory. You cannot revoke what you cannot list.
7. Revocation and offboarding. When the agent is retired, the credential dies the same day.
8. Logs tied to the identity. Every call is attributable.

A short example

Say a team builds a finance-reconciliation agent. The first version uses an administrator’s API key pasted into an environment file. Later, someone adds a document reader to the agent, and a poisoned invoice tells it to export vendor bank details. With the admin key, it can. The fixed version gives the agent its own identity, read-only access to the invoice and ledger tables, a token that expires daily, and no access to the vendor master. The same attack now hits a wall.

Common mistakes

• Using a human’s credential for the agent.
• Giving the agent admin rights “until we figure out what it needs.”
• Storing keys in code, prompts, or chat logs.
• Forgetting agents built by individual teams that IT never sees. See the glossary entry on shadow AI.
• No expiry and no rotation.

Questions for your next review

• How many agents and automations run in production, and who owns each?
• Which credentials are static, and when did each last rotate?
• Which agents share a credential?
• Which agents hold more access than their tasks need?
• Which credentials belong to a person who has left?
• If one agent were hijacked today, what is the largest thing it could do?
• Can we revoke a single agent without breaking others?

Answering these usually produces a clean-up list within a day. It also shows which agents nobody can account for.

Related terms

Tool calling is how an agent uses its identity. AI guardrails add checks on top of permissions. For a wider control list, see the enterprise AI security checklist.