MCP Security Architecture: Trust Boundaries and Runtime Controls
MCP security architecture consists of three distinct trust boundaries: Host-to-Client, Client-to-Server, and Server-to-backend-system. Each boundary requires different controls. HTTP-based MCP servers use an OAuth 2.1 authorization model with resource-scoped tokens, while local stdio servers rely on host-level process trust.
What MCP Security Architecture Covers
Model Context Protocol defines a Host-Client-Server architecture that connects AI applications to external tools and data. A Host application maintains one or more Clients, each holding a 1:1 connection to a Server that exposes tools, resources, and prompts. Messages between clients and servers use JSON-RPC 2.0, and the protocol supports both local stdio transports and remote HTTP-based transports, including streaming variants.
Because a single MCP deployment often mixes local and remote servers, security architecture cannot rely on one uniform control layer. Authentication, authorization, and monitoring must be designed separately for each transport type and validated at each of the protocol's structural boundaries. This distinction matters for platform engineering teams evaluating how to expose internal tools to AI agents without creating a single point of unauthorized access.
The Three Trust Boundaries
Each boundary in an MCP deployment has a different threat model and requires controls appropriate to its transport and trust assumptions.
Host-to-Client
Internal application boundary between the AI host and its embedded MCP clients. Controlled through application-level access and process isolation.
Client-to-Server
Network or IPC boundary requiring authentication, authorization, and explicit consent before tool invocation or data transmission.
Server-to-Backend
The server's own credentialed access to internal APIs and data sources. Controlled through least-privilege service accounts and scoped credentials.
| Boundary | Transport | Primary Control | Key Risk |
|---|---|---|---|
| Host-to-Client | In-process / IPC | Application trust, process isolation | Privilege escalation within the host |
| Client-to-Server | HTTP or stdio | OAuth 2.1 tokens (HTTP); OS process trust (stdio) | Cross-server token reuse; unauthorized tool invocation |
| Server-to-Backend | Internal APIs | Scoped service credentials, least privilege | Confused-deputy: server acts on behalf of any caller |
Authentication and Authorization Differ by Transport
For HTTP-based transports, the MCP specification defines an authorization framework built on OAuth 2.1, with the MCP server acting as an OAuth resource server rather than an authorization server. Recent specification revisions incorporated OAuth Resource Indicators (RFC 8707) so that access tokens can be scoped to a specific MCP server instead of being valid across multiple servers.
This addresses a documented cross-server token misuse pattern, where a token issued for one server could otherwise be replayed against another. Official security guidance also flags the confused-deputy pattern, where an MCP server proxies requests to a third-party API using a shared token, effectively acting on behalf of any client that can reach it.
Local stdio servers fall outside this OAuth model entirely. They rely on host-level process trust, meaning the operating system's process isolation and permission model become the primary control rather than any token exchange. Enterprises running mixed deployments should assume no uniform authentication layer exists and architect controls separately for each transport type.
Do not assume that OAuth controls applied to HTTP-based servers also protect stdio servers. The two transports require separate security strategies. A policy gap at either boundary undermines the deployment as a whole.
Runtime Controls to Prevent Unauthorized Tool Invocation
MCP does not itself define a centralized policy enforcement point. Runtime authorization decisions, such as which tool a given caller may invoke, with which arguments, and under what conditions, must be implemented by the host or by an intermediary inserted between the client and server layers.
This gap matters because tool definitions, including name, description, and input schema, are supplied by the server and can change between client sessions. Static allowlisting of tool names alone does not account for this: a previously approved tool's schema or description can be altered without the client necessarily detecting the change.
Recommended runtime controls
- Validate and pin tool schemas at first approval, then require re-confirmation when a schema changes before allowing subsequent invocations.
- Obtain explicit user or operator consent before a tool call executes and before data is transmitted to a server.
- Insert a gateway or proxy layer between clients and servers to centralize policy enforcement across heterogeneous server implementations.
- Apply rate limiting at the gateway layer, independent of how any individual server is built.
- Emit structured audit logs at the client-server boundary for every tool invocation, including caller identity, tool name, schema version, and outcome.
Governance Requirements for MCP Deployments
Because MCP tool definitions are server-supplied and mutable, governance must be treated as a continuous runtime concern rather than a one-time configuration step. The following areas require ongoing attention in production deployments.
Agent identity and permissions management
Each agent or client interacting with MCP servers should carry a distinct identity, with permissions scoped to the tools and resources that agent legitimately requires. Shared credentials across agents prevent meaningful audit attribution and expand the blast radius of a compromised session.
Schema change detection
Tool schemas exposed by MCP servers can change without explicit versioning. Governance tooling should detect schema drift between sessions and surface changes to operators before re-approval, rather than silently accepting updated definitions.
Audit logging
A full audit trail of tool invocations, including the invoking identity, the tool and schema version used, input arguments (subject to data classification constraints), and the server response, is essential for incident investigation and compliance reporting. Logs should be written at the enforcement layer, not delegated to individual server implementations.
Evaluation Criteria and Tradeoffs
When architecting or evaluating an MCP deployment, platform teams should assess the following questions for each server in the deployment.
| Evaluation Area | What to Assess |
|---|---|
| Token scoping | Does the server enforce resource-scoped tokens (RFC 8707), or does it accept broadly-scoped tokens that could be reused against other servers? |
| Schema change handling | How are tool schema changes detected, surfaced to operators, and re-approved? Silent schema drift undermines prior consent decisions. |
| Transport risk profile | stdio servers depend on host process isolation and OS-level least privilege. HTTP servers depend on correct OAuth resource-server configuration. Neither is inherently safer; each requires controls matched to its actual trust model. |
| Enforcement layer placement | Is policy enforced at a central gateway between clients and servers, or distributed across individual server implementations? Central enforcement is more consistent and auditable. |
| Confused-deputy exposure | Does the server proxy requests to third-party APIs using a shared token? If so, any client that can reach the server can indirectly access those APIs using the server's credentials. |
Trussed AI provides runtime governance for AI agents, including MCP-aware policy enforcement, tool approval workflows, agent identity and permissions management, and audit logging. These capabilities are applied as an enforcement layer between clients and servers, complementing correct MCP configuration rather than replacing it.
Frequently Asked Questions
Does MCP provide a built-in authorization layer?
For HTTP-based transports, MCP defines an authorization framework based on OAuth 2.1 and RFC 8707 resource indicators. However, MCP does not provide a centralized policy enforcement point for runtime tool invocation decisions. Those controls must be implemented by the host application or an intermediary gateway.
Are stdio-based MCP servers safer than HTTP-based servers?
Neither transport is inherently safer. stdio servers depend on host process isolation and operating system-level least-privilege permissions. HTTP servers depend on correct OAuth resource-server configuration and token scoping. Each requires controls matched to its actual trust model. A mixed deployment requires both sets of controls applied independently.
What is the confused-deputy problem in MCP?
The confused-deputy problem occurs when an MCP server proxies requests to a third-party API using a shared credential. Any client that can reach that MCP server can indirectly invoke those APIs using the server's credentials, regardless of whether that client should have direct access. Mitigations include per-caller credential scoping and explicit authorization checks before the server forwards any request.
How should tool schema changes be handled at runtime?
Tool schemas should be validated and pinned at the time of first approval. If a schema changes between sessions, the enforcement layer or host should surface the change to an operator and require re-approval before the updated tool definition is used. Accepting schema changes silently invalidates prior consent decisions.
What does a gateway or proxy layer add to MCP security?
A gateway positioned between MCP clients and servers provides a single, consistent enforcement point for policy decisions, rate limiting, schema validation, and audit logging. It prevents policy fragmentation across heterogeneous server implementations and allows governance rules to be updated centrally without modifying individual servers or clients.
Architect MCP Security Around Trust Boundaries, Not Assumptions
Runtime governance for MCP deployments starts with visibility into tool invocations and enforceable policy at the client-server boundary.
Explore Runtime Governance