MCP Security

TL;DR: Review an MCP integration at three boundaries: the material the model reads, the process or service that executes a request, and the authority used to access data. A familiar server name, a valid token or a read-only annotation does not establish that a particular action is allowed.

After this lesson, you should be able to draw the two credential hops in a remote integration, distinguish local process confinement from protocol permissions, and specify a refusal test for each boundary. Start with agentic AI security if the difference between a model proposal and an authorized action is new.

Start with the actual integration

The host is the AI application. Its MCP clients communicate with servers, which offer tools, resources or prompt templates. The host decides which of those definitions and results reach the model; connecting does not necessarily put every tool into every context. If a description does reach the model, treat its author as a contributor of input, not as someone entitled to change the user's task. The MCP tools specification describes these definitions and warns that untrusted annotations need independent scrutiny.

A local server launched through stdio is a subprocess. Standard input and output carry messages; they do not confine the program. Its effective operating-system identity, mounts, environment and network policy determine what else it can reach. A remote server introduces a different question: what data and credentials are you willing to disclose to its operator?

Write down the caller, server owner, transport, exposed operations, token recipients and data destinations. Include startup and discovery, not just successful tool calls.

Worked review: a support assistant

Consider a hypothetical assistant that summarizes a customer's open ticket. It uses a vendor-hosted ticket server and a local server that reads product documentation. It needs neither ticket updates nor message sending.

Limit the remote operation. Permit a ticket read only when the authenticated support user is assigned to the relevant customer. Obtain the customer identity from verified server-side context and check the requested ticket against it. A model-supplied customer ID is a request parameter, not evidence of membership. If the vendor uses a broad service account upstream, these checks become especially important: the account's reach exceeds the user's permission.

Separate the credential hops. The host presents a token intended for the MCP server. That server calls the ticket API using a separately authorized credential intended for the ticket API, preserving the user's constraints. The second credential might come from a delegated user grant; an application credential is appropriate only where the product explicitly permits that service identity to act. Merely replacing the user's token with a powerful service token would make the design worse.

Confine the local reader. Mount only the documentation it needs, preferably read-only. Do not give it the developer's home directory, credential files, SSH agent socket or container-control socket. If reading local documents needs no network, deny network access. A declared read tool may still be implemented by a process that can write or make requests.

Remove an unnecessary data path. Ticket contents should not become arguments to the documentation server. Keep the two integrations separate where the task permits it. If the host needs information from both, define what may cross, minimize it and keep returned text untrusted. Different server names do not create this separation.

Set release evidence. In a fixture containing invented tickets and credentials, verify that a wrong-customer read is denied, an unapproved metadata revision is not loaded, and the local reader cannot reach an unrelated fixture directory. Test only systems you own or are explicitly authorized to assess. A refusal in one fixture supports that check; it does not certify every operation.

HTTP authorization: what to verify

Protocol snapshot: revision 2026-07-28, checked November 2026. MCP authorization is optional overall. Its authorization specification defines the HTTP flow when authorization is supported; stdio implementations should obtain credentials through their environment instead of applying that flow.

For a protected HTTP server, check protected-resource discovery, the selected issuer, PKCE support, resource indicators and token validation. The server must reject tokens not issued for it. Current registration guidance prefers client ID metadata documents and retains deprecated dynamic registration for compatibility. These are protocol requirements to check against the deployed revision, not evidence that a vendor implements them correctly.

Resource indicators in RFC 8707 identify the intended protected resource. Audience restriction limits where a token is accepted; scopes and resource-level checks limit what it can do there. Neither establishes that a requested action matches the user's current task.

The MCP security guidance prohibits accepting an upstream token as though it were issued for the MCP server and forwarding it onward. A supported token-exchange flow is a separate authorization decision. RFC 8693 does not make exchange revoke the original credential; explicit invalidation and resource-server enforcement are separate work.

Do not use a workflow ID as a substitute for identity. The current revision removes protocol-level sessions, while older deployments may still use them. Application state can exist in either case: a returned job or cart handle needs a caller-ownership check on every operation. See the versioning rules before applying a current transport assumption to an older client.

Discovery and startup happen before the tool call

A metadata fetch is already network access. An installer can already start a process. An approval shown after either event cannot prevent an effect that has happened.

For discovery, enforce destination policy where the connection is made. Validate redirect destinations and the addresses actually used, not just the initial hostname. Handle IPv4 and IPv6 with established parsers, bound response size and time, and keep credentials away from unapproved destinations. Public-service clients generally have no reason to contact internal or link-local services. An intentional internal integration needs an explicit destination policy, not a blanket exception. The OWASP SSRF prevention guide explains why application validation and network restrictions belong together.

A local HTTP listener also needs protection from other processes and browser-originated requests. Loopback binding reduces exposure but does not authenticate a caller. Check the Streamable HTTP security requirements, including Origin validation. A missing Origin header from a non-browser client is not an identity credential.

One historical example is useful here: JFrog's CVE-2025-6514 disclosure describes command injection through an authorization endpoint handled by vulnerable mcp-remote clients. The lesson is to validate the destination and use safe URL-opening APIs without shell interpretation. It is not a blanket prohibition on opening an authorization page in a browser. Check maintained release advisories before selecting a version.

Approval of metadata has limits

Review the full model-visible definition and bind approval to the server identity and the reviewed content. Check newly discovered or changed definitions before exposing them, including updates during an existing connection. Waiting until reconnect leaves a gap. Tool annotations are hints, not proof of actual behavior.

A matching definition hash establishes only that the checked bytes match. It does not attest to remote code, mutable dependencies, runtime data or the safety of the original definition. Keep operation-level policy in the service that holds the resource. The tool poisoning lesson develops this distinction with a changed-response exercise.

For investigations, retain server identity, approved definition revision, request and workflow IDs, policy decisions and outcomes. Store sensitive evidence separately with access and retention controls. Routine logs should not contain bearer tokens or complete customer conversations.

Check your review

Try the MCP integration interview scenario. Your answer should identify a resource owner, an enforcing component and a falsifiable check, not just name OAuth or a sandbox.