Most organisations now run MCP servers and agent-to-agent connections faster than they can say which ones exist, who approved them and what tokens they hold. Model Context Protocol (MCP) servers, A2A agents and the platforms that host them have become a new integration layer, and each connection is a non-human identity with access to data and tools. This maturity model scores that layer across seven capability areas and five levels, from ad hoc developer installs to a governed, monitored protocol estate. It is written for platform, security architecture and IAM teams who need a shared baseline and a realistic next step. Agent identity in general is scored in the Agentic AI Identity Maturity Model; this model covers what sits on top of it: protocol conformance, server trust, gateways, registries and protocol-level monitoring.
Key takeaways
- Inventory caps every other score. You cannot be above Level 2 in any area if you cannot list the MCP servers and agent endpoints your users and platforms connect to.
- Specification conformance is a Level 3 test, not a nice-to-have. The MCP 2025-11-25 authorisation specification makes Protected Resource Metadata, PKCE with S256, the
resourceparameter and token audience validation mandatory for HTTP servers that implement authorisation. - Token passthrough is the clearest Level 1 marker. The specification forbids an MCP server from accepting or forwarding tokens not issued for it, yet proxy-style servers still do it.
- Local servers are code execution. A stdio MCP server runs with the user's privileges; maturity means consent, sandboxing and an allowlist, not trust in the package name.
- Level 3 is the realistic target. Owned and registered servers, conformant authorisation, a gateway in the path for remote servers and per-call logs are achievable within a year for most enterprises.
The five levels
| Level | Name | Description |
|---|---|---|
| 1 | Ad hoc | Developers and business users add MCP servers and agent connectors themselves. No inventory, shared or personal tokens in configuration files, no logging beyond what each client keeps. |
| 2 | Developing | A partial list of approved servers exists and a policy says what may be connected. Some remote servers use OAuth, but conformance is not tested and local servers are unmanaged. |
| 3 | Defined | Every server and agent endpoint is registered with an owner. Remote servers pass a conformance check against the current MCP authorisation specification, traffic goes through a gateway or approved client, and every tool call is logged with user and agent identity. |
| 4 | Managed | Scopes are minimal and stepped up per operation, tool definitions are pinned and change-detected, A2A Agent Cards are signed and verified, and detections run on protocol telemetry with tested response playbooks. |
| 5 | Optimised | Policy decides each tool call at runtime using user, agent, data and risk context. Unregistered servers cannot obtain tokens, cross-organisation agent trust is governed, and controls are measured and tuned from incidents and testing. |
The level names match the five-level NHI Mgmt Group scale used in the NHI Governance Maturity Model, so scores can be compared across programmes.
Capability areas
Score each area separately. Report the profile, not an average: a Level 4 gateway does not compensate for a Level 1 inventory.
1. Inventory and registry
| Level | What it looks like |
|---|---|
| 1 | No list. Servers live in individual mcp.json or client configuration files on laptops and in agent code. |
| 2 | A spreadsheet of approved remote servers; local servers on endpoints are found only by occasional sweeps. |
| 3 | A private registry or catalogue holds every approved server and agent endpoint with owner, purpose, transport, tools exposed, data reached and credentials used. Endpoint and code scanning feeds it regularly. |
| 4 | Discovery is continuous across endpoints, repositories, cloud and identity provider logs; drift between the registry and reality raises a ticket. |
| 5 | Clients and gateways resolve servers only from the registry, so an unregistered server cannot be reached or issued a token. |
The official MCP Registry is in preview and, by its own documentation, does not support private servers and is not designed for self-hosting; it recommends a private registry for internal servers and delegates security scanning to package registries and downstream aggregators. Treat public registry presence as proof of namespace ownership only, not of safety. See the MCP Server Inventory Template and MCP Registry and Server Publishing Security Guide.
2. Authorisation and specification conformance
| Level | What it looks like |
|---|---|
| 1 | Remote servers accept static API keys or no authentication; some forward the caller's token to downstream APIs. |
| 2 | OAuth used for some servers, often with broad scopes and Dynamic Client Registration left open. |
| 3 | Remote servers publish Protected Resource Metadata (RFC 9728), validate token audience, reject tokens not issued for them, and clients use PKCE (S256) and the resource parameter (RFC 8707). Conformance is tested before go-live. |
| 4 | Minimal initial scopes with step-up through insufficient_scope challenges; short-lived access tokens; refresh token rotation for public clients; Client ID Metadata Documents or pre-registration instead of open registration. |
| 5 | Enterprise-managed authorisation ties MCP access to the corporate identity provider; per-call decisions combine token claims with runtime policy. |
The current specification (version 2025-11-25) builds on the OAuth 2.1 draft and lists Client ID Metadata Documents as a SHOULD and Dynamic Client Registration as a MAY, kept for backwards compatibility. The MCP authorisation extensions repository lists Enterprise-Managed Authorization as stable and Client Credentials as a draft (checked 11 November 2026). See the MCP Authorisation Specification Guide.
3. Server trust and supply chain
| Level | What it looks like |
|---|---|
| 1 | Servers installed from any package or one-click link; unpinned versions run with npx or uvx at start-up. |
| 2 | A review before approval, but versions float and tool descriptions are not recorded. |
| 3 | A trust assessment per server (publisher, code, permissions, data flows); versions and package hashes pinned; tool names and descriptions captured at approval. |
| 4 | Tool definition changes (including notifications/tools/list_changed events) are detected and block use until re-approved; internal mirror for packages; SBOM per server. |
| 5 | Signed builds and provenance verified at deployment; publisher risk rescored continuously. |
The postmark-mcp malicious server showed why version pinning matters: a trusted-looking package changed one line and began copying every email to an attacker. See the MCP Server Trust Assessment.
4. Local server and client hardening
| Level | What it looks like |
|---|---|
| 1 | Any user can add a local server; clients run them with full user privileges. |
| 2 | Guidance tells users what not to install; no technical enforcement. |
| 3 | Managed client configuration with an allowlist; clients show the full command before first run; local HTTP servers require a token or use stdio or IPC with restricted access. |
| 4 | Local servers run sandboxed (containers or OS sandboxes) with explicit file system and network grants; clients reject dangerous URL schemes and never open URLs through a shell. |
| 5 | Endpoint controls block unapproved server binaries and alert on credential access by MCP processes. |
The specification's security best practices say clients offering one-click local configuration MUST show the exact command without truncation and require explicit approval, and SHOULD sandbox servers with minimal default privileges. The Amazon Q MCP configuration vulnerability shows what happens when a repository can supply the configuration. See the Local MCP Server Security Guide.
5. Gateways and runtime policy
| Level | What it looks like |
|---|---|
| 1 | Clients connect straight to any remote server on the internet. |
| 2 | Egress allowlists for known server hostnames. |
| 3 | Remote MCP traffic goes through a gateway or approved hosting platform that enforces the registry, authenticates both sides and logs every call. |
| 4 | Per-tool policy (read versus write, data classification, human approval for irreversible actions); SSRF controls on OAuth discovery fetches; egress proxy for server-side clients. |
| 5 | Context-aware decisions per call, with automatic step-up or block on risk signals and a tested kill switch for a server or tool. |
SSRF controls are not theoretical: the security best practices describe malicious servers pointing resource_metadata or authorisation server URLs at internal addresses such as 169.254.169.254, and say clients SHOULD block private and link-local ranges. See the MCP Gateway and MCP Server Governance Guide.
6. Agent-to-agent protocols
| Level | What it looks like |
|---|---|
| 1 | Agents call other agents with shared keys; Agent Cards fetched and trusted as-is. |
| 2 | TLS everywhere; authentication declared in securitySchemes but not consistently enforced. |
| 3 | Every request authenticated, as A2A requires; extended Agent Cards only to authenticated clients; partner agents registered like suppliers. |
| 4 | Agent Cards signed (JWS over an RFC 8785 canonical form) and verified before trust; mutual TLS or OAuth client credentials for agent identity; credentials obtained in the TASK_STATE_AUTH_REQUIRED state never reused beyond their stated scope. |
| 5 | Delegation chains recorded and narrowed at each hop; cross-organisation trust governed by contract and technical policy. |
A2A version 1.0 states servers MUST authenticate every incoming request, that the auth-required task state alone MUST NOT be treated as authorisation, and that clients SHOULD verify at least one Agent Card signature before trusting a card. See the A2A Protocol Security Guide and A2A Agent Card Security Guide.
7. Monitoring, testing and response
| Level | What it looks like |
|---|---|
| 1 | No protocol logs; incidents found by users. |
| 2 | Client logs collected on request; servers log errors only. |
| 3 | Each tool call logged centrally with user, agent, server, tool, arguments summary, result status and scope elevation events, using correlation IDs. |
| 4 | Detections for new servers, tool definition changes, token audience failures, bulk reads and unusual outbound destinations; security tests (prompt injection through tool results, token handling) before release; a written MCP incident playbook exercised. |
| 5 | Red-team findings and incidents feed policy changes, with metrics reviewed by an owner each quarter. |
The Sentry MCP agentjacking case is a reminder that tool results are untrusted input: logging what a tool returned is as important as logging what was called. See the MCP Security Testing Guide and MCP Incident Response Playbook.
Self-assessment questions
| Area | Question | A "no" usually means |
|---|---|---|
| Inventory | Can you list every MCP server used on managed laptops this week, with an owner for each? | Level 1 to 2 |
| Authorisation | Do all internal remote servers reject a valid token issued for a different audience? | Level 2 or below |
| Authorisation | Does any server forward the client's token to a downstream API? | A "yes" is Level 1 |
| Supply chain | Would you know within a day if an approved server changed a tool description? | Level 3 or below |
| Local servers | Can a user add a stdio server that runs an arbitrary command without IT seeing it? | A "yes" is Level 2 or below |
| Gateway | Is human approval enforced for irreversible tools (delete, pay, send externally)? | Level 3 or below |
| A2A | Do you verify signatures on partner Agent Cards before trusting them? | Level 3 or below |
| Monitoring | Could you show, for one tool call last month, which user, which agent and which token caused it? | Level 2 or below |
Where identity fits
Every MCP client registration, server-to-API credential and A2A agent is a non-human identity. Three identity questions decide most scores: whose authority a call carries (the user's delegated token or the server's own credential), whether that credential is scoped and short-lived, and whether it can be revoked without breaking unrelated workflows. Servers that hold their own upstream credentials should keep them in a secrets manager, rotate them and record them in the NHI inventory. The LiteLLM MCP authentication bypass showed how a gateway's default master keys become the weakest identity in the estate. See the Agentic AI Identity Guide.
Moving up: roadmap
- Find what exists (weeks 1 to 4): scan managed endpoints for MCP client configuration files, search repositories for MCP SDK imports and Agent Card endpoints, and pull OAuth grants to AI clients from the identity provider. Load results into the registry with an owner per entry.
- Stop the Level 1 patterns (weeks 3 to 8): remove token passthrough, static keys in shared configuration and servers with no owner. Disable unknown local servers in audit mode first, then enforce the allowlist through managed client settings.
- Test conformance (months 2 to 4): for each internal remote server, test 401 handling with Protected Resource Metadata, audience rejection, PKCE enforcement and rejection of tokens in query strings. Record pass or fail in the registry.
- Put a gateway in the path (months 3 to 6): route remote servers through a gateway in log-only mode, compare its view with the registry, then enforce. Keep a rollback path that returns to direct egress allowlists if the gateway fails.
- Pin and watch tools (months 4 to 8): pin versions and hashes, store approved tool definitions and block on change until re-review.
- Extend to A2A and partners (months 6 to 12): require signed Agent Cards and authenticated requests for partner agents, and add them to third-party risk reviews.
- Measure and repeat: re-score every six months and after any protocol-related incident.
Small versus large organisations: a small team can reach Level 3 with managed client settings, a short approved list and a hosted gateway. Large organisations usually need a private registry, identity provider integration for enterprise-managed authorisation and a platform team that owns the gateway as a product.
Metrics that show progress
- Percentage of discovered servers that are registered with an owner.
- Percentage of remote servers passing the conformance test.
- Number of servers or tools in use with unpinned versions.
- Median time from a tool definition change to re-approval or block.
- Percentage of tool calls attributable to both a user and an agent identity.
Framework mapping
| Capability area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | Threat references |
|---|---|---|---|
| Inventory and registry | ID.AM-02, ID.AM-04 | CM-8 | OWASP ASI04 Agentic Supply Chain Vulnerabilities |
| Authorisation and conformance | PR.AA-01, PR.AA-05 | AC-6, IA-9 | ATT&CK T1528 Steal Application Access Token, T1550.001 Application Access Token |
| Server trust and supply chain | GV.SC-07 | SR-3, SA-9 | ATT&CK T1195.002; ATLAS AML.T0010 AI Supply Chain Compromise |
| Local server hardening | PR.PS-01 | CM-7 | OWASP ASI05 Unexpected Code Execution |
| Gateways and runtime policy | PR.AA-05 | AC-4, AC-6 | ATLAS AML.T0053 AI Agent Tool Invocation; OWASP ASI02 Tool Misuse and Exploitation |
| Agent-to-agent protocols | PR.AA-01 | IA-9 | OWASP ASI07 Insecure Inter-Agent Communication |
| Monitoring and response | DE.CM-09 | AU-2, AU-12, SI-4, CA-7 | ATLAS AML.T0051 LLM Prompt Injection, AML.T0086 Exfiltration via AI Agent Tool Invocation |
Common failure patterns
- Scoring the gateway, not the estate: teams report Level 4 because a gateway exists, while most traffic comes from local stdio servers the gateway never sees.
- Publishing every scope: the specification lists publishing all possible scopes in
scopes_supportedand wildcard scopes as common mistakes; a stolen token then reaches every tool. - Trusting registry listings: namespace verification proves who published a server, not that its code is safe.
- Sessions used as authentication: the specification says servers MUST NOT use sessions for authentication and MUST verify every inbound request; servers behind load balancers with shared queues are most exposed.
- Hosting platforms with one master token: the Smithery.ai hosting breach exposed a single token controlling thousands of hosted servers.
- Averaging scores: an overall 3.1 hides a Level 1 in local server control.
Practitioner checklist
- Score all seven areas and report the profile, with inventory as a cap.
- Build a private registry with owner, transport, tools and credentials for every server and agent endpoint.
- Remove token passthrough and static shared keys from every MCP server.
- Test internal remote servers against the 2025-11-25 authorisation requirements before go-live.
- Enforce a managed allowlist for local servers and sandbox those you approve.
- Pin server versions and block on tool definition changes until re-reviewed.
- Route remote MCP traffic through a gateway with per-call logging and SSRF controls.
- Require authenticated requests and signed Agent Cards for partner A2A agents.
- Re-score every six months and after any protocol-related incident.
Standards and references
- Model Context Protocol: Authorization specification (2025-11-25)
- Model Context Protocol: Security Best Practices
- Model Context Protocol: The MCP Registry
- A2A Protocol: Specification
- OWASP GenAI Security Project: Top 10 for Agentic Applications for 2026
- IETF: RFC 9728 OAuth 2.0 Protected Resource Metadata
- IETF: RFC 8707 Resource Indicators for OAuth 2.0
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: MCP Security Guide · MCP Server Security Checklist · Unsanctioned AI Agents and MCP Servers Guide · Agent Protocols Compared · Agentic AI Identity Maturity Model