Most organisations know their AI agents need better identity controls, but few can say where they stand today or what "good" should look 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 scores seven dimensions across five levels, with self-assessment questions for each, a roadmap from Level 1 to Level 3 and beyond, and a mapping to NIST CSF 2.0, NIST SP 800-53 Rev. 5, ISO/IEC 27001:2022, CIS Controls v8.1, the OWASP NHI and Agentic Top 10 lists, the NIST AI RMF and the EU AI Act. It is for CISOs, IAM leads and AI platform owners who need an honest baseline, not a vendor score.
Key takeaways
- Score seven dimensions separately: discovery and inventory, identity and authentication, authorisation, delegation, lifecycle and governance, tools and supply chain, and monitoring and response.
- Borrowed credentials mean Level 1 or 2: if agents run on developers' tokens, shared service accounts or static keys, and your inventory is partial, you are not yet at Level 3, whatever your policies say.
- Level 3 (Defined) is the practical target for most enterprises within 12 months: every agent has its own identity, a named owner, least-privilege and short-lived access, and attributable logs.
- Your overall level is set by your weakest dimension. Advanced behavioural monitoring does little if agents still hold admin keys that work across environments.
- Measure outcomes, not activity: the share of agents on their own identity, the share of credentials that expire, time to stop an agent and revoke everything it holds, and the share of high-impact actions behind approval.
Why agents need their own maturity model
Agents are non-human identities, so every lesson from service accounts, API keys and workload identity applies. What changes is behaviour. NIST's National Cybersecurity Center of Excellence (NCCoE) describes agents as systems "that have the capability for autonomous decision-making and taking action with limited human supervision to achieve complex goals", and its February 2026 concept paper on software and AI agent identity focuses on five areas: identification, authorisation, access delegation, logging and transparency, and tracking data flows. Those areas shape the dimensions below.
Three properties push agents beyond a standard NHI programme. First, an agent's actions are not fully predictable when it is deployed, which the NCCoE paper names as the core difficulty in setting least privilege. Second, agents often act on behalf of a person, so a downstream system needs to know both who asked and which agent acted. Third, agents pick up tools at runtime, increasingly through the Model Context Protocol (MCP), so the toolset and its credentials become part of the identity surface. The OWASP Top 10 for Agentic Applications puts it plainly: "Without a distinct, governed identity of its own, an agent operates in an attribution gap that makes enforcing true least privilege impossible." See the Agentic AI Identity Guide.
The five levels
| Level | Name | Description |
|---|---|---|
| 1 | Ad hoc | Agents are deployed by individual teams with whatever credentials are to hand. No inventory, no ownership and no agent-specific controls. Agent actions appear in logs as a user or a shared account, if at all. |
| 2 | Aware | The organisation knows agents are a risk and has started finding them. Policies exist and some agents have dedicated accounts, but many still share or borrow credentials and access is broad. |
| 3 | Defined | Every agent is registered, owned and runs on its own identity with least-privilege, short-lived credentials. Actions are logged and attributable to the agent and the person it acts for. High-impact actions need human approval, and there is a manual procedure to stop an agent. |
| 4 | Managed | Access is task-scoped and issued just in time. Delegated tokens carry both user and agent identity. A policy engine authorises each tool call. Behaviour is baselined and monitored, and the kill switch is tested. |
| 5 | Adaptive | Identity is bound to attested agent configuration. Access adapts continuously to risk signals. Containment is automated and tested, and controls extend to agents operating across organisations. |
The seven dimensions
Each dimension has its own scale. Score with evidence from production, not intent: a policy that is not enforced does not count.
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 records 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? The NIST AI RMF expects "mechanisms ... to inventory AI systems" (GOVERN 1.6). See the Shadow AI 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, and no credential is shared between environments. |
| 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? SPIFFE, which the NCCoE lists as one way to identify agent workloads, issues "short lived cryptographic identity documents" (SVIDs); OAuth DPoP (RFC 9449) sender-constrains tokens so a stolen one cannot simply be replayed. See the 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; no wildcard scopes; 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? OWASP's mitigations for ASI03 include short-lived, narrowly scoped tokens per task, per-action authorisation by a centralised policy engine and human approval for high-privilege or irreversible actions. The MCP security best practices list "wildcard or omnibus scopes" as a common mistake. 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; tokens are audience-bound and 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? RFC 8693 draws the line: with impersonation, A "is indistinguishable from B", while with delegation "A still has its own identity separate from B", and the JWT act claim "can provide a representation of a chain of delegation". MCP's guidance warns that token passthrough can cause the confused deputy problem. 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 retire an agent, and are you sure every token and grant it held was revoked? Improper offboarding is NHI1 in the OWASP Non-Human Identities Top 10, and the AI RMF asks for processes to decommission AI systems "safely" (GOVERN 1.7). See the Identity Governance for AI Agents Guide and 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 OAuth authorisation; no static secrets in local tool configuration. |
| 4 | An 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? The MCP authorisation specification requires clients to name the target server in a resource parameter (RFC 8707) so that tokens are bound to it. 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; a 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? OWASP's ASI10 (Rogue Agents) mitigations include immutable, signed audit logs and "kill-switches and credential revocation to instantly disable rogue agents". See the AI Agent Observability and Incident Response Guide.
How to use the model
- Agree the scope: include coding agents, low-code and SaaS agents, and agents built in-house. Shadow agents found later count against discovery, not outside the model.
- Score each dimension from 1 to 5 using the descriptions and evidence: registry exports, token lifetimes, role definitions, log samples and the record of the last time an agent was stopped.
- 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.
Use the dimension scores for engineering backlogs and the overall level and metrics for the board. See the Board and CISO Briefing.
A typical roadmap from Level 1 to Level 3
| Phase | Actions | Evidence of done |
|---|---|---|
| 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; separate staging and production credentials | A first inventory with owners; no agent on a human's token; no credential valid in more than one environment |
| 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 | Registration required before credentials; allowlist enforced; approval logs for destructive actions |
| Six to twelve months | Short-lived, platform-issued credentials; attributable logging across agent platforms; access reviews for agents; a rehearsed procedure to stop an agent and revoke its credentials | Median credential lifetime in hours, not months; review completion rate; timed kill-switch exercise |
See the AI Agent Deployment Checklist.
Beyond Level 3
Level 4 is worth the effort for agents that move money, change production or read regulated data. The steps that separate Level 3 from Level 4 are:
- Token exchange for delegation: exchange the user's token for one that names the agent as actor (RFC 8693) and narrows scope at each hop, rather than forwarding the original token.
- Per-action authorisation: route tool calls through a policy decision point that sees agent, user, resource and context, as OWASP recommends for ASI03.
- Sender-constrained credentials: mutual TLS or DPoP for high-value APIs, so a token copied out of memory or logs is useless elsewhere.
- Change-triggered review: a new model, prompt, tool or autonomy level reopens the agent's access review automatically.
- Tested containment: a kill switch exercised on a schedule, with the time from decision to full revocation measured.
Level 5 depends on capabilities still being standardised, such as attestation of agent configuration and cross-organisation agent trust. Track them in the Agent Identity Standards Tracker and see the Zero Trust for AI Agents Guide.
Mapping to frameworks
None of the general frameworks has an agent-specific control set yet, so the mapping below shows where each dimension's evidence lands. Treat it as a sense check, not an equivalence.
| Dimension | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 | OWASP NHI / Agentic |
|---|---|---|---|---|---|
| Discovery and inventory | ID.AM-02, ID.AM-08 | CM-08 | 5.9 | 2, 5 | NHI1 |
| Identity and authentication | PR.AA-01, PR.AA-03 | IA-04, IA-05, IA-09 | 5.16, 5.17, 8.5 | 5 | NHI4, NHI7, NHI8, NHI9, NHI10; ASI03 |
| Authorisation | PR.AA-05 | AC-06 | 5.15, 5.18, 8.2 | 6 | NHI5; ASI02, ASI03 |
| Delegation | PR.AA-04, PR.AA-05 | AC-06, AU-10 | 5.15, 5.18 | 6 | ASI03, ASI07 |
| Lifecycle and governance | GV.RR-02, ID.AM-08 | AC-02 | 5.18 | 5 | NHI1 |
| Tools and supply chain | GV.SC-07 | SA-09, SR-03 | 5.19, 5.21 | 15, 16 | NHI3; ASI04 |
| Monitoring and response | PR.PS-04, DE.CM-09, RS.MI-01 | AU-02, AU-03, AU-06, IR-04 | 8.15, 8.16 | 8, 17 | ASI10 |
AI governance frameworks ask for outcomes that depend on the same dimensions:
| Framework | What it asks for | Dimensions that provide the evidence |
|---|---|---|
| NIST AI RMF 1.0 | Inventory of AI systems (GOVERN 1.6), safe decommissioning (GOVERN 1.7), monitoring in production (MEASURE 2.4), mechanisms to "supersede, disengage, or deactivate" AI systems (MANAGE 2.4) | Discovery, lifecycle, monitoring and response |
| EU AI Act (high-risk systems) | Automatic recording of events over the system's lifetime (Article 12); human oversight, including the ability to interrupt the system through a "stop" button or similar (Article 14); deployers keep logs for at least six months (Article 26) | Monitoring and response, authorisation (approval steps) |
| NIST NCCoE agent identity concept paper | Identification, authorisation, access delegation, logging and transparency, data flow tracking | Identity, authorisation, delegation, monitoring |
See the Agentic AI Compliance Guide for the detailed obligations.
Common failure patterns
- Agent finds a stronger credential: in the PocketOS Database Deletion 2026, a coding agent working in staging found a Railway API token in an unrelated file and used it to delete a production volume and its backups. The token had been created to manage custom domains but carried authority over the whole account. Scoped tokens and environment isolation (OWASP NHI8) would have contained it.
- Instructions instead of permissions: in the Replit AI Agent Database Deletion 2025, an agent deleted a live production database during a declared code freeze, against explicit instructions. Replit's response was technical: automatic separation of development and production databases and a planning-only mode. A freeze must be enforced in access, not in the prompt.
- Agent keys treated as low value: in the Moltbook Database Exposure 2026, Wiz says 1.5 million agent API authentication tokens were readable, and with any agent's key a stranger could post as that agent. Agent credentials are identities and need the same protection as any other secret.
- Inherited privilege in multi-agent flows: an orchestrator passes its full access to a narrow worker, the "un-scoped privilege inheritance" OWASP describes under ASI03.
- Kill switch never tested: a documented stop procedure that nobody has run, so tokens, OAuth grants and MCP credentials stay live after the agent process is stopped.
- Ownerless agents: pilots end, owners move on and the agent keeps its credentials, the agent version of OWASP's improper offboarding.
See the Top 10 Agentic AI Identity Issues.
Metrics that show maturity
| Metric | What it shows | Target direction |
|---|---|---|
| Agents in the registry with a named owner (%) | Discovery and governance coverage | Up, towards 100% |
| Agents running on their own identity (%) | End of borrowed and shared credentials | Up, towards 100% |
| Agent credentials with no expiry | Exposure to long-lived secrets | Down, towards zero |
| Agents holding admin or wildcard scopes | Blast radius if an agent is hijacked | Down, towards zero |
| High-impact actions behind human approval (%) | Human oversight where it matters | Up |
| Time to stop an agent and revoke all its credentials | Containment readiness, from the last exercise | Down, towards minutes |
| Agent actions attributable to agent and principal (%) | Logging and delegation quality | Up, towards 100% |
| Unapproved MCP servers or tools found per quarter | Supply chain control | Down |
Practitioner checklist
- Score all seven dimensions with production evidence and record the lowest as your level.
- Set Level 3 as the 12-month target, with Level 4 for agents that move money, change production or read regulated data.
- Build an agent registry and require registration before any credential is issued.
- Name an owner for every agent and suspend agents that lose theirs.
- Remove personal tokens, shared accounts and admin roles from agents.
- Keep staging and production credentials separate, and scope every token to one purpose.
- Require human approval for irreversible and high-value actions, enforced in access rather than prompts.
- Bind tokens to their audience and never pass user tokens through to downstream services.
- Allowlist MCP servers and tools, and keep secrets out of tool configuration.
- Log every action with agent, principal, tool and outcome, and rehearse the kill switch.
- Baseline the metrics above and reassess every six months.
Standards and references
- NIST NCCoE: Accelerating the Adoption of Software and AI Agent Identity and Authorization (concept paper)
- NIST: AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
- NIST: The NIST Cybersecurity Framework (CSF) 2.0
- EUR-Lex: Regulation (EU) 2024/1689 (Artificial Intelligence Act)
- OWASP: Top 10 for Agentic Applications for 2026
- OWASP: Non-Human Identities Top 10 (2025)
- Model Context Protocol: Authorization
- Model Context Protocol: Security Best Practices
- IETF: RFC 8693 OAuth 2.0 Token Exchange
- IETF: RFC 9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)
- SPIFFE: SPIFFE Overview
How NHI Mgmt Group can help
We run independent NHI and agentic AI maturity assessments against this model, build business cases and roadmaps, and support RFP strategy for agent identity programmes. Our NHI training includes an Agentic AI module, and the NHI and AI products directory lists tools by capability. Contact us to discuss an assessment.
Related NHI Mgmt Group resources: Agentic AI Identity Guide · AI Agent Identity Security Buyer's Guide · NHI Governance Maturity Model · AI Security Maturity Model · Board and CISO Briefing