In short
- Every agent gets its own identity – never a borrowed or shared account.
- Every agent identity has a named human owner.
- Least privilege, short-lived credentials, separate environments.
- Log every action so you can say which agent did what, for whom, and why.
When an AI assistant answers a question, identity barely matters. When an AI agent starts taking actions – updating records, sending messages, moving files, calling other systems – it matters a great deal. Every action needs to be attributable, permitted and, where possible, reversible.
In many organisations, the first agents are deployed using whatever credentials are to hand: a developer’s account, a shared service account, an API key pasted into a configuration file. It works, until someone asks who changed a record – or until that developer leaves.
This guide sets out a practical approach to AI agent identity that a security team will recognise and a delivery team can live with.
Why AI agent identity matters now
Organisations have managed non-human identities – service accounts, application credentials, machine certificates – for years. Agents add something new. Unlike a fixed integration that does the same thing every time, an agent decides what to do based on instructions and the content it reads. Its behaviour is more flexible, which makes its permissions more consequential.
Agents can also be manipulated. Content an agent reads – an email, a web page, a document – can contain instructions designed to make it act outside its intended purpose. Good identity and permission design limits the damage if that happens.
Finally, agents multiply quickly. A team that starts with 2 can have 20 within months. Without a deliberate approach, identity sprawl follows.
“Every agent action should be attributable, permitted and, where possible, reversible.”
8 principles for AI agent identity
1. Every agent gets its own identity
Treat each agent as a distinct identity in your systems – not a borrowed human account and not a shared service account used by several agents.
A distinct identity means you can see exactly what each agent did, grant and remove its permissions independently, and switch it off without affecting anything else. Shared identities make all 3 impossible.
2. Every agent identity has a named human owner
An agent can’t be accountable. A person can. Record against every agent identity the individual who owns it – who decides what it’s for, approves its permissions and answers for what it does.
When that person changes role or leaves, ownership must transfer explicitly. An agent without an owner should be suspended until it has one.
3. Grant the least privilege that does the job
Start from nothing and add only the permissions the agent needs for its defined tasks. Scope them as narrowly as your systems allow: specific records, specific actions, specific environments.
Resist granting broad access “so it can be helpful”. An agent’s authority should be written down before its permissions are configured, and the permissions should match the authority – no more.
4. Distinguish acting as itself from acting for someone
Some agents do work in their own right – a monitoring agent checking system health, for example. Others act on behalf of a particular person – drafting an email for a colleague, or retrieving documents that person is entitled to see.
These need different treatment. When an agent acts on someone’s behalf, it should operate within that person’s permissions, not its own broader ones, and the record should show both the agent and the person it was acting for. Delegated access patterns supported by modern identity platforms are designed for exactly this.
ACTING AS ITSELF
Its own scoped permissions, its own audit trail.
ACTING FOR SOMEONE
That person’s permissions, with both names on the record.
5. Use short-lived credentials and manage secrets properly
Avoid long-lived keys and passwords embedded in code or configuration. Prefer credentials issued at run time that expire quickly and can be revoked centrally. Store any secrets the agent must use in a proper secrets manager – never in prompts, files or source control.
An agent with access to its own credentials in plain text can, in principle, be tricked into revealing them.
6. Separate environments
Give agents separate identities for development, testing and production. An agent under test should never be able to touch live data or systems by accident.
7. Log everything in a way you can use
For every action an agent takes, you should be able to establish which agent took it, on whose behalf (if anyone’s), under what authority, what information it used, and what it changed and when.
Make sure these logs flow into the monitoring your security team already uses, rather than sitting in a separate tool nobody watches.
8. Manage the lifecycle
Agents are created, changed and retired far faster than employees. Build a lightweight lifecycle around them:
1. Provisioning. A simple request that records purpose, owner, authority and permissions before the identity is created.
2. Review. A regular check – more frequent than for human accounts – that each agent is still needed, still owned and still uses only the permissions it has.
3. Retirement. A defined process for revoking credentials and archiving logs when an agent is no longer needed.
A pre-production checklist
Before any agent goes into production, you should be able to answer yes to each of these:
| Question | Yes / No |
|---|---|
| Does the agent have its own identity, not a shared or human account? | |
| Is a named person recorded as its owner? | |
| Is its authority written down, and do its permissions match it? | |
| Are its credentials short-lived and stored in a secrets manager? | |
| When it acts for a person, does it use that person’s permissions? | |
| Does it have separate identities per environment? | |
| Are its actions logged to your central security monitoring? | |
| Is there a date for its next access review? |
Where to start if you already have agents running
If agents are already live, don’t stop everything. Work through 3 steps:
1. Build the inventory. Find every agent, what credentials it uses and who set it up. Expect surprises.
2. Assign owners. Give every agent a named owner within a fixed period; suspend any that remain unclaimed.
3. Fix the riskiest first. Prioritise agents using human accounts or shared credentials, and those with write access to sensitive systems.
Identity is the foundation
Most of what makes agents trustworthy – governance, audit, accountability, the ability to switch one off quickly – depends on knowing exactly which agent did what, under whose authority. Get identity right early and everything built on top becomes easier. Get it wrong and every later control is built on sand.
Common questions
What is AI agent identity?
The distinct, managed identity an AI agent uses to access systems and data – with its own credentials, permissions, owner and audit trail – rather than borrowing a person’s account or a shared service account.
Should AI agents use human user accounts?
No. Using human accounts makes it impossible to tell agent actions from human ones, ties the agent to one person’s employment, and usually grants far more access than the agent needs.
What is a non-human identity?
Any identity used by software rather than a person – service accounts, application credentials, machine certificates and, increasingly, AI agents. They need the same rigour as human identities, and often more frequent review.
How should AI agent permissions be set?
Write down the agent’s authority first, then grant the least privilege needed to perform it, scoped to specific records, actions and environments. When acting for a person, the agent should use that person’s permissions.
What this looks like in practice
Every agent in our own business works under its own identity, with a named human owner and written authority. We help organisations put the same foundations in place before their agent estate grows beyond what they can see. Read about agent governance →
