Agent identity maturity runs from shared API keys at the bottom to per-agent, short-lived, delegated and audited access at the top. Most teams start at level one. Moving up means answering four questions for every agent: who owns it, what can it reach, how long does access last, and who can see what it did.
Why use a maturity model?
Agents spread through a company one team at a time, and each team picks the quickest credential. A model gives you a way to see where you are and avoid trying to leap to the end. It also keeps the conversation concrete. The model below is our own framing for planning, not a published standard.
Level 1: shared keys
One API key or service account is used by several agents and scripts. Secrets sit in config or chat. Nobody can say which agent did what. OWASP's Non-Human Identities Top 10 lists secret leakage, overprivileged identities and long-lived secrets among its risks, and this level has all three.
Next step: find every agent and every credential it uses.
Level 2: one identity per agent
Each agent has its own identity and a named human owner. You can revoke one without breaking others. Permissions are still broad, because scoping takes work.
Next step: narrow permissions to what each agent needs.
Level 3: scoped and time-bound
Permissions match the agent's job. Credentials expire. Static keys are replaced where the platform allows, with short-lived identity documents of the kind SPIFFE specifies for workloads. Access to tools is checked against policy before a call, not after.
Next step: connect agent actions to the people they act for.
Level 4: delegated and attributed
When an agent acts for a user, the record shows both. RFC 8693 distinguishes impersonation, where the actor is indistinguishable from the user, from delegation, where the agent keeps its own identity while acting on the user's behalf. At this level you use delegation, so an investigator can tell a person's action from an agent's.
Next step: make the evidence usable.
Level 5: audited and continuously reviewed
Every access grant is logged. Owners attest on a schedule that the agent still needs its rights. Retired agents lose access automatically. Anomalies, such as an agent touching a tool it has never used, are reviewed. Evidence for auditors is produced from the logs rather than assembled by hand.
A constructed example
A team runs three agents: a code reviewer, a ticket triager and a release notes writer. All share one token (level 1). They give each agent its own token and an owner in the team wiki (level 2). They then cut the reviewer's rights to read-only on repositories and add a 24-hour expiry (level 3). The example is invented, but the order is typical: attribution first, then scope, then lifetime.
What to do
- Count your agents, including ones built by individual engineers.
- List the credentials each one holds and who owns it.
- Pick the lowest level any production agent sits at and lift that one first.
- Set a rule that new agents start at level 2 or above.
- Add an expiry to every credential you can.
- Schedule a quarterly review of agent permissions.
Where Safeguard fits
Safeguard offers agent identity, which tracks which agent holds what access at what level, and policies and guardrails that can be enforced at build, CI and release. Both are generally available. They help you see and constrain agent access, and they work alongside your identity provider.
Quick check
Do we need level 5 everywhere?
No. Match the level to the agent's access. A read-only agent on public data needs less than one that can change production.
What is the cheapest first step?
An inventory: which agents exist, what each can reach and who owns it. Most gaps show up there.
Sources
Last reviewed: 18 October 2026.
