What is a non-human identity?

A non-human identity is a digital identity that belongs to software rather than to a person: a service account, an API key, a certificate or a token used by an application, a script or an AI agent. It lets systems grant, track and revoke access for that software on its own, separate from any employee.

Why does a non-human identity matter for AI agents?

Without one, an agent acts under someone else's name. Teams often connect an agent using a developer's login or a shared integration account because it works on day one. The result is a record showing that a developer updated 2,000 customer addresses when the developer did nothing, and access that cannot be reviewed, because nobody knows which permissions belong to the agent.

Agents differ from older software identities in one important way. A batch job does the same thing every night. An agent decides what to do next, in response to content it reads. Its identity therefore needs tighter scoping, closer review and a clear owner, more like a member of staff than a cron job.

How does it work in practice?

A well-run non-human identity for an agent has:

• its own credential, never shared with a person or another agent;
• a named human owner who answers for it and approves changes to its access;
• scoped permissions, set per capability, not inherited from a broad integration account;
• short-lived secrets where systems allow, rotated on a schedule;
• inclusion in access reviews, alongside staff;
• a clean way to revoke, so suspending the agent removes its access everywhere at once.

The set-up steps are in giving an AI agent its own identity in your access management system.

What does an example look like?

An insurer runs an agent that drafts claim acknowledgement letters. It gets its own identity in the insurer's directory, owned by the claims operations lead. That identity can read claim records and write drafts into the correspondence system, nothing else. When a handler approves a draft, the record shows two identities: the agent drafted it, the handler sent it. If the agent is retired, the identity is disabled the same day and its access disappears from every connected system.

How is it different from a human identity with automation?

Some teams let an agent act through the identity of the person using it, so it inherits their access. That is delegation, not a non-human identity. It can suit a personal assistant that only reads a user's own mail. It is a poor fit for agents that act on shared systems, because the agent then has every permission the person has, and the record cannot tell the person's actions from the agent's. Where a person approves an agent's draft, as in human-in-the-loop working, the record needs both identities to show who did what.

Which terms sit close to it?

Service account: the most common form of non-human identity. Least privilege: the principle its permissions should follow. Role-based access control: the usual way to assign those permissions. Our guide to agent governance covers how identity fits with certification and records.

Where Pryme fits

In Pryme, every verdict is filed in an append-only record that names the agent that attempted the action and, for held actions, the named person who decided. The record always separates what the agent did from what a person decided.