Connecting an AI assistant to your documents is one decision. Letting it change a customer record or send an email is another. A useful connector should make that distinction visible—not bury it behind a successful login.

The Model Context Protocol, or MCP, gives applications a common way to expose tools and context to AI systems. Its architecture separates the application hosting the assistant, the clients connecting it to services, and the servers offering capabilities.[1] But a common interface is not a common permission policy. The practical question is not simply whether a product supports MCP. It is which component can refuse an operation even when the model asks for it.

This guide examines the published MCP specification revision dated July 28, 2026, and documentation checked October 30, 2026. It explains documented mechanisms, not independently tested behavior in any particular assistant. The worked example is a proposed design, not a deployed system or security audit.

What MCP actually adds

Imagine an assistant that needs a document search service and a customer database. In MCP’s architecture, the host application manages client instances, each communicating with a particular server. Servers expose tools, resources and prompts; the host coordinates the model and handles policy and consent decisions.[1]

For tools, the protocol describes discovery through tools/list and invocation through tools/call. Tool definitions carry names, descriptions and input schemas; an output schema can also describe expected results.[2] That makes the interface more structured than asking a model to improvise an arbitrary command. It does not tell you whether the credentials behind that interface can access every customer in a database.

Our evaluation rule is to separate three questions: what the assistant can discover, what its credentials can reach, and what the application will actually permit. Ask for an answer to each. A provider’s connector demonstration may show interoperability without establishing that the permission boundaries fit your organization.

A tool description is not enforcement

The tools specification recommends keeping a human able to deny tool invocations, with visible tool use and confirmation prompts. It also leaves the particular interaction interface to implementations.[2] Consequently, the words “supports MCP” do not establish that every operation in a given product receives the same approval treatment. Ask the provider to demonstrate its actual behavior.

The specification explicitly treats tool annotations as untrusted unless they come from trusted servers.[2] Our practical interpretation: a label such as “read only” is something to verify against the execution path, not sufficient evidence on its own. If a system claims a tool cannot modify records, ask what rejects a modification: a restricted account, a server-side permission check, an operating-system boundary, or merely an instruction to the model.

Microsoft’s multitenant-agent architecture guidance makes the distinction explicit: prompts and model behavior are not tenant-isolation boundaries. It recommends deterministic authorization and tool-level controls, with tenant context derived from trusted state rather than model-generated content.[5] Here, a tenant means a customer organization sharing the application. Even in a single-company deployment, the same question is useful: can changing a tool argument expose a different team’s material?

Login approval and action approval solve different problems

MCP’s HTTP authorization specification describes access to restricted servers using an OAuth-based flow. It identifies the client, protected server and authorization server as separate roles. Authorization support is optional in MCP implementations; the HTTP flow is not the prescribed approach for local standard-input/output connections.[3] Do not assume that installing a local connector reproduces the permissions shown on a hosted service’s sign-in page.

The HTTP specification discusses limiting requested scopes to intended operations and requesting additional permissions when necessary.[3] A scope is part of the access grant. It is not the same thing as approving the exact text of a particular outgoing message. Our recommendation is to treat the two decisions separately: connecting an account establishes an available access path; approving a message authorizes a specific use of it.

The security requirements also say servers must verify that access tokens were issued for them, and prohibit token passthrough.[4] In plain language, a connector should not accept an unrelated service’s credential as though it were issued for the connector. Ask how downstream access is authorized rather than assuming one successful login safely covers every hop. These access tokens are credentials in the described authorization flow, not a reason to buy a cryptocurrency.[3][4]

Worked example: research a renewal, but do not send it

Consider a hypothetical assistant asked to locate a customer’s renewal terms and prepare a reminder. We propose a deliberately narrow first version: it can retrieve authorized documents and create a private draft, but has no outbound email tool. The following is our design checklist, not a claim that MCP supplies these controls automatically.

First, the application establishes the user’s identity and permitted customer account before retrieval. The model may suggest a search phrase, but it should not be able to choose an unrestricted customer identity. The document service checks access before returning text. Test this with a deliberately mismatched account and require rejection, not a polite refusal generated after the document has already been returned.

Second, the retrieved contract is evidence, not an instruction channel. Suppose it contains a sentence telling the assistant to forward the whole document to a new address. The assistant’s task remains finding renewal terms. In our proposed first version, the absence of an outbound capability is a stronger restriction than hoping the model disregards that sentence. It does not, by itself, settle where retrieved text is processed or retained.

Third, the draft should identify the source document, the relevant version and any ambiguity about the renewal date. If two amendments conflict, stopping for review is an acceptable outcome. Do not turn an unresolved source conflict into a confident reminder simply because the drafting tool succeeded.

If sending is added later, make it a separate permission boundary. Present the exact recipient, subject, body and attachments for approval. Recheck the user’s authority at execution time, and invalidate the approval if those details change. After an approved send, inspect the service’s actual result and record whether it succeeded, failed or remains uncertain. A completed model response is not our proposed success criterion.

Microsoft similarly recommends evaluating authorization on each tool invocation and says human approvals do not replace deterministic tenant checks.[5] The example adds our own stricter product choices—especially initially omitting sending—rather than claiming that a confirmation dialog alone makes the workflow safe.

Local does not automatically mean contained

A remote connector and a local connector move the trust boundary to different places. MCP’s security guidance warns that local servers execute on the user’s machine and may inherit the client’s privileges. It recommends informed installation consent, minimal privileges, sandboxing and restricted filesystem and network access.[8] Local execution is therefore not a substitute for checking which files, credentials and network destinations the process can reach.

For a local document assistant, our suggested acceptance test uses a disposable directory and non-sensitive files. Give it an allowed folder and a separate forbidden folder. Verify that an attempted out-of-scope read is rejected by the execution boundary. Then test whether the process can reach an unapproved network destination. Run these tests in an authorized test environment, not against someone else’s systems.

There is also a concrete version trap. In the July 28, 2026 specification, MCP’s filesystem “roots” feature is deprecated. Its documentation describes roots as informational guidance, not enforced access control, and recommends that new implementations use alternatives such as tool parameters, resource URIs or server configuration.[7] A folder picker is not proof of a sandbox. Passing a directory through another field is not proof either; the enforcement mechanism still needs examination.

For a buying or build decision, use the same questions across three designs. This is an evaluation framework, not a performance ranking.

A direct API integration: ask which service permissions it uses, where requests are validated, and whether its narrower interface covers the job. If all you need is one stable operation, consider whether a custom integration would be easier to inspect than a general tool catalog.

A remote MCP server: ask who operates it, what data it receives, which tools are exposed, how access is granted, and where user or customer restrictions are checked. Ask for evidence that the deployed server follows the documented authorization behavior—not just a link to the specification.

A local MCP server: ask what executable starts, which privileges it inherits, what it can read, and whether it can contact the network. Require the same data-handling review you would apply to another installed program. A friendly connector name should not end that review.

Across all three, request a failure demonstration: an unauthorized account, a revoked permission, an altered approved action, and a misleading instruction inside retrieved material. Record the component that refused each operation. Also check logs and retained data; restricting modifications does not answer every confidentiality question.

What is documented—and what remains unproven

The sources establish published protocol behavior and implementation guidance. They do not establish that every MCP client or server implements those controls, that older deployments use the reviewed revision, or that a particular connector resists every attack. This article reports no penetration test, measured reliability result or independent certification.

Our conclusion is narrower than “MCP is safe” or “MCP is unsafe.” MCP is an interface choice. Permission boundaries are an implementation and operating decision. The useful purchase question is: show me what this assistant cannot do, identify what enforces that limit, and demonstrate that a model request cannot override it.

Sources

[1] https://modelcontextprotocol.io/specification/2026-07-28/architecture — MCP Architecture — revision 2026-07-28; checked 2026-10-30 [2] https://modelcontextprotocol.io/specification/2026-07-28/server/tools — MCP Tools — revision 2026-07-28; checked 2026-10-30 [3] https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization — MCP Authorization — revision 2026-07-28; checked 2026-10-30 [4] https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations — MCP Authorization Security Considerations — revision 2026-07-28; checked 2026-10-30 [5] https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/considerations/agentic-systems — Microsoft: Multitenant agentic systems — page date 2026-09-25; checked 2026-10-30 [7] https://modelcontextprotocol.io/specification/2026-07-28/client/roots — MCP Roots — revision 2026-07-28; checked 2026-10-30 [8] https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices — MCP Security Best Practices — versioned documentation; checked 2026-10-30