MCP Host vs Client Distinction in Agent Architecture

MCP splits agent work across three roles: host, client, server. The host is the full application (Claude Desktop, Cursor, whatever enterprise agent framework you've built). The client is a piece that lives inside the host and talks to servers. Mixing these two up is a naming quirk with real consequences; the confusion is why security policy goes missing in production deployments right now.

Here's the setup. The host starts the interaction, owns the screen the user looks at, and answers for what the agent does. Inside it runs a client, which handles the actual back-and-forth with one or more MCP servers: opening the connection (stdio or HTTP/SSE), speaking JSON-RPC, pulling down the list of tools a server offers, sending calls out, catching responses as they stream back. The server sits outside both, owns whatever infrastructure it exposes, and never reaches out to the host on its own. The client always initiates.

People blur host and client constantly, in docs and in casual conversation, and even the spec itself isn't always careful about the line. That sloppiness matters more now than it used to. Early 2026 numbers put the ecosystem at over 10,000 active MCP servers, 177,000 registered tools, and 97 million monthly SDK downloads. At that scale, a fuzzy architectural boundary stops being a documentation nitpick and starts being an actual production risk.

What the host owns that the client does not

The host carries jobs the client simply cannot do by itself.

Start with policy. The host decides which servers get to connect at all, checks that the user has authorized what's about to happen, and applies whatever acceptable-use rules the organization has set, before any tool call goes out the door. None of that lives in the client. The client runs inside whatever rules the host has already put in place.

User-facing transparency sits at the host layer too. Consent prompts, approval screens, confirmations before an action fires: all of it belongs to the host, because the host owns the interface the person is actually looking at.

The client's job is narrower on purpose: send requests, manage the connection, fetch what tools are available. A client running with no host enforcing policy above it is just an open pipe.

Even something like whether a client keeps a connection alive across a long task, or treats every exchange as a fresh, independent one, is a call the host makes based on the use case. Stateful connections suit long-running work; stateless ones suit one-off requests. Either way, the host picks the pattern.

The short version: governance lives in the host, communication lives in the client. Those are two different jobs, and treating them as one job is where the trouble starts.

How authentication responsibility splits between host and client in practice

Who handles login depends heavily on where the server actually runs.

For local, stdio-based servers, the server runs as a subprocess of the host and just inherits whatever permissions the host application already has. The security boundary is the user's own machine; whatever access controls the host enforces are the only controls in play.

Remote servers work differently, and as of the November 2025 spec revision (version 2025-11-25), OAuth 2.1 is the mandated standard for them. That requirement traces back to a June 2025 update, and since then, servers act as OAuth resource servers: they check tokens, they don't hand them out. Token issuance and user consent happen upstream of the server entirely.

The client's part in this is to run the OAuth flow, hold the token, and present it to the server on request. Scope is set by the host and the identity provider, not the client.

The November 2025 spec added Cross App Access, where the client carries an identity assertion from an authorization server instead of making the user click through a consent screen every time. Admins keep full visibility and the ability to revoke, which matters in practice: if you need to cut off an AI agent's access to one internal tool, you do that once at the identity provider. You don't go hunting through every client instance that might have a cached credential.

Except a lot of deployments don't actually work this way. NSA guidance from May 2026 pointed out that OAuth 2.1, despite being mandatory in the spec, remains optional in practice, because plenty of real implementations skip it. That gap between what the spec says and what gets built is a failure sitting at the host level. It's not a client problem.

Authentication should route through the identity provider your organization already runs, Okta, Azure AD, Google Workspace, rather than around it. And agents need to be able to register with authorization servers automatically, because manually registering each one does not scale once you're dealing with dozens of MCP servers.

The security threats that exploit confused host-client boundaries

When the line between host and client gets blurry, the policy enforcement layer just isn't there anymore, and that's exactly the gap attackers go looking for.

Tool poisoning, cataloged as OWASP MCP03:2025, targets the client's trust in whatever metadata a server hands it describing its tools. Instructions buried in a tool description reach the model through the client before the host ever gets a chance to check them. A proof-of-concept from Invariant Labs in April 2025 showed a single poisoned tool description quietly pulling private repository contents and message histories out, with no action from the user required. Benchmarking across more than 45 real-world MCP servers found attack success rates above 60%, with the best-performing model hitting 72.8% in testing, according to Cloud Security Alliance research. A host doing its job would inspect tool definitions before ever showing them to the model. A host that hands that inspection off to the client has just created the hole.

Rug pull attacks work off a different gap: the lack of host-level version tracking. MCP has no built-in cryptographic content-addressing or version pinning for tool descriptions, so a server that got reviewed and approved once can quietly change its behavior later with no re-approval triggered anywhere. CVE-2025-54136, rated 8.8 on CVSS and disclosed in July 2025, confirmed exactly this: tool definitions approved in production AI environments don't stay valid once the server changes them behind the scenes. The Enhanced Tool Definition Interface proposal addresses this by binding tool definitions to signed JWTs, a host-level control by design, something a client cannot enforce on its own.

Prompt injection through tool output is another route in. The client processes whatever a server sends back, and if that response contains embedded instructions, they came from a compromised external resource, not from the user typing something in. A 2025 GitHub MCP vulnerability showed this working through crafted repository content, indirect injection that ended up leaking private data out of other users' sessions. Standard perimeter defenses don't catch this, because the attack lives in the meaning of the language, not in a signature or a suspicious IP.

Then there's outright session hijacking and remote code execution, which trace back to failures in the host's authentication layer. CVE-2025-49596 (CVSS 9.4) let attackers run arbitrary commands through MCP Inspector instances that had been deployed without authentication, meaning a host went live with no controls in front of it at all. CVE-2025-6514 found OS command injection in mcp-remote, a transport library used widely across the ecosystem, letting a malicious server achieve remote code execution on connection.

None of these stay isolated. A supply chain attack drops a malicious server in; tool poisoning through that server pulls credentials out; those credentials open the door to session compromise somewhere else. Each hop crosses the host-client boundary, and each hop is stoppable only if the host, not the client, is the one enforcing controls.

The stakes here are rising fast. Tools capable of actually changing something in the outside world grew from 27% of all MCP tools in November 2024 to 65% by February 2026. Most of what's in the ecosystem now can act on the world, not just observe it.

Why credential management belongs to the host, not the client

The client's job is moving credentials from point A to point B. Owning what those credentials can do, and for how long, is the host's job.

In real deployments, credentials often end up parked at the client layer anyway, and that's what happens when host and client get treated as one blob instead of two separate roles. Tokens hardcoded into client configuration files. Credentials inherited with no scope limit attached. Long-lived tokens with no rotation built in at all. Every one of these is a symptom of nobody having clearly owned the governance question in the first place.

There's a broader identity problem underneath this, sometimes called the non-human identity issue: AI agents act on behalf of users or services, but their identity and permission scope frequently aren't registered or tracked anywhere in the organization's identity system. Without the host registering that identity somewhere visible, the agent's credentials are invisible to the security team, full stop. And a breached MCP server running without authentication controls hands attackers access to every database, file system, and cloud service the assistant was ever connected to. One credential, the entire blast radius.

The fix is just-in-time credential issuance: scope a credential to one specific tool call, issue it right when the call happens, kill it right after. That only works if the host is mediating every single tool call, which is impossible if the client is off handling credentials on its own.

Tying agent identity into SSO and SCIM at the host layer connects agent access to the same lifecycle as everything else in the organization. When someone leaves the company, their agent's access should die with their account, but that only happens if the agent's identity was ever tied to the host's SSO integration in the first place, rather than sitting in a config file somewhere with a credential nobody's tracking.

NSA guidance from May 2026 called out implicit trust between agents and tools as a systemic risk on its own. The host is where that trust needs to become explicit, and revocable, instead of assumed.

What governance and audit require from each role

Audit isn't something you bolt on after the fact. If the architecture wasn't built to support it, you won't get it later.

The host needs to produce three things for an audit trail to mean anything: which user or service account authorized the session, what tools were allowed and under what scope at the moment the call happened, and a record of what the user actually consented to before the agent acted.

The client needs to produce its own record: every tool call it dispatched, the tool name, the input parameters, the server's response, plus transport-level detail like timing and connection errors. But that record is close to meaningless on its own. Without the host's identity and policy context sitting alongside it, you've got a log of activity with no way to say who authorized it or under what rule.

OpenTelemetry tracing is what ties host records and client records into one chain that can actually be followed after something goes wrong. Skip that, and you've got two separate logs that can't be joined once you need them.

Audit logs also need to be tamper-proof, written somewhere the agent itself can't touch. An agent that's able to edit its own audit trail has given you a story, not accountability.

NSA's May 2026 guidance flagged dynamic tool invocation and shared context as risks that older cyber defense approaches just don't cover. The audit setup has to reflect that by capturing what a tool call actually meant, semantically, not just its network footprint. Compliance frameworks are moving toward expecting AI agent actions to be traceable to a person, bounded in scope, and reviewable after the fact, none of which is possible if host and client responsibilities were never split clearly to begin with.

How the protocol's governance evolution shifts host-level obligations

MCP stopped being one company's spec in December 2025, when Anthropic handed it over to the Agentic AI Foundation under the Linux Foundation, moving it to a multi-stakeholder governance model. OpenAI, Google, Microsoft, and AWS all backed the move, which puts MCP on track to be vendor-neutral infrastructure rather than one vendor's product.

For anyone building a host, that means the spec keeps changing through a community process, and someone has to track what each change shifts onto the host's plate. The November 2025 revision added a formal Tasks abstraction for long-running operations with progress tracking attached, which means hosts now have to supervise asynchronous agent work, not just handle synchronous tool calls one at a time. The centralized MCP Registry, sitting at over 3,000 publicly listed servers as of early 2026, gives hosts a place to discover new servers; it also gives hosts a new obligation to vet what they find there before letting a client anywhere near it.

WebMCP, accepted by the W3C Web Machine Learning Community Group in September 2025, pushes MCP into browser-native execution, a host context with a different security boundary than anything running on a desktop or a server.

NSA's May 2026 assessment put it plainly: MCP's adoption has outrun the security work needed to back it up. Governance maturing at the protocol level doesn't close that gap by itself. Somebody still has to build the host correctly.