MCP security
An MCP server's security comes down to four questions: who may reach it, who the caller is, what the caller's tools can touch, and what a malicious tool description or result can talk the model into. The specification requires origin validation and authentication for anything non-public; the rest is the server author's design.
Validate Origin, or a web page drives your server#
A local MCP server listening on 127.0.0.1 is reachable by any page the user has open, because the browser will happily send a request to localhost from any origin. Combined with DNS rebinding — a hostname that resolves to an attacker's address and then to yours — it means an ordinary website can call a tool server that was only ever meant to serve the desktop application that launched it.
The defence is small and mandatory: when an Origin header is present, validate it and answer 403 if it is not one you accept. An absent Origin is normal and allowed — a desktop MCP client is not a browser and sends none. What must never happen is accepting any origin that turns up.
Connect does exactly this. The allowed set is the public site, plus a configured public origin, plus explicitly listed extras; localhost is accepted only when the process is not running in production mode. A present, unrecognised origin gets 403 before anything is parsed.
Authentication, scope and blast radius#
Public and private tools are different problems and should not share a surface by accident. A tool that reads a published file needs no credential, because requiring one protects nothing that a browser could not already fetch. A tool that reads a workspace needs a credential, and that credential must decide which workspace — not the request body.
- Bind scope to the credential. If the caller can name the workspace in an argument, the tool is one typo away from a cross-tenant read. The key resolves the workspace; the arguments never do.
- Call the domain service, not the database. A tool that goes straight to SQL bypasses autonomy, approval, suppression, metering and audit — every rule the product enforces lives above the query.
- Keep the tool list small and specific. Ten narrow tools can be read and reasoned about. One general tool that takes a path or a statement cannot.
- Log what a tool did, not just that it was called. A refusal is a decision worth recording; a write with no trail is a write nobody can explain later.
The injection surface people forget#
Tool descriptions, resource contents and tool results all arrive in the model's context, and a model does not natively distinguish a description written by a server author from an instruction written by the user. A hostile server can therefore attack a client through text alone, and a benign server can be turned into a weapon if it returns attacker-supplied content verbatim.
Two habits address most of it. Read a server's tool list before enabling it, the way you would read a browser extension's permissions. And treat content that came from outside — a message, a web page, a document — as data being reported, never as instructions to follow, wherever it appears in a chain. The same reasoning applies to ordinary business mail arriving at an agent that can act, which is covered in Prompt injection arrives as ordinary business mail.
Does Connect use these protections?#
Yes, and the public endpoint is the easy case: POST /mcp exposes documentation tools that read generated files, hold no session and reach no workspace, so the worst outcome of an unauthenticated call is that somebody learns what the website already says.
| Control | Behaviour |
|---|---|
| Origin validation | Present and unrecognised → 403; absent → allowed |
| Rate limiting | 120 requests per minute per client address → 429 |
| Body size | 256 KB ceiling → 413 before parsing |
| Header agreement | MCP-Protocol-Version, Mcp-Method, Mcp-Name must match the body → -32020 |
| Batching | Refused — one JSON-RPC message per request |
| Error detail | Internal faults answer with a generic message and no internal path |
Workspace-scoped tools are a separate surface with a separate contract: an integration key, one workspace per key, and the existing domain services underneath so that autonomy, approval, suppression, safe-sales limits, metering and audit all still apply. See Authenticating to the MCP server and Integration keys.
Questions#
My MCP client sends no Origin header. Is that a problem?
No. Desktop and command-line clients are not browsers and normally send none, which is why an absent Origin is allowed. The rule is about a *present* origin: if one arrives, it must be checked, because only a browser sends it and a browser can be driven by any page.
Is rate limiting a security control or a capacity control?
Both, and here it is mostly the first. The public endpoint reads generated files, so capacity is not the constraint; a per-address ceiling keeps one misbehaving client from making the endpoint useless for everyone else.
Can an MCP tool see my workspace data if I have not given it a key?
No. The public tools read the generated documentation corpus and nothing else. Anything that reaches a workspace requires an integration key, and that key fixes which single workspace is in scope — the caller cannot name one.