MCP client-server naming: what it means for IAM and security

TL;DR: MCP reverses the usual web naming convention: the MCP client holds the LLM and agent loop, while the MCP server exposes tools, according to Archestra. That inversion is technically consistent with JSON-RPC but creates avoidable confusion for engineers and complicates how teams reason about the security boundary.

Editorial analysis by NHI Mgmt Group, based on content published by Archestra: “'MCP server' and 'MCP client' are confusing names”.

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.

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

A: Clean core matters because it changes where controls can live.

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.

Practitioner guidance

• 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.

Bottom line: MCP reverses the usual web naming pattern, so teams cannot rely on the words client and server to infer trust, responsibility, or control placement.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →