MCP client and server names invert the usual security model

At a glance

What this is: This is an analysis of why MCP client and MCP server mean the opposite of what many engineers expect, and why that naming matters for security boundaries.

Why it matters: It matters because identity and access decisions in MCP depend on understanding which component runs the agent loop, which component exposes tools, and where credentials actually live.

Context

MCP naming creates a governance problem before it creates a technical one: the words client and server suggest a familiar web model, but MCP flips that intuition. In practice, the MCP client is the component with the LLM and agent loop, while the MCP server exposes tools and may even run locally on the same machine.

That inversion matters because teams often map trust, credentials, and control ownership from the name alone. If the boundary is misunderstood, practitioners can misplace responsibility for tool access, credential storage, and runtime control, especially when integrating MCP security into desktop or local-agent workflows.

The article’s core point is not that MCP is broken, but that its vocabulary is hostile to first-time interpretation. Security teams should treat the naming as a documentation hazard and verify the actual execution model before they assign risk ownership.

Key questions

Q: How should security teams implement trust boundaries in MCP deployments with remote servers and upstream APIs?

A: Security teams should treat each MCP boundary as a separate trust decision. A token issued for one server must only be accepted by that server, and it should never be forwarded upstream. When a server needs another API, it should obtain its own credential. That preserves audience binding, prevents token laundering, and keeps attribution clear when actions are reviewed later.

Q: Why does clean core matter for identity and access governance?

A: Clean core matters because it changes where controls can live. When the SAP digital core is kept minimal, identity governance must operate through supported integrations and policy layers instead of bespoke code. That improves upgrade resilience, but only if IAM and GRC teams redesign controls for portability rather than assuming legacy extensions will carry forward.

Q: What should teams do when a protocol uses familiar words in unfamiliar ways?

A: They should freeze the vocabulary, write down the actual runtime roles, and require reviewers to use those roles in design discussions. That prevents control placement from drifting toward assumptions imported from other protocols. The goal is not to rename the standard, but to stop the organisation from governing the wrong component.

Q: What is the difference between an MCP host, client, and server?

A: The host is the AI application the user interacts with and where the session is managed. The client handles one connection to a specific server, including discovery and request formatting. The server exposes the actual tools, resources, and prompts. Security responsibility is split across all three, so each boundary needs separate controls.

Technical breakdown

Why MCP client and server feel backwards

MCP inherits its terminology from JSON-RPC and the Language Server Protocol, where the client sends a request and the server returns a response. That makes the naming protocol-correct even though it conflicts with the more common web mental model in which the server is the large production system. The result is not a protocol flaw so much as a semantic trap: the word server describes the tool exposer, not the heavyweight system. For identity work, that distinction matters because trust often follows the role label before anyone checks where execution and credentials actually sit.

Practical implication: Map roles from protocol behaviour, not from the words client and server.

What the MCP server actually does in the tool chain

In MCP, the server is the tool-facing component. It exposes actions such as database access, file reads, or GitHub operations, and it may be a tiny local process rather than a cloud service. The client, by contrast, contains the LLM and the agent loop that decides what to do next. That separation matters because the server may hold credentials even when it is not the decision-maker. From an NHI perspective, the server is often the credential-bearing execution point, while the client is the policy-and-orchestration point. See the NHI Authentication Guide.

Practical implication: Classify the tool server as a credential-bearing NHI and govern it accordingly.

Why naming confusion becomes a security boundary problem

When teams confuse the client and server roles, they can draw the wrong trust boundary around the MCP interaction. The real question is not which side sounds more important, but which side can initiate tool calls, where credentials are loaded, and which component brokers access to upstream systems. If a gateway or intermediary sits between the client and server, it becomes the control point for policy enforcement, tool selection, and credential delegation. That is why language clarity is not cosmetic in MCP. It affects how teams partition responsibility, scope credentials, and prevent a local tool process from being mistaken for an inert helper.

Practical implication: Define the boundary around tool invocation and credential delegation, not around the label.

NHI Mgmt Group analysis

Naming confusion is itself a control failure in MCP onboarding. When the same term means the opposite of what most engineers expect, access, credential, and trust decisions start from the wrong mental model. That does not create an exploit by itself, but it creates the conditions for mis-scoped controls and misplaced responsibility. Practitioners should treat terminology drift as a governance issue, not a documentation annoyance.

MCP clients and MCP servers should be governed by function, not by name. The client is the LLM-bearing decision layer, and the server is the tool-exposing execution layer. That split matters because governance errors usually happen when teams assume the server is the heavyweight production control plane and the client is a thin caller. In MCP, that assumption is inverted, so the identity model has to follow behaviour rather than familiar infrastructure language.

Tool exposure in MCP is an NHI problem even when the server is small and local. A tiny script can still hold credentials, call upstream systems, and become the practical control point for data access. The named concept here is role-label inversion: when the label suggests one trust model but the execution path uses another. Teams that miss this will misclassify risk and under-protect the component that actually touches credentials.

The gateway, not the vocabulary, is where policy should live. If an intermediary decides which upstream tool server runs a call and with what credentials, that intermediary becomes the enforcement layer that matters. The practical implication is to anchor governance to actual call routing, not to the protocol nouns that make onboarding easier.

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.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

The naming issue in MCP is a reminder that identity programmes fail fastest when teams inherit assumptions from older architecture patterns. A control design that assumes the server is always the privileged heavyweight will misplace ownership in environments where the tool exposer is small, local, and credential-bearing.

Role-label inversion: in MCP, the names client and server describe protocol direction, not operational weight. That distinction matters because governance depends on the component that can call tools and hold secrets, not the component that sounds like the obvious control plane.

For practitioners, the next step is to align reviews, inventories, and credential handling with the actual MCP call path rather than the expected web model. That avoids a class of governance errors where a small local process is treated as harmless simply because its name sounds secondary.

For practitioners

• Audit role assignments by execution behaviour Document which component initiates tool calls, which component exposes tools, and which component stores credentials so the team does not inherit the wrong mental model from the protocol name.
• Treat local tool servers as governed NHIs Apply inventory, ownership, and secret-handling controls to small MCP server processes even when they run on a developer laptop or in a short-lived shell session.
• Define the security boundary around delegation Mark the point where a client request becomes an authenticated tool invocation and require that boundary to carry policy, logging, and approval logic.
• Standardise onboarding language for MCP teams Publish an internal glossary that maps MCP client and MCP server to their actual runtime roles before integration work starts, so reviews use the same terms across engineering and security.

Key takeaways

• MCP reverses the usual web naming pattern, so teams cannot rely on the words client and server to infer trust, responsibility, or control placement.
• The practical security risk is governance error: credentials, tool access, and policy enforcement can be assigned to the wrong component if the runtime roles are not documented clearly.
• Identity teams should classify MCP components by behaviour, then place controls at the tool invocation boundary where access is actually decided and executed.

Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · OWASP Agentic Applications Top 10

Key terms

• Mcp Client: An MCP client is the application or agent that connects to a Model Context Protocol server to request tools, data, or prompts. It manages the session, sends structured requests, and receives responses in a standard format. In identity terms, it is the calling party that may need authentication, authorization, and audit controls.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Role-label inversion: Role-label inversion happens when a system name suggests one trust model but the runtime behaviour uses another. In MCP, that means the familiar client and server labels do not match common web intuition. The result is governance risk, because teams may assign controls based on naming rather than on actual execution and credential handling.

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.