MCP security is about the identities behind an AI tool call

The protocol’s security guidance explains why a convenient connector must not pass authority blindly between services.

An AI tool call can cross several trust boundaries in a fraction of a second: the assistant client, a connector, an identity provider and the application holding the data. Model Context Protocol makes tool integration more consistent, but consistency is not authorization. The [MCP security guidance](https://modelcontextprotocol.io/docs/2025-11-25/tutorials/security/security_best_practices) describes risks that arise when services assume another component has already checked the caller. This is an engineering review of the retained November 2025 specification, checked in October 2026.

The central question is who is asking for which operation. A valid token for one service may not be valid for another. A proxy that accepts a credential and forwards it without verifying the intended audience can obscure both authority and accountability. A model’s decision to call a tool does not make that call trustworthy. The tool service must independently validate identity, scope and the operation’s target.

Consider an original internal-document assistant with two permitted tools: search a project archive and open a source document. The archive belongs to two fictional departments. A test user can read one department’s material. Before adding any model, invoke each tool directly under that user and confirm that cross-department requests fail safely. This distinguishes an authorization defect from a model that merely chose the wrong argument.

Next, introduce a harmless test document containing instructions to fetch a restricted report. The assistant should treat those words as document content. Even if it attempts the forbidden lookup, the service must deny access. Success is a system boundary that holds under a mistaken or manipulated model decision. A prompt alone is an unreliable place to keep the only access restriction.

The [authorization specification](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) provides protocol requirements, while [IETF OAuth guidance](https://datatracker.ietf.org/doc/html/rfc9700) supplies broader identity-security context. Use a maintained implementation that supports the required checks and preserve its license. Avoid improvising a simplified token scheme because a demo works. A demo usually omits revocation, multiple clients, malicious redirects and sessions created under different identities.

Review connector registration and consent as distinct events. A person may consent to a named client reading a narrow collection without consenting to another client reusing that decision. The proxy needs a clear record of what was approved. The user-facing flow should display understandable scope and the actual requesting client. An unfamiliar tool name or a broad permission request should not be hidden behind a friendly assistant label.

For server-operated clients, network boundaries deserve their own tests. Metadata and redirect locations can cause a client to contact unintended destinations if they are trusted blindly. Use an approved test environment to confirm that outbound requests respect the application’s network policy. Do not probe real internal services merely to demonstrate a theoretical issue. Restrict redirects and resolve destinations through maintained, reviewed controls.

Log enough to investigate a disputed action: safe operation identifier, caller, client, target record and outcome. Exclude tokens, private form content and document bodies from routine logs. When a request fails, the person should see what action was not completed and what recovery is appropriate. Raw provider messages, token-validation exceptions and internal hostnames belong in restricted diagnostics, never in the chat response.

Performance tradeoffs are real. Extra authorization checks and current-permission lookups can add latency. Cache decisions only with a defined lifetime and revocation policy; avoid turning a speed optimization into permanent authority. Cost estimates should include identity operations and monitoring, especially for a high-volume assistant that repeatedly opens documents. Measure end-to-end permitted tasks rather than tool-call speed alone.

The result of a useful review is a map of identities and decisions, plus evidence that denial, revocation and recovery work in the configured system. Installing an MCP server or reading a specification does not establish compliance. The benefit of the protocol is reusable integration; the responsibility retained by the application is to ensure that reusable integration never makes authority transferable by accident.

For the two-tool exercise, give each request a safe correlation identifier and compare server-side denial with the assistant’s explanation. The same denied lookup should never appear as a successful empty search. That difference is essential when users decide whether to retry or seek access.