Most organisations know their AI agents need better identity controls. Few can say where they stand today or what "good" looks like next year. This maturity model gives security, IAM and platform teams a shared way to assess how well they identify, authenticate, authorise, govern and monitor AI agents. It covers seven dimensions across five levels, with self-assessment questions for each, so you can find the gaps that matter most and build a realistic roadmap. It follows the same progression as our Machine-to-Machine Identity Maturity Model, extended for the autonomy, delegation and runtime behaviour that make agents different.
Key takeaways
- Assess maturity across seven dimensions: discovery and inventory, identity and authentication, authorisation, delegation, lifecycle and governance, tools and supply chain, and monitoring and response.
- If your agents run on borrowed or shared credentials and your inventory is partial, you are at Level 1 or 2.
- Level 3 is the practical target for most enterprises in the near term: every agent has its own identity, an owner, least-privilege access and attributable logs.
- Your overall level is set by your weakest dimension. Advanced monitoring does little if agents still hold admin keys.
The five levels
| Level | Name | Summary |
|---|---|---|
| 1 | Ad hoc | Agents are deployed by individual teams with whatever credentials are to hand. No inventory, no ownership, no specific controls. |
| 2 | Aware | The organisation knows agents are a risk and has started finding them. Some policies exist, but agents still share or borrow credentials. |
| 3 | Defined | Every agent is registered, owned and runs on its own identity with least-privilege, short-lived credentials. Actions are logged and attributable. High-impact actions need approval. |
| 4 | Managed | Access is task-scoped and issued just in time. Delegation carries both user and agent identity. Authorisation is decided per action by policy. Behaviour is baselined and monitored. |
| 5 | Adaptive | Identity is bound to attested agent configuration. Access adapts continuously to risk signals. Containment is automated and tested. Controls extend to cross-organisation agent trust. |
The seven dimensions
1. Discovery and inventory
| Level | What it looks like |
|---|---|
| 1 | No list of agents or AI integrations. |
| 2 | One-off discovery exercise; partial list of sanctioned agents; shadow AI largely unknown. |
| 3 | Agent registry covering all sanctioned agents, with purpose, owner, tools and credentials. Regular discovery of OAuth-connected AI apps and AI API keys. |
| 4 | Continuous discovery from identity provider, SaaS, cloud, endpoint and network sources feeds the registry automatically; unregistered agents cannot obtain production credentials. |
| 5 | Registry includes relationships between agents, tools and data; changes to agents are detected and reconciled in near real time. |
Self-assessment: Could you list every agent with write access to a business system today? Would you know if a team launched a new one tomorrow? See the Shadow AI and AI Agent Discovery Guide.
2. Identity and authentication
| Level | What it looks like |
|---|---|
| 1 | Agents use developers' personal tokens, shared service accounts or static API keys in configuration. |
| 2 | Some agents have dedicated service accounts; static secrets are moved into a secrets manager. |
| 3 | Every agent has a unique identity; credentials are short-lived and platform-issued where possible; no agent uses human credentials. |
| 4 | Workload identity federation and sender-constrained tokens for high-value access; no static secrets for internal agents. |
| 5 | Agent identity is bound to attested workload and agent configuration (model, prompt and toolset); changing the configuration changes the identity. |
Self-assessment: What percentage of agents run on their own identity? How many hold credentials that never expire? See the Agentic AI Identity Guide and NHI Authentication Guide.
3. Authorisation
| Level | What it looks like |
|---|---|
| 1 | Agents granted admin or broad roles so they "just work". |
| 2 | Admin access removed from most agents; roles defined per agent but broad. |
| 3 | Least-privilege roles per agent purpose; human approval enforced for irreversible and high-value actions. |
| 4 | Task-scoped, just-in-time access; a policy engine authorises each tool call using agent, user, resource and context. |
| 5 | Authorisation adapts to real-time risk signals, stepping up to approval or blocking automatically. |
Self-assessment: If an agent were fully hijacked by prompt injection, what is the worst it could do with its current access? See the AI Agent Authorisation Guide.
4. Delegation
| Level | What it looks like |
|---|---|
| 1 | Agents impersonate users with full-scope tokens, or act with no link to a user at all. |
| 2 | OAuth consent used for user-facing agents, but scopes are broad and downstream systems see only the user. |
| 3 | Consent scopes are narrow; user tokens are never passed through to other services. |
| 4 | Delegated tokens identify both the user and the agent (for example via token exchange); authority narrows at each hop in multi-agent systems. |
| 5 | Full delegation chains are recorded and enforced across agents and organisations; high-risk actions trigger out-of-band user approval. |
Self-assessment: Can a downstream API tell whether an action came from a user or from an agent acting for them? See the Multi-Agent and A2A Security Guide.
5. Lifecycle and governance
| Level | What it looks like |
|---|---|
| 1 | No owners; agents and their credentials persist after projects end. |
| 2 | Policy requires owners; some manual reviews; offboarding inconsistent. |
| 3 | Every agent has a named owner; registration before credentials; periodic access reviews; defined retirement that revokes all credentials. |
| 4 | Changes to model, prompt, tools or autonomy trigger automatic re-review; ownerless agents are suspended automatically. |
| 5 | Governance is integrated with AI risk management and compliance reporting; controls are evidenced continuously. |
Self-assessment: When did you last remove an agent, and are you sure every token and grant it held was revoked? See the Agentic AI Security Policy Template.
6. Tools and supply chain
| Level | What it looks like |
|---|---|
| 1 | Any MCP server, plugin or package can be installed; credentials pasted into tool configuration. |
| 2 | Guidance on approved tools; some scanning of configuration for secrets. |
| 3 | Allowlist of approved MCP servers, plugins and agent frameworks; remote MCP servers require authorisation; no static secrets in local tool configuration. |
| 4 | MCP or tool gateway brokers credentials and enforces policy; tool definition changes are detected and require re-approval. |
| 5 | Signed and verified tools and agent metadata; continuous assessment of third-party agents and servers. |
Self-assessment: Do you know which MCP servers your developers are running, and what credentials they hold? See the MCP Security Guide.
7. Monitoring and response
| Level | What it looks like |
|---|---|
| 1 | Agent actions logged as users or shared accounts, if at all. |
| 2 | Some agent platforms log activity; logs not correlated; no agent-specific detections. |
| 3 | Every action logged with agent, principal, tool and outcome; a manual procedure exists to stop an agent and revoke its credentials. |
| 4 | Per-agent behavioural baselines and detections; tested kill switch that works in minutes; correlation across model, tool and API logs. |
| 5 | Automated containment triggered by detections; revocation signals shared with relying services; regular red teaming of agents. |
Self-assessment: How long would it take to stop a misbehaving agent and revoke everything it holds? Have you tested it? See the AI Agent Observability and Incident Response Guide.
How to use the model
- Score each dimension from 1 to 5 using the descriptions. Use evidence, not intent: a policy that is not enforced does not count.
- Take the lowest score as your overall level, and note where one dimension lags the others.
- Prioritise by risk: identity and authentication, and authorisation, usually give the biggest reduction in blast radius. Discovery comes first because you cannot fix what you cannot see.
- Set a 12-month target: for most organisations, Level 3 across all dimensions, with Level 4 for agents that touch sensitive data or can take irreversible actions.
- Reassess every six months, and whenever you adopt a new agent platform or protocol.
A typical roadmap from Level 1 to Level 3
- First 90 days: discover agents and AI integrations; remove admin and wildcard permissions; stop agents using personal tokens; name an owner for every agent found.
- Three to six months: stand up an agent registry; issue a dedicated identity to each agent; move secrets out of configuration; approve a list of MCP servers and tools; enforce approval for high-impact actions.
- Six to twelve months: short-lived, platform-issued credentials; attributable logging across agent platforms; access reviews for agents; a tested procedure to stop an agent and revoke its credentials.
Mapping to frameworks
Level 3 across all dimensions provides much of the identity-related evidence expected by the OWASP NHI Top 10, the identity controls behind the OWASP Top 10 for Agentic Applications (particularly ASI02, ASI03 and ASI10), and the governance, logging and human oversight themes in the NIST AI RMF, ISO/IEC 42001 and the EU AI Act. See the Agentic AI Compliance Guide for the detailed mapping.
How NHI Mgmt Group can help
We run independent NHI and agentic AI maturity assessments, build business cases and roadmaps, and support RFP strategy for agent identity programmes. Our NHI Foundation Level Training Course includes an Agentic AI module. Contact us to discuss an assessment.
Related NHI Mgmt Group resources: Machine-to-Machine Identity Maturity Model · Agentic AI Identity Guide · AI Agent Identity Security Buyer's Guide · Board and CISO Briefing
