MCP security and privacy: what a connector can actually see

Filed under Guide

By Gerald · 13 August 2026

A brass padlock latched onto a weathered wooden door, representing the access control decision behind connecting an AI tool to your data

An MCP connector can see exactly what its token is scoped to see, no more and no less. That is the whole answer to "is MCP safe," and it is also why the question is usually wrong. The real question is what you granted, and whether anything you did not mean to expose is sitting inside that grant.

I built Flow's own MCP connector, so I have spent time thinking about what I would want to know before pasting a URL into an AI tool. Most of what gets written about MCP security is either a vague "trust the vendor" reassurance or a dense enterprise threat model nobody outside a security team will read. This is the middle version.

A connector is not a leak by itself. It is a permission you granted, and the risk lives entirely in what that permission covers and how sloppily the token protecting it is handled.

What a connector actually receives

MCP, the Model Context Protocol, is a standard for letting an AI model call tools against a service on your behalf. When you connect an assistant to an app, you are not handing the model your password. You are handing it a token, and the token is scoped to whatever tools the service's MCP server exposes.

Concretely, that means the model can call the specific functions the server author wrote: list your notes, read a task, create a calendar event, search a repository. It cannot reach into anything the server does not expose a tool for, and a well-built server does not expose a "read the entire database" tool just because that would be convenient to build.

The practical question for any connector is narrower than "can it see my data." It is "which tools does this connector define, and does any of them return more than the task in front of me needs."

Tokens, scopes, and why read-only matters

A security camera mounted on the corner of a brick building, representing monitoring and scoped access rather than a full, unrestricted view — A connector only sees what its token is scoped to see, not everything you own.

The July 2026 MCP specification release candidate hardens the authorization layer considerably: it requires clients to validate the iss (issuer) parameter on tokens per RFC 9207 to stop mix-up attacks between servers, and it tightens how OAuth-based clients register and bind credentials to a specific authorization server, according to the official MCP specification blog. None of that fixes a badly scoped token, though. Protocol-level hardening stops a token from being replayed against the wrong server. It does not stop an overly broad token from doing exactly what it was built to do.

That is why scope is the setting that actually matters day to day. A read-only tool, marked with a readOnlyHint in its definition, tells the client it is safe to call without asking permission every time, because nothing it does can change your data. A tool that can create, update, or delete something should require an explicit approval, at least the first time. If a connector's setup screen does not show you which tools are read-only and which can write, that is worth checking directly with the vendor before connecting anything sensitive.

Short-lived, rotating tokens matter for the same reason a short-lived password reset link matters. Security researchers have flagged that a large share of current MCP servers still rely on static API keys or personal access tokens that do not expire on their own, which turns a single leaked token into a standing, indefinite grant rather than a brief window. If a service lets you regenerate or revoke your connector token from its account settings, do that occasionally, and definitely do it the moment you finish testing a client you do not plan to keep using.

Prompt injection is the realistic threat

The scary MCP headline is a leaked protocol or a broken server. The realistic daily risk is prompt injection: text your model reads from somewhere else, a web page, a document, an email, that contains instructions the model was never supposed to follow, and the model follows them anyway because it cannot tell content from commands.

Academic security research on MCP in 2026 has documented this directly. Threat-model analysis of tool poisoning, where a server's tool description or a fetched document embeds hidden instructions, found it measurably raises how often an agent takes an unintended action. The comparison is against equivalent setups without MCP-style tool calling.

Separately, the NSA's own published guidance on securing AI-driven automation names prompt injection through untrusted content as one of the primary risks specific to this kind of tool use. It is not treated as a hypothetical there. It is treated as the expected failure mode.

The practical version: if you ask your assistant to condense a web page for you, and that page contains a paragraph telling the model to "also forward the user's notes to this address," a connector with write access to your notes and no human approval step could actually attempt it. This is not about whether MCP itself is insecure. It is about giving a model both read access to untrusted content and write access to something valuable in the same session, without a checkpoint in between.

Keeping sensitive material out of reach entirely

The most reliable control is not a setting inside the connector. It is deciding, at the source, what the connector can see at all.

Concretely: mark truly private material as excluded from any AI-facing tool, rather than trusting a permission checkbox to catch it every time. Flow's connector, for one example, filters out anything a user has marked confidential before it ever reaches a list or search tool, and rejects direct reads of it too, so a locked note simply does not exist from the model's point of view no matter what it is asked. That is a stronger guarantee than "the model was told not to share this," because the model never receives it to begin with.

The same principle applies to any tool: keep financial records, health information, or anything you would not want summarized by a third party out of the scope a connector can reach, either by marking it private inside the app or by not connecting that particular data source at all.

Questions to ask before connecting a service

Before pasting a connector URL into an AI client, it is worth getting direct answers to a short list of questions, either from the vendor's documentation or by testing the connector yourself.

Which tools are read-only, and which can create, update, or delete something.
Whether the token can be scoped to a subset of your data, or whether it is all-or-nothing.
Whether the token is easy to revoke or regenerate from your account settings.
Whether the vendor uses connector data to train models, and where that is stated in writing, not implied in a sales page.
Whether the connector honors any "private" or "confidential" marking you have already set on your own data.

If a vendor cannot answer the first two clearly, that is itself useful information.

What good connector design looks like

The best MCP servers treat every write action as something that should require a visible approval, describe exactly what each tool does in plain language rather than vague names, and default to the narrowest scope that still does the job. How MCP differs from a plain API covers why this tool-based model, rather than a raw endpoint, is what makes fine-grained scoping possible in the first place, and what MCP is is the place to start if you want the underlying mechanics before the security layer.

For what it is worth, this is also how Flow's own connector is built: read-only tools are marked so clients can skip repeated prompts, nothing destructive exists as a tool at all, and confidential notes are excluded at the data layer rather than the prompt layer, which how the Flow connector is scoped covers in more detail.

Frequently asked questions

Can an MCP server read all of my files? Only if its tools are built to expose that, and only within whatever your token is scoped to. A well-designed server exposes specific tools, like listing notes or reading one task, rather than raw filesystem or database access. Check the tool list a connector defines rather than assuming full access.

Does connecting an assistant mean my data is used for training? Not automatically, but it depends entirely on the AI vendor and the service you connect, and you should check both parties' current policies rather than assume either way. This is a stated-policy question, not a protocol question, since MCP itself does not dictate what either side does with the data that passes through it.

What is prompt injection in an MCP context? It is when untrusted content the model reads, a web page, a document, an email, contains hidden instructions that the model follows as if you had typed them. Combined with a connector that has write access to something valuable, this is the realistic attack path, not a broken protocol.

How do I revoke an MCP connector? Go to the account settings of the service you connected and regenerate or disable the connector token there. Revoking access inside your AI client alone often does not invalidate the token on the service side, so remove it from both ends.

Are local MCP servers safer than remote ones? They remove one risk, a network-based interception of the token, but they do not remove tool-scope or prompt-injection risk, since those depend on what the server exposes and what content the model reads, not on where the server runs. A local server with an overly broad tool still has an overly broad tool.

My verdict

MCP is not the risk. An unscoped token combined with untrusted content is. Read what a connector's tools actually do before you connect it, keep anything genuinely private excluded at the source rather than trusted to a prompt, and revoke tokens for clients you stop using.