The main year one mistakes with agent identity are running agents on a human's account, sharing one token across agents, granting permanent broad access, keeping no inventory of agents, and never reviewing what each can do. Each one blurs who did what, which is the whole point of identity.
What is agent identity?
Agent identity means each AI agent has its own recognizable identity, with its own permissions, instead of acting as an anonymous script or as a person. The identity lets you answer: which agent took this action, on whose behalf, with what access, and until when.
Standards help with parts of this. RFC 8693 defines token exchange in OAuth, including delegation and impersonation, where one party acts for another. The SPIFFE standards describe securely identifying software workloads. The Model Context Protocol's authorization specification builds on OAuth for access to servers over HTTP. None of them solve the whole problem, but they give a vocabulary.
Mistake 1: The agent runs as a person
A developer gives an agent their personal token for speed. Now every action is logged as the developer, the agent has all of their access, and leaving the company can break the agent.
Fix: create a separate identity for the agent, and use delegation to act for the user when needed, with a narrower scope than the person holds.
Mistake 2: One shared token
Five agents share a key stored in a shared secret. When a destructive call appears in the logs, nobody can tell which agent made it. Revoking the key stops all five.
Fix: one identity per agent, or at minimum per agent role, so you can revoke and trace separately.
Mistake 3: Permanent broad access
Agents are given wide permissions "to avoid friction," and the credential never expires. OWASP's 2025 LLM list names Excessive Agency as a risk: an agent with more capability than its task needs.
Fix: start with the least access that completes the task, use short lived credentials, and request more through an approval step.
Mistake 4: No inventory
Teams spin up agents in notebooks, CI jobs, chat tools and IDEs. Nobody has a list. A security review cannot answer how many agents exist.
Fix: keep a register of agents: purpose, owner, identity, access level, last used. Review it monthly and retire the unused.
Mistake 5: Identity but no authorization
Teams issue identities and stop there. Anything with an identity can still call anything its credentials allow.
Fix: pair identity with policy: which agent may call which tool, in which environment, on which data. Enforce it outside the agent, not in its prompt.
Mistake 6: Ignoring the tools an agent connects to
An agent with a narrow identity can still talk to a tool server that holds broad credentials of its own, so the narrow identity means little.
Fix: treat each tool server as part of the access chain. Check what credentials it holds and who can reach it.
Mistake 7: Logs that cannot answer questions
Logs show an API key ID, not an agent name, a task or a requesting user.
Fix: log agent identity, acting user if any, tool, action and result. Test by asking, "what did agent X do last Tuesday?" and see how long the answer takes.
Mistake 8: No offboarding
People leave, projects end, agents remain with active access.
Fix: tie each agent to an owner and a review date. When the owner leaves or the date passes, access lapses until renewed.
A quick self test
| Question | Healthy answer |
|---|---|
| How many agents run here? | A number from a register |
| Who is the owner of agent Y? | A named person |
| When does its access expire? | A date |
| Can you revoke one without stopping others? | Yes |
| Can you list its actions from last week? | Yes, in minutes |
Where Safeguard fits
Safeguard supports agent identity, tracking which agent holds what access at what level, along with an MCP Guardrail that sits in front of MCP servers and policies enforced at build, CI and release. Those pieces cover the register, the access limits and the enforcement points described above.
What to do
- Stop agents using personal tokens and give each its own identity.
- Replace shared keys with per agent or per role credentials.
- Set expiry on every credential and a review date on every agent.
- Build and maintain a register of agents with owners.
- Enforce tool limits outside the agent.
- Test your logs with a real question.
Quick check
Why not let an agent use my own login?
Logs then show you, not the agent, the agent holds all your access, and offboarding you can break it. A separate identity fixes all three.
Do standards like OAuth solve agent identity?
They provide building blocks, such as delegation, but you still need a register, narrow scopes, expiry and enforcement.
Sources
- RFC 8693, OAuth 2.0 Token Exchange
- SPIFFE overview
- Model Context Protocol authorization specification
- OWASP Top 10 for LLM Applications, 2025
Last reviewed: 18 October 2026.
