TL;DR: MCP standardises how AI apps connect to tools and data, but Apono’s analysis shows that the protocol also expands NHI exposure through standing tokens, over-scoped access, and weak auditability. The governance problem is not the protocol itself, but the identity controls around it.
At a glance
What this is: This is an analysis of seven security concerns in the Model Context Protocol, with the central finding that MCP’s growth widens NHI governance gaps when tokens, service accounts, and audit controls are not tightly managed.
Why it matters: It matters because IAM, PAM, and NHI teams now have to govern AI tool access as a live identity problem, not just an integration pattern, or risk uncontrolled access paths and weak accountability.
By the numbers:
- 20% of organisations experienced breaches tied to unauthorized AI tools, with each incident costing up to $670,000 on average.
Context
MCP, or Model Context Protocol, standardises how AI applications connect to tools and data, but that convenience also turns every integration into an identity decision. The first governance question is no longer whether the connection works, but which non-human identities are authorised to use it, for how long, and under what scope.
The article’s core problem is not protocol design in isolation. It is the way MCP implementations inherit standing tokens, service accounts, and opaque tool access patterns that most IAM programmes were not built to govern at machine speed. That makes visibility, scoping, and revocation part of the design problem rather than an afterthought.
Key questions
Q: What breaks when MCP access is left on long-lived tokens?
A: Long-lived tokens assume access is stable enough to review later, but MCP workflows often involve temporary, multi-step delegation. That creates standing trust where task-bound trust is needed, increases blast radius if a token is reused, and makes offboarding or revocation harder to prove.
Q: Why do MCP deployments create audit and accountability gaps for AI agents?
A: Because the protocol can hide who invoked the tool, which context was used, and what data moved downstream unless logging is designed into the control path. Without that linkage, security teams cannot reconstruct model actions, prove proper authorisation, or separate legitimate automation from misuse.
Q: How should security teams govern NHI access when exposing internal tools through MCP?
A: Treat each MCP server as a governed NHI boundary. Teams should define scope, ownership, expiry, and revocation for every non-human identity used by the protocol, then restrict tool registration to approved servers and validate every call server-side before execution.
Q: What is the difference between an MCP integration and a governed AI access model?
A: An MCP integration only proves that the tool connection works. A governed AI access model also proves that the right identity is calling the right tool, with the right scope, for the right duration, and with traceable evidence after the fact.
Technical breakdown
How MCP clients and servers create an identity control plane
MCP uses a client-server model in which an AI host sends structured requests to an MCP server, which then invokes the underlying API or tool and returns the result. That architecture removes the need for one-off connectors, but it also centralises trust in the server boundary. If the server is not bound to a strong identity model, any model that can reach it may inherit capabilities far beyond the original use case. In practice, the protocol turns tool access into a governed identity path rather than a mere integration detail.
Practical implication: Treat each MCP server as an identity boundary and define explicit authorisation and provenance rules before exposing tools.
Why standing tokens and service accounts are the main NHI risk
MCP deployments commonly rely on API keys, OAuth tokens, and service accounts to make AI tool calls work. Those are non-human identities, and in many environments they are long-lived, broadly scoped, and reused across tools or environments. Once a token is embedded in a config file or runtime and left in place, the access path outlives the original task. That is what turns a convenience layer into privilege sprawl: the credential becomes durable infrastructure instead of ephemeral authorisation.
Practical implication: Map every MCP credential to an owner, scope, and expiry condition so stale access can be removed before it becomes a standing privilege path.
Why auditability breaks when tool use is mediated by models
MCP can hide the operational trail if logging does not capture which model called which tool, with what input, and in what context. Without that linkage, security teams cannot distinguish legitimate automation from misuse, and compliance teams cannot reconstruct who or what accessed sensitive records. The issue is not only logging volume. It is attribution, because the control has to show the identity chain from model request to downstream action. Without that, the platform may be technically functional while remaining operationally ungovernable.
Practical implication: Require invocation-level logging that binds model context, tool identity, and request parameters into SIEM-visible records.
Threat narrative
Attacker objective: The objective is to convert routine AI tool access into persistent reach over sensitive business data and operational systems.
- Entry occurs when an AI application gains access to an MCP server through a standing token, service account, or OAuth credential that was created for routine tool use.
- Escalation follows when that credential is over-scoped, reused across environments, or left active after its original purpose changed, giving the model broader tool reach than intended.
- Impact occurs when the model, or an attacker manipulating it, uses that persistent access to read sensitive data, trigger unintended actions, or move into production systems.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
MCP is not the governance problem. Standing machine access is. The protocol simply makes the access path easier to wire up and harder to ignore. The real failure is that many programmes still treat model connectivity as integration plumbing rather than as a governed NHI estate. Practitioners should reframe MCP adoption as an identity lifecycle problem, not a tooling convenience problem.
Long-lived credential exposure window: This is the specific failure mode MCP sharpens. Tokens, service accounts, and API keys often survive far beyond the task they were created for, so the access window is defined by human memory rather than policy. That breaks the core NHI assumption that access can be provisioned, observed, and retired on a manageable lifecycle.
Auditability is becoming a first-class control, not a reporting feature. MCP-driven tool use can look clean at the protocol layer while remaining opaque at the governance layer. If the organisation cannot bind model, tool, and downstream action into a traceable identity chain, accountability collapses at the point where the agent acts. Teams need to treat traceability as part of authorisation, not as a post-event log search.
The MCP risk surface is a preview of broader agentic governance pressure. AI systems that use tools through structured protocols will keep expanding, and the surrounding identity model will determine whether that expansion is controllable or chaotic. The important question is not whether organisations will adopt tool-connected agents, but whether they will govern them with the same discipline already expected for privileged machine accounts.
Named concept: MCP identity sprawl. MCP identity sprawl is the accumulation of broad, persistent, and poorly attributed non-human access as AI integrations multiply. It matters because each new server or tool adds another credential, another trust edge, and another offboarding obligation. Practitioners should expect the control burden to grow faster than the connector count if identity governance is not designed in from the start.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- Read next: MCP Security Guide
What this signals
MCP identity sprawl: As AI integrations multiply, the hidden risk is not the protocol itself but the accumulation of credentials, trust edges, and offboarding debt around each server. If teams do not define ownership and expiry for every tool-facing NHI, the environment will become harder to govern than the AI use case justifies.
Access reviews are a weak control for MCP if the credential can be created, used, and forgotten inside the same operational cycle. The stronger control point is issuance time, where scope, expiry, and server provenance can still be enforced before the model receives access.
For practitioners
- Map every MCP credential to an owner and expiry Inventory API keys, service accounts, and OAuth tokens used by MCP servers, then attach lifecycle ownership, intended scope, and a removal trigger for each one.
- Bind tool access to the requesting identity context Require each MCP request to carry validated tenant, user, or agent context so the server can enforce scope before any downstream action is executed.
- Instrument invocation-level audit logs Log the model, tool, parameters, response metadata, and timestamp for every MCP call, then route the records into your SIEM for correlation.
- Replace standing privileges with short-lived access Use JIT access patterns for MCP-connected identities so credentials expire after the task, not after the team remembers to revoke them.
- Review tool provenance before registration Allow only approved MCP servers and tool names, and reject unauthenticated registration paths that could let a rogue server impersonate a trusted tool.
Key takeaways
- MCP turns AI tool connectivity into an identity governance problem because the protocol depends on tokens, service accounts, and other non-human access paths.
- The main risk is not the standard itself but the standing credential model around it, especially where audit trails and expiry rules are weak.
- Practitioners should govern MCP servers as controlled identity boundaries, with short-lived access, explicit ownership, and traceable tool invocation logs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | MCP deployments depend on exposed API keys and tokens that often leak into configs or runtimes. |
| NHI-05 — Overprivileged NHI | The article’s main governance gap is broad, persistent access granted to AI-connected non-human identities. | |
| NHI-07 — Long-Lived Secrets | The article repeatedly highlights static credentials that outlive the task or environment they were created for. | |
| Recommendation — Scan MCP environments for leaked credentials and revoke any secret exposed in configs, logs, or agent runtimes. Reduce MCP tool scopes to the minimum permissions needed and remove standing access that exceeds task scope. Replace long-lived MCP credentials with short-lived access and enforce expiry as part of issuance. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | MCP tool access is an entitlement problem that must be governed across identities and environments. |
| Recommendation — Apply entitlement controls to every MCP-connected identity and verify tool access before execution. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article’s risk path runs through credential abuse and broader tool access once a token is compromised. |
| Recommendation — Map MCP credential exposure to credential access and lateral movement and monitor for unusual tool invocation patterns. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
- Action Provenance: Action provenance is the record of who initiated a task, which identity executed it, what tool was used, and what decision was made at runtime. It is essential when delegated work crosses systems because it preserves accountability even when the original request and the final action are separated by many steps.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org