How to give an AI agent its own identity in your access management system

Create one non-human identity per agent, per environment, with a named human owner and no interactive login. Map each capability to its own entitlement at the depth it was approved for, give it no administrative rights, and tie its lifecycle to the agent inventory. Every sign-in and entitlement change is then logged against that agent alone.

Why does the agent need its own identity, and who owns it?

An agent that runs under an employee's account, or under a shared integration account, cannot be limited, reviewed or switched off on its own. Its actions blur into someone else's history. The reasons are set out in why AI agents need their own identities, and the category of account is explained in what is a non-human identity?

The identity and access management team owns the identity. The agent's process owner is its sponsor: they request entitlements, approve them at review and answer for what the agent does. Security sets the rules for non-human identities in general.

What are the steps?

1. Person, process owner: registers the agent on the inventory, which creates the request for an identity.
2. Person, identity team: creates the identity as a non-human type, one per agent and per environment, with the process owner recorded as sponsor and the inventory reference stored on it.
3. Person, identity team: disables interactive sign-in. The agent authenticates with short-lived tokens or certificates, never a password a person could type.
4. Person, process owner: requests one entitlement per capability, matching the approved capability and depth matrix.
5. Person, identity team: grants entitlements as narrow roles: read on specific objects, write on specific fields, never broad administrator roles.
6. Person, security: sets conditions, such as calls only from the agent platform's network, and blocks the identity from managing identities, including its own.
7. Agent, depth 1: is tested with attempts outside its entitlements, which must fail and be logged.
8. Person, identity team: links the lifecycle. When the agent is suspended, retired or changes role on the inventory, the identity changes with it.

Which permissions does it get per action, and at what depth?

The fourth row matters. An agent approved at depth 4 for payments should still not hold the right to release payments directly in the banking system. It prepares and submits, and the release entitlement belongs to the person or workflow that approves. When the agent needs more, it asks through the proper route described in how to let an AI agent request access through your access management system.

What stays with a person?

Creating the identity, granting and removing entitlements, approving the sponsor, and reviewing access all stay with people. So does any action the agent takes on behalf of a specific user: where a user asks the agent to act for them, the record should carry both identities, the agent's and the user's, and the user's own access should still limit what is done.

What is recorded, and what evidence does it leave?

• Identity record: type, sponsor, inventory reference, creation approval.
• Entitlements: each grant with the request, the approver and the capability it serves.
• Sign-ins and token issues: every authentication, with source and time.
• Refusals: every attempt outside entitlements.
• Lifecycle changes: suspension, role change, retirement, each linked to the inventory change that caused it.

Link the identity's activity to the agent's own record of verdicts, so an investigator can move from "this identity changed this field" to "this is why the agent did it and who approved it".

Which controls make it safe?

One identity, one agent. Two agents sharing an identity cannot be told apart or limited separately.

Separate identities per environment. The test agent's identity has no rights in production.

No standing administrator rights. If a task needs elevated access, grant it for that task, for a short time, with approval.

Least privilege, reviewed. Grants start narrow and are checked at every access review; see how do you give an AI agent least-privilege access?

Shared drives are not a back door. File shares often grant access by group membership. Do not put agent identities in broad groups; follow how to give an AI agent access to shared drives.

What should you measure?

Count agents running without their own identity (the target is none), entitlements without a linked capability, identities whose sponsor has left, refusals per identity, and identities still active after their agent was retired.

Where does it usually go wrong?

The agent borrows a person's session. It is quick to build and impossible to govern. The agent then has everything the person has.

Groups grant too much. Adding the agent to a team group gives it every share and mailbox the team can reach.

Sponsors move on. The process owner changes jobs, and the identity has no one answering for it. Make sponsor changes part of the leaver and mover process.

Retirement misses the identity. The agent is switched off, the identity remains, and its tokens still work.

Where Pryme fits

In Pryme, each agent acts under its own identity, and every action meets the minimum chain of five bounds before your systems see it. Your access management system remains the outer limit; Pryme narrows within it per capability and files every verdict. See agent governance is a bound, not a model.