--- title: "MCP Security Basics for Product Teams" description: "What a connected MCP server can actually reach, the attack patterns the specification names, and the approval boundary a product team agrees before connecting." canonical_url: "https://builderscamp.com/guides/tools/mcp-security-for-product-teams" date_published: "2026-09-18" date_modified: "2026-09-18" author: "Andre Albuquerque, Inês Lourenço" publisher: "Builders Camp" guide_class: "tools" --- # MCP security for product teams, and the approval boundary to agree first **TL;DR:** The MCP specification names user consent, data privacy and tool safety as key principles and then states plainly that it cannot enforce them at the protocol level. That makes the approval boundary a team decision, made before a connection exists. Four questions per server, one named owner, and a re-review trigger cover most of what actually goes wrong. ## What can a connected server actually reach? It depends on where it runs, and the two answers are very different. A local server, connected over the stdio transport, is a program running on your machine with your client's privileges. The specification is direct about what that means: arbitrary code execution, no visibility into what commands are running, data exfiltration and data loss are all listed as risks of running a local server from an untrusted source. Its mitigation guidance asks clients that offer one-click setup to show the exact command without truncation before it runs, to flag dangerous patterns, and to sandbox servers with minimal default privileges. A remote server, connected over HTTP with OAuth, is bounded by your account rather than your machine. That sounds tighter and often is not. If your account is an administrator account, the connection inherits administrative reach without saying so. Both cases share a third surface that surprises people. Tool descriptions come from the server, reach the model, and shape what it does next. The specification treats them as untrusted unless the server itself is trusted, which is why the trust decision belongs on the server as a whole rather than on the individual tools you think you are enabling. ## What the specification makes your problem Three key principles sit at the front of the specification: users must explicitly consent to and understand all data access and operations, hosts must obtain explicit user consent before exposing user data to servers, and hosts must obtain explicit user consent before invoking any tool. Then comes the sentence that matters most for a product team. The specification states that MCP itself cannot enforce these principles at the protocol level, and asks implementors to build consent and authorisation flows into their applications instead. Read that as an allocation of responsibility, not a disclaimer. The protocol handles the connection shape and deliberately declines to make the judgement call. Somebody in your organisation makes it. If nobody is named, it gets made implicitly by whoever installs the fastest. ## The attack patterns worth knowing by name You do not need to implement the mitigations. You need to recognise the shapes, because they tell you which questions are worth asking a vendor. **Confused deputy.** A proxy server sitting between clients and a third-party API, using one static client identifier while letting clients register dynamically, can be manipulated into handing an authorisation code to an attacker. The consent screen gets skipped because a cookie from an earlier legitimate flow is still present. The specification requires proxy servers to run their own per-client consent before forwarding anything onward. **Token passthrough.** A server accepting a token that was not issued for it, and forwarding it downstream. The specification is unambiguous: servers must not accept tokens that were not explicitly issued for the server. Accepting them breaks rate limiting and request validation, and makes audit logs attribute actions to the wrong identity. **Over-broad scopes.** The specification treats scope minimisation as a security control in its own right, and names the consequences of ignoring it: a stolen token reaches unrelated tools, revoking it disrupts every workflow at once, and a single omnibus scope hides what the user actually intended in the audit trail. Wildcard and full-access scopes are listed as common mistakes. **Local server compromise.** A malicious startup command in a configuration, or a malicious payload inside the server itself, executed with your privileges. **Instructions hidden in data.** Not a protocol flaw, and the most likely one to hit a product team. Supabase names it as the primary risk of connecting a model to a database: content already sitting in your data can carry instructions that steer the model. Anywhere outsiders can write text you later query is exposed, which is most support and feedback surfaces. [MCP for product managers](https://builderscamp.com/guides/tools/mcp-for-product-managers) covers why a server is an active participant in the conversation rather than a passive data source. ## What the client vendors tell their own users Anthropic's guidance for custom connectors is short and worth quoting to your team verbatim rather than paraphrasing. It asks users to connect only to servers built and hosted by organisations they trust, to review the permissions a server requests during authorisation, to be aware that malicious servers may include hidden instructions, and to notice that server developers may update tool behaviour unexpectedly. That last one is the item most review processes miss. A connection approved in March is not the same connection in June, and nothing announces the change. ## The approval boundary to agree before anything is connected Four questions per server, answered in writing, before the connection exists. None of this needs a security function. - **What single job is this for?** One sentence. A server with no named job cannot be evaluated, because there is nothing to weigh the access against. - **Read or write, and if write, which specific actions?** Take the read-only path where the vendor publishes one. Treat write as an exception that names its own action type. - **Whose account, and what does that account reach?** The permission level of the authenticating identity is the real scope of the connection, whatever the server documentation says. - **Who re-reviews it, and what triggers that?** A named person, a quarterly pass, and an immediate review whenever a connection asks for a permission it did not need before. The output is one short page. Teams that keep it find the list of connected servers stops growing on its own, which is the actual goal. ## Why the one-time review is the weak point Because the review is a snapshot of something that moves. Tool lists are fetched from the server and can change. Clients cache discovery results for a period, so what you saw at approval time may not be what runs next week. Credentials expire and reconnect quietly. And the specification's own advice on scopes assumes a client that widens permissions incrementally, which means the access surface at month three is rarely the one you approved at month one. The cheap countermeasure is to make the connection list boring and visible: one page, one owner, four answers per row, revisited on a fixed date. Compare that to the alternative most teams run by default, which is a configuration file nobody has opened since the person who wrote it changed roles. This is the same discipline Builders Camp's AI Product Management bootcamp applies to AI features generally: how much rope the model gets is a product decision covering what it sees, what it may use, when a human must approve and what happens when it fails, and its own material argues that most failures trace to missing guardrails rather than weak models. It runs 2 weeks with 4 live sessions and 7 microlessons. AI Agents covers the agent design layer over 2 weeks, and Building with Claude Code names MCP and tool integrations directly in its syllabus for the implementation side. [See the AI Product Management bootcamp](https://builderscamp.com/bootcamps/ai-product-management?utm_source=guide&utm_medium=organic&utm_campaign=mcp-security-for-product-teams) One thing to do this week that costs half an hour: list every MCP server currently connected across your team's tools, and mark which ones can write. Most teams cannot produce that list from memory, and the gap between what people believe is connected and what is connected is usually the whole finding. For the tool-call approval model underneath, [Claude Code permissions and safety](https://builderscamp.com/guides/tools/claude-code-permissions-and-safety) is the practical companion, and [how to design an AI agent](https://builderscamp.com/guides/tools/how-to-design-an-ai-agent) covers the design layer above a single connection. ## Frequently asked questions ### Does MCP enforce any security by itself? No, and the specification says so. It lists user consent and control, data privacy and tool safety as key principles, then states that MCP cannot enforce those principles at the protocol level and asks implementors to build consent and authorisation flows instead. The protocol standardises the connection and hands the judgement to whoever connects it. ### What can a local MCP server do to my machine? Whatever your client can do. The specification treats local servers as binaries running with the client's privileges and names arbitrary code execution, data exfiltration and data loss as the risks. Its guidance asks clients offering one-click setup to display the exact command before running it, and recommends sandboxing servers with minimal default privileges. ### What is the confused deputy problem in MCP terms? A proxy server that uses one static client identifier with a third-party service while letting clients register dynamically can be tricked into issuing an authorisation code to an attacker, because the consent screen is skipped by a cookie set during a legitimate earlier flow. The specification requires proxy servers to implement their own per-client consent before forwarding to the third party. ### What is token passthrough, and why is it banned? It is a server accepting a token that was issued for something else and forwarding it downstream. The specification states that MCP servers must not accept tokens that were not explicitly issued for them, because doing so breaks audience validation, defeats rate limiting and request validation, and makes audit trails show the wrong identity. ### Are tool descriptions trustworthy? The specification says descriptions of tool behaviour, including annotations, should be treated as untrusted unless they come from a trusted server. A connected server is not a passive data source. It supplies text that reaches the model and influences what it does next, which is why the trust decision sits on the server, not on the individual tool. ### Does read-only make a connection safe? It makes it non-destructive. Supabase's documentation names prompt injection through content already sitting in your database as the primary risk, which read-only does not remove. Read-only limits what a successful injection can do rather than preventing one, which is still the single highest-value control available. ### How often should a connection be reviewed? Whenever the server changes, which you will not be told about. Anthropic's own connector guidance warns that server developers may update tool behaviour unexpectedly. A practical cadence is a quarterly pass over the approved list plus an immediate review whenever a connection starts asking for a permission it did not previously need. ## Sources - [Model Context Protocol: Security best practices](https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices) - [Model Context Protocol specification, revision 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/index) - [Anthropic Support: Getting started with custom connectors using remote MCP](https://support.claude.com/en/articles/11175166-getting-started-with-custom-connectors-using-remote-mcp) - [Supabase: Model context protocol (MCP)](https://supabase.com/docs/guides/getting-started/mcp) ## How this guide was made Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.