Agent identity means giving each AI agent its own recorded identity, owner and permissions, so you can tell which agent did what and what it was allowed to touch. It differs from a user login or a shared API key, which hide the agent behind a person or a team.
The vocabulary around this is loose. Here is a glossary arranged around the questions an access review asks.
Who is this?
Identity. A record that names an actor and lets systems recognize it. For an agent, it should include a name, an owner and a purpose.
Agent. Software that uses a model to decide on actions and carries them out through tools. A chatbot that only answers is not much of an agent. One that files tickets, runs queries or changes code is.
Principal. The identity a system sees when a request arrives. Questions to ask are whether the principal is the agent, the user who started it, or a shared account.
Service account. A non-human account used by software. Agents often run under one. The risk is reuse: one account shared across several agents erases the answer to "which agent did this".
Owner. The human accountable for an agent. Without one, nobody retires its access when the project ends.
What can it do?
Permission. A single allowed action, such as reading a repository or creating a record.
Scope. A grouped set of permissions requested at sign-in. Broad scopes are convenient and hard to review.
Least privilege. Giving an actor only the access its task needs. OWASP's LLM06 Excessive Agency, in the 2025 Top 10 for LLM Applications, describes the failure when an LLM system holds more functionality, permissions or autonomy than it requires.
Tool access. Which tools an agent may call. With Model Context Protocol servers, tool access is where an agent reaches your data, so it deserves its own list.
Access level. How strongly the agent can act on a resource: read, write, administer. Knowing the level matters as much as knowing the resource.
On whose behalf?
Delegation. An agent acts for a user and inherits some of their rights. The question is whether it gets all of them or a narrowed subset.
Impersonation. The agent acts as the user, and logs show only the user. Convenient, and poor for audit.
Confused deputy. An agent with strong access is tricked into using it for someone with less. Prompt injection, listed as LLM01, is one route to this, because untrusted text can steer what the agent does with its own permissions.
Human in the loop. A person approves selected actions. Decide which actions, because approval on everything trains people to click yes.
How is it proven and recorded?
Credential. What the agent presents: a token, key or certificate. Short-lived credentials limit damage when one leaks.
API key. A long-lived secret. Easy to create, easy to copy into a place it should not be. Treat keys given to agents as sensitive as passwords.
OAuth grant. An authorization a user gives an app, often with a set of scopes. Review grants periodically, because they outlive the interest that created them.
Audit trail. A record of who did what. For agents it should show agent name, tool, target and the instruction that triggered it, where possible.
Rotation and expiry. Replacing credentials on a schedule and ending access when it is no longer needed.
Terms that get mixed up
Agent identity vs user identity. The first names the software actor. The second names the person. An agent acting for a user should carry both in the record.
Authentication vs authorization. Authentication proves who. Authorization decides what is allowed. An agent can authenticate correctly and still be authorized for far too much.
Identity governance vs agent guardrails. Governance tracks who holds what. Guardrails enforce rules when the agent acts. You want both.
What to do
- Inventory every agent in use, including ones engineers run locally.
- Give each agent its own account and a named owner.
- Record tools, scopes and access level per agent.
- Replace long-lived keys with short-lived credentials where you can.
- Review agent access on a schedule and remove what is unused.
- Make sure logs show both the agent and the user it acted for.
Where Safeguard fits
Safeguard's agent identity capability tracks which agent holds what access, at what level, and its MCP Guardrail proxy can enforce policy on calls to MCP servers. Both are generally available. They complement your identity provider and do not replace it.
Quick check
Can an agent just use my credentials?
It can, but then logs cannot separate your actions from the agent's, and its access is as wide as yours. Give it its own identity with narrower rights.
What is the first list to build?
A list of agents with an owner, tools and access level for each. Everything else builds on that.
Sources
Last reviewed: 18 October 2026.
