MCP servers: what you install when you install one

MCP gives a model access to external tools and data through a standard interface. Adding one feels like installing a browser extension. It is closer to granting an API integration a standing credential and letting something else decide when to use it.

The NSA has published a cybersecurity information sheet specifically on MCP security. Agencies do not write those about low-consequence software.

What the protocol does and does not give you

The specification is explicit that it does not enforce security at the protocol level. Authentication, authorisation, monitoring and governance are left to implementations.

That is a reasonable design choice for a protocol and it means the security properties of any given server are whatever its author built. There is no baseline you can assume.

The failure modes that are documented

Token aggregation. An MCP server holding OAuth tokens for several integrated services becomes a single point of failure. Compromise it and you have not lost one integration; you have lost every service it held.

Confused-deputy problems. A proxy server connecting to third-party APIs can be manipulated into obtaining authorisation codes without proper user consent — the server has the authority, and the attacker supplies the intent.

Untrusted content becoming instructions. Anything an MCP server returns enters the model's context. A server that fetches web pages, reads tickets or pulls email is a channel through which someone else's text reaches your agent as apparent instruction. See Prompt injection.

Before you install one

The same discipline as any skill, and for a stronger reason, because a server runs code rather than merely instructing a model.

Read what it does — the code and the manifest, rather than the README. What does it connect to, and which scopes does it request? A calendar server asking for full mailbox access has told you something.

Prefer official over convenient. Where a service publishes its own server, that carries different provenance from a third-party wrapper around the same API.

Pin a version. Auto-update means today's review does not cover tomorrow's code, and this is the step most commonly skipped.

Local servers get the same treatment. Running on your own machine removes the network hop and none of the access, which is why the specification's guidance on sandboxing, minimal OS privileges and restricted filesystem access is aimed precisely at that case.

Bound what it can reach

Even a well-built server should be granted narrowly.

Read-only where read-only does the job. One service per server rather than one server holding tokens for five. Remove ones you stopped using — an unused integration retains its access indefinitely and nobody is watching it.

In an organisation

Treat adding an MCP server as a procurement decision rather than a preference. Who may add one, who reviews it, whether versions are pinned, and what happens when a publisher changes hands.

Most organisations have a process for npm dependencies and none for this, despite the access being strictly greater: a dependency runs in your build, and an MCP server holds credentials to live systems.

What goes wrong

Judging it like a browser extension. The access is closer to a service account.

One server for everything. Convenient, and it concentrates the tokens.

Installing and forgetting. Access persists, review does not.

Assuming the protocol secures it. The specification says otherwise in plain terms.

Trusting local to mean safe. Local removes the network hop and keeps the filesystem access.

How to check it worked

List the MCP servers you have connected and, for each, name the scopes it holds and the last time anyone looked at it. Anything you cannot answer for is a standing grant to code nobody has reviewed — which is the position this page exists to get you out of.