MCP Server Security: Match the Guardrails to the Blast Radius

Most writing about Model Context Protocol security worries about the malicious server. The daily problem for a team that operates one is different: an assistant that is not malicious, just confidently wrong, about to call a tool you gave it. The useful question is not whether the server is secure, but who absorbs the damage when a call is a mistake.

Three doors, three postures

Door one reads and writes, on the user's own machine. Hiberden, a desktop archiving tool, ships an MCP server with about thirty tools, several of them destructive. That sounds reckless until you ask who is exposed: the person driving the assistant owns the machine and could delete the same copy in two clicks through the app.

The guardrails guard the decision, not the capability. The server runs locally over stdio, with no listening port, and credentials stay in the operating system keyring. Permissions are an application setting the assistant cannot grant itself, read-only is the default, and destructive operations sit behind a switch a human must turn on.

Door two is read-only, on a shared service. Easy2257 hosts 18 U.S.C. 2257 records for producers in a regulated field, and its MCP server exposes sixteen tools that cannot create, change, sign, delete or pay. A mistaken write would alter a legal record about a third party who never consented, so writes were removed.

Read-only is not automatically safe: a tool that returns a date of birth is a breach waiting for an audience. Nothing worth stealing is in the response shape, no names, birth dates, ID numbers or images, only compliance state such as record codes and counts. Credentials are scoped to one account, and outside lookups are throttled.

The threat model people skip

This assumes the assistant means well. It sees “clean up the old stuff”, decides that means the 2019 archive, and reaches for a delete tool because you gave it one. It retries failed jobs and treats text inside a tool result as an instruction: a tool result is untrusted input, like a form field.

Three habits follow. Name tools for what they do: delete_copy gets called deliberately, cleanup speculatively. Make destructive operations narrow and specific: a tool that deletes everything matching a filter is a loaded weapon with a natural-language trigger. And make retries free: idempotency is a security control.

One posture does not fit all

Match the security to the blast radius. The door that can act authenticates people and signs what it sends; the door that writes for other platforms uses live keys and verified humans; the door that can only read carries nothing worth stealing. Never apply one posture everywhere: a read-only server with an over-generous payload can be more dangerous than a write-capable one with an explicit permission switch.