MCP server security creates new identity governance gaps for AI agents

At a glance

What this is: This is a security analysis of the Model Context Protocol and the identity risks it introduces when AI systems connect to enterprise tools and data sources.

Why it matters: It matters because MCP turns every tool connection into an identity and access decision, which affects NHI governance, autonomous agent control, and human IAM oversight.

By the numbers:

• 20% of organizations experienced breaches tied to unauthorized AI tools, with each incident costing up to $670,000 on average.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Apono's analysis of MCP server security and identity risk

Context

MCP server security is a governance problem as much as it is an integration problem. The protocol makes it easier to expose internal tools to AI systems, but it also assumes that the identities behind those connections are already scoped, observable, and revocable. In practice, many deployments rely on service accounts, API keys, and tokens that were never designed for broad model-driven access.

The article’s central point is that standardisation lowers engineering friction while widening the identity attack surface if access management lags behind adoption. That means IAM, PAM, secrets management, and workload identity controls all become part of the MCP decision, not just the tooling decision. For teams building AI-enabled workflows, the real question is whether the access model matches the speed and reach of the protocol.

Key questions

Q: How should security teams govern MCP tool access in production environments?

A: Security teams should treat MCP tool access like any other privileged integration. That means binding every tool call to a verified identity, scoping permissions to the minimum task, and preventing shared credentials from crossing tenants or environments. If the server cannot prove who requested the action and why, the access model is too broad for production use.

Q: Why do MCP integrations increase NHI risk in AI workflows?

A: MCP integrations increase NHI risk because they rely on service accounts, tokens, and API keys to let AI systems reach real tools and data. If those credentials are long-lived or over-scoped, the model inherits more authority than it needs. That turns a helpful integration into a durable path for data exposure and unintended actions.

Q: What breaks when MCP servers do not enforce tool scoping?

A: When MCP servers do not enforce tool scoping, models can reach tools and data across users, tenants, or environments that were never meant to be shared. The failure is usually not obvious at the interface level. It appears later as leakage, unauthorised actions, or audit gaps that are hard to reconstruct after the fact.

Q: Who is accountable when an AI agent misuses MCP-connected credentials?

A: Accountability sits with the organisation that defined the identity, scope, and logging model for the integration. If credentials were left broad, static, or unbound to request context, the failure is governance, not model behaviour alone. Teams should assign ownership for tool identities, access reviews, and incident traceability before deployment.

Technical breakdown

MCP client-server architecture and tool delegation

MCP uses a client-server pattern in which an AI host sends structured requests to a tool server, receives the result, and continues the session with that data. This is valuable because it removes one-off connectors, but it also means the model becomes an active consumer of enterprise capabilities through a delegated execution path. The security boundary is no longer the UI, it is the tool server and the identity attached to it. If that server is trusted too broadly, every downstream action inherits the server’s privilege scope rather than the user’s intent.

Practical implication: Treat every MCP server as a privileged integration surface and require explicit scoping, authentication, and policy enforcement before tool exposure.

Standing privileges in MCP-connected NHI credentials

MCP deployments often depend on long-lived non-human identities such as service accounts, OAuth tokens, and API keys. Those credentials are frequently persistent, broad, and embedded in configuration or runtime systems, which makes them a natural target for abuse once an AI tool can act at scale. The problem is not only compromise, but persistence. A token that was acceptable for a staging workflow can quietly remain active after the workflow changes, creating access that outlives the original purpose. That is classic privilege sprawl, now attached to AI-mediated execution.

Practical implication: Move MCP integrations toward short-lived, tightly scoped credentials and remove hard-coded or environment-wide tokens from production paths.

Prompt injection, tool poisoning, and confused deputy risk

MCP does not prevent a model from being manipulated into using a legitimate tool in the wrong way. If input is not constrained, prompt injection can steer the model toward unauthorized parameters, while a confused deputy problem appears when the tool acts with broader authority than the request deserved. Both failure modes are access problems, not just model quality problems. They show up when the authorization layer trusts the model to self-police its tool use. In security terms, the issue is not whether the tool works, but whether the request context is bound to the right identity and scope.

Practical implication: Bind tool calls to the originating identity and request context, and put policy checks in front of execution rather than relying on the model to behave safely.

Threat narrative

Attacker objective: The attacker’s objective is to turn a trusted AI integration into a path for unauthorized data access, unintended actions, or silent compliance failure.

1. Entry occurs when an AI host is connected to enterprise tools through MCP and receives credentials or server access that exceed the task’s actual scope.
2. Escalation follows when the model invokes a tool with standing privileges, allowing broader data retrieval or action than the requester intended.
3. Impact occurs when those over-scoped credentials expose sensitive transcripts, customer data, or operational systems through a single delegated integration path.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standardised tool access has become an identity governance problem, not just an application design choice. MCP reduces connector sprawl, but it also concentrates privilege inside the server identity, which means the control failure shifts from code integration to access governance. That matters because a model can only act as safely as the identity behind its tool path allows. Practitioners should treat MCP as a governance surface before they treat it as an engineering convenience.

Standing privilege is the core failure mode in most MCP deployments. A token or service account that stays live across environments creates access that no longer matches the task, the tenant, or the session. In NHI terms, the issue is not merely credential exposure but privilege persistence after context has changed. This is where OWASP-NHI and Zero Trust thinking converge: the access path must be narrow enough to survive misuse, not just easy enough to deploy.

Cross-tenant data leakage is the visible symptom, but the underlying problem is missing identity context at request time. If MCP requests do not carry tenant, user, and purpose information, the server has no reliable way to scope the response. The result is not an API bug in the narrow sense, but an authorisation design that assumes the model will infer boundaries correctly. Practitioners should recognise that data segregation now depends on identity context being enforced at the tool layer.

Prompt injection becomes more dangerous when the model controls tools that can change state. Once a model can query, export, or modify production systems, malicious instructions can turn a benign prompt into a privileged operation. That makes the policy layer more important than the prompt layer, because the model is not the control. The implication for security teams is clear: tool use must be authorised outside the model, or MCP will amplify the blast radius of a single request.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a control lens on the same problem, see OWASP Agentic AI Top 10 for runtime governance and tool abuse patterns.

What this signals

Identity context is becoming the deciding factor in whether AI-enabled integrations remain governable. As MCP spreads, teams need to assume that every tool path can become a privileged execution path unless tenant, user, and purpose data are enforced at request time. That is why the access model, not the protocol banner, determines whether the programme is controllable.

Ephemeral credential trust debt: this is the growing gap between fast AI integration and the slower work of scoping, rotating, and auditing the identities behind it. Once that debt accumulates, the organisation inherits a control surface that looks modern but behaves like legacy privilege sprawl. The right response is to align access lifecycle controls with the speed of AI tool adoption.

With 53% of MCP servers exposing credentials through hard-coded values in configuration files, the operational signal is clear: secret handling and workload identity discipline will matter more than connector count. Teams should prepare for governance reviews that focus on where credentials live, how they are bound, and whether tool use is actually observable.

For practitioners

• Inventory every MCP-connected identity Map which service accounts, tokens, and API keys back each tool server, then document where those credentials are stored and which environments they can reach.
• Enforce request-level scoping for tool calls Pass tenant ID, user role, and purpose context into each MCP request and validate those fields server-side before any tool executes.
• Replace long-lived credentials with short-lived access Use short-lived tokens, JIT-style access, and regular rotation for any credential that can reach production data or state-changing tools.
• Log every model-to-tool transaction Capture the model, tool name, input parameters, response metadata, and identity context in a central log stream so investigations can reconstruct tool misuse.
• Block unverified tool registration Require mutual authentication and an approved registry for MCP servers so rogue or spoofed tools cannot enter the trust boundary.

Key takeaways

• MCP reduces integration friction, but it also concentrates risk inside the identities that power tool access.
• Standing credentials, weak scoping, and poor auditability are the main conditions that turn AI convenience into governance exposure.
• Teams that can bind, rotate, and observe tool identities will be better positioned to adopt MCP without expanding the attack surface uncontrollably.

Key terms

• MCP Server: An MCP server is the tool-facing component that exposes data or actions to an AI client through a standard protocol. In security terms, it is a privileged integration endpoint, so its identity, scope, and logging behaviour matter as much as its functionality.
• Standing Privilege: Standing privilege is access that remains continuously available rather than being granted only when needed. For MCP and other NHI deployments, it creates exposure when a credential can be reused across tasks, environments, or sessions long after the original use case changed.
• Confused Deputy: A confused deputy occurs when a trusted component uses its own authority to perform an action that the requester should not have been allowed to trigger. In MCP flows, it appears when a model or tool acts with broader privileges than the user intent justifies.
• Tenant-aware Access: Tenant-aware access means every request is evaluated in the context of the tenant, user, and purpose that originated it. It is the control that prevents shared tools from returning or modifying data outside the correct organisational boundary.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Apono: 7 Cybersecurity Concerns Related to The MCP Protocol. Read the original.