MCP’s security model exposes new trust gaps for agentic AI

At a glance

What this is: This is an analysis of MCP as the protocol layer for agentic AI tool access, with a focus on the trust and authentication gaps that appear when agents connect to local or remote servers.

Why it matters: IAM, PAM, and NHI teams need to decide how agent-to-tool trust is brokered, because MCP shifts control from static integration design to runtime identity, token, and server authorization decisions.

Context

MCP, or Model Context Protocol, is a standard for how agentic applications discover tools and resources, call remote services, and exchange data with servers. The security gap is that the protocol makes tool access easier to standardise while also expanding the number of identities, tokens, and trust boundaries that must be governed.

In practice, that means the control problem moves away from simple integration and into runtime authorisation. If an agent can choose tools dynamically, the organisation must decide which MCP servers are trusted, how OAuth2 tokens are scoped, and where human approval still has to sit in the delegation chain.

Key questions

Q: What breaks when MCP servers are not governed like integrations?

A: What breaks is the trust boundary. If an MCP server can connect an agent to tools or data without clear ownership, logging, and access limits, the server becomes part of the effective attack path. That creates hidden delegation and makes it harder to prove which actions were authorised.

Q: Why do shared OAuth clients increase risk in Remote MCP deployments?

A: A shared OAuth client collapses many downstream users and tools into one upstream identity, which means consent decisions can be reused beyond their original context. That creates a larger attack surface for code leakage, redirect abuse, and unexpected token issuance. For practitioners, shared client_id designs require stronger session binding and stricter callback validation.

Q: How can security teams spot unsafe MCP server behaviour?

A: Look for servers that request secrets, widen access unexpectedly, or accept tokens that were not clearly approved for the current task. Suspicious behaviour also shows up when a server is added without ownership, review, or an offboarding path. Those are signs that the server is functioning as an unmanaged identity rather than a controlled integration point.

Q: Should organisations allow agentic apps to connect to any MCP server?

A: No. The safer model is to allow only explicitly approved servers, because dynamic tool discovery without a server allowlist makes it too easy for an agent to act on unvetted capabilities. Organisations should constrain server selection, separate trusted from untrusted sources, and require human approval for high-risk tool paths or privileged actions.

Technical breakdown

How MCP client-server architecture shapes agent trust

MCP uses a client-server model where the application is the client and the MCP server exposes tools, resources, prompts, and related capabilities through a common interface. That structure makes integrations portable, but it also centralises trust in the server boundary. The client and server may speak JSON-RPC, yet the security question is not transport syntax. It is whether the server is allowed to act as a delegated authority for the agent, and whether the application can prove which server was actually consulted at runtime.

Practical implication: inventory every MCP server as a governed trust boundary, not just an integration endpoint.

Why OAuth2 does not remove agent access risk

Streamable HTTP introduces OAuth2 so remote MCP servers can authenticate users and clients in a familiar way, but OAuth2 only solves part of the problem. A token that works for the MCP server must also be acceptable to the backend APIs the server calls, which creates a chain of trust across multiple services. If that chain is loose, the agent may authenticate successfully while still inheriting broader access than intended. In NHI terms, the token becomes a delegated credential whose blast radius depends on both scopes and downstream acceptance rules.

Practical implication: validate end-to-end token scope and backend acceptance before allowing remote MCP access.

How prompt injection and untrusted servers alter tool selection

MCP does not stop prompt injection, because the model still decides which tool to call at runtime. A malicious user prompt can steer the model toward an unsafe tool, and a malicious tool response can influence later decisions. That means the security model must treat both input prompts and server responses as control points. The risk is not only data leakage. It is action selection under manipulated context, where the agent’s apparent autonomy becomes a channel for misuse if the surrounding validation layer is thin.

Practical implication: put validation middleware on both prompt ingress and tool response egress before approving production use.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP turns trust boundaries into first-class identity controls. Once an agent can discover tools dynamically, the old assumption that integration paths are fixed no longer holds. The protocol makes server selection, token acceptance, and runtime authorisation part of the identity plane, not just the application stack. Practitioners should treat each MCP connection as a policy decision with a measurable blast radius.

OAuth2 is necessary here, but not sufficient as a governance model. The article’s example shows that a client token must be accepted by the MCP server and by the backend services behind it. That creates a delegated-identity chain, which means scope control must be assessed end to end instead of at the login step alone. Practitioners should re-evaluate whether their approval and federation assumptions still hold once the server becomes a policy-bearing intermediary.

Untrusted MCP servers create an NHI governance problem disguised as application flexibility. The article is clear that many community servers are immature, numerous, and not production-hardened. That is not just a software quality issue. It is a third-party NHI risk because the server may receive privileged access, tokens, or secrets on behalf of the agent. Practitioners should govern MCP servers as external identities with lifecycle, offboarding, and review requirements.

Prompt injection becomes more dangerous when the tool layer is also the identity layer. If the model can be nudged into choosing the wrong tool, the resulting action may still look authenticated and authorised. That collapse between apparent legitimacy and unsafe intent is what makes agentic systems different from traditional integrations. Practitioners should rethink whether current controls inspect the decision path, not just the final API call.

Runtime trust decisions need a named control boundary: agent-server trust policy. MCP adoption is pushing organisations toward a policy model that defines which servers an agent can reach, what tokens they can use, and which flows require human involvement. This is now an architectural governance issue, not an afterthought. Practitioners should separate tool discovery from tool authorisation if they want defensible control over agent behaviour.

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.
• Read next: MCP Security Guide

What this signals

MCP adoption changes the centre of gravity for identity governance because the trust decision now sits between the agent and the server, not just at user login or API onboarding. Teams that already govern service accounts and workload identities should extend the same discipline to MCP servers, token scopes, and approval paths.

Agent-server trust policy: The practical control gap is not whether an agent can call tools, but whether every server it can discover has a declared owner, approved scope, and an offboarding path. That is the boundary that will separate controlled agentic access from unmanaged tool sprawl.

NHI programmes should expect more pressure to classify remote MCP servers as third-party identities with lifecycle and access reviews. If that governance layer is missing, prompt injection, token reuse, and unreviewed server additions can turn a flexible protocol into a persistent trust problem.

For practitioners

• Register each MCP server as a governed trust boundary Maintain an inventory of local and remote MCP servers, classify them by data sensitivity and privilege level, and define who can approve each connection path.
• Validate OAuth2 scope end to end Check that access tokens issued to the client are accepted only by the backend services the agent truly needs, and reject implicit token reuse across unrelated APIs.
• Apply prompt and response validation controls Inspect user prompts and tool outputs for instruction injection, then block unsafe tool choices before the agent can execute privileged actions.
• Treat community MCP servers as third-party NHIs Require ownership, review, and offboarding for external servers that can receive secrets or privileged access, just as you would for other non-human identities.

Key takeaways

• MCP makes tool access easier to standardise, but it also expands the identity and trust surface that security teams must govern.
• The main security pressure points are OAuth2 scope, prompt injection, and whether remote servers inherit more authority than the task requires.
• Controlled MCP adoption depends on inventorying servers, constraining token use, and treating third-party servers as governed non-human identities.

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.
• AI Agent Trust Boundary: The set of data, systems, and actions an AI agent is allowed to interpret or control. For security teams, the boundary is not just the prompt or login session. It includes memory, tools, external sources, and destinations that can turn a model decision into real-world impact.
• Delegated Credential: A token, key, or other secret that allows one system to act on behalf of another identity. For agentic environments, delegated credentials matter because they extend trust into runtime, where the agent can use them to reach tools, data, or services without a fresh human approval.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.

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.