MCP Server Security: What to Check Before You Connect

TL;DR: Almost every MCP security guide is written for the team operating a server — container isolation, TLS binding, host header validation. Useful, and mostly not your job. If you are connecting an agent to Slack, GitHub, Postgres and your CRM, you are a client operator, and your entire control surface is four things: which servers you allow, what scope their credentials carry, which tools each agent can reach, and what requires a human before it commits. The documented incidents so far all failed on one of those four, not on the protocol.

The guides are answering someone else's question

Search "MCP server security" and you get a consistent checklist: run servers in Docker or gVisor, bind to 127.0.0.1 instead of 0.0.0.0, validate the Host header, enforce TLS, sign JSON-RPC messages. Every item is correct. Most of them apply to about 5 percent of the people reading them.

MCP has two operator roles and they own different risks. The server operator exposes a system and owns process isolation, transport and input validation. The client operator — you, if you are connecting an agent platform to systems you already pay for — owns which servers get trusted, what credentials they hold, and what the agent is allowed to do with the result. You cannot sandbox Stripe's server. You can decide it never gets a write scope.

That split matters because the loud half of the checklist is the half you can't act on, and the quiet half is where every real incident has landed.

If you need the protocol itself first, what MCP is in plain English covers the mechanics, and the AI integration guide covers where MCP sits among the four ways AI reaches your systems at all.

What has actually gone wrong

Not theoretical. Five documented cases, all from the first eighteen months of the ecosystem:

When	What	How it failed
Apr 2025	Asana's AI feature	Multi-tenant separation bug created cross-organisation exposure; feature pulled for two weeks and user connections reset
May 2025	GitHub MCP server	A malicious issue in a public repo carried hidden instructions; the agent pulled private repo contents into a generated PR
Sep 2025	postmark-mcp npm package	Published with a backdoor that silently BCC'd outgoing mail — password resets, invoices, internal threads
Nov 2025	WhatsApp integration	A poisoned tool description on a second server caused message-history exfiltration through a benign-looking call
Nov 2025	Anthropic's Git MCP server	Path validation bypass and argument injection chained with a filesystem server into remote code execution

Read the "how it failed" column again. One is a supply-chain compromise, one is a classic multi-tenancy bug, one is a genuine code vulnerability — and two are the same thing: the model treated text it fetched as instructions it should follow. Checkmarx's incident review has the full technical detail on each.

None of them would have been prevented by TLS.

Four attack shapes worth naming

Tool poisoning. Instructions hidden in tool metadata. OWASP now tracks it as its own attack class, and the important nuance is that the whole schema is the injection surface, not just the description string — parameter names and return schemas get read into context too. The user approves a tool called search_docs; the model reads a description that also says to include the contents of the last file it opened.

Cross-server shadowing. You connect two servers. Server B's tool description contains instructions about how to call server A's tools. The agent has no concept of "these came from different trust domains" — it has one context window with everything in it. This is why the count of connected servers is itself a risk number.

Over-scoped OAuth and the confused deputy. The server asked for repo because per-repository tokens are annoying. Now every agent that can reach that server can reach every repository. The OWASP MCP cheat sheet is blunt about the related failure: bind session identity per request and never pass a token through to a downstream API, or the server becomes a deputy that authorises actions on behalf of the wrong caller. RFC 8707 resource indicators exist specifically so a token issued for one server can't be replayed against another.

Rug pulls. The server you audited in March ships a new tool definition in June. Nothing in the default flow re-prompts you. Pin tool definitions by hash and treat a change as re-approval, not as an update.

The controls that actually reduce blast radius

Ordered by how much risk they remove per hour of work, for a client operator:

1. An allowlist of servers, owned by someone. Not "whatever a developer connected." A registry with a named owner per entry, and a default-deny for everything else. This is the same problem as shadow AI and it has the same solution: give people a fast sanctioned path, or they build an unsanctioned one.

2. Scope the credential to the tool's stated job. An agent that reads invoices does not need write access to the vendor master. If the server only offers a broad scope, that is information about the server — weigh it.

3. Per-agent tool allowlists, not per-server. Connecting a Postgres server does not mean every agent gets every query tool. The unit of authorisation is the tool, evaluated per invocation. A support agent and a finance agent connected to the same server should not have the same reach.

4. A human gate on anything irreversible or outbound. Payments, external email, deletions, anything a customer sees. This is the control that turns a successful poisoning attempt into a rejected approval request instead of a wire transfer, and the reasoning behind it is unchanged from why full autonomy is the wrong goal.

5. A tool-call audit log with parameters, not just tool names. "The agent called send_email" tells you nothing. "The agent called send_email with these recipients at 03:12 under this agent's identity" is an investigation you can close. Under the EU AI Act's transparency and record-keeping duties, it is also increasingly not optional.

6. Read the schemas before approving. Tool names are marketing. Descriptions and parameter schemas are what the model actually reads. Scanners like mcp-scan automate the first pass; the Cloud Security Alliance's agentic MCP best practices covers the vetting dimensions in depth.

Together these are the same guardrail set that makes any agent with write access approvable — MCP just makes the scoping question concrete, because there is finally a named boundary to scope.

What does not work

Telling the model to ignore instructions in tool output. It helps and it is not a control. Any defence that lives in the prompt is defeated by a better prompt in the data. Treat model-level mitigation as depth, never as the layer you're relying on.

Reviewing at install time only. Policy has to be enforced before each execution, because tool definitions change and context changes. An install-time approval is a snapshot of a system that moves.

Counting connectors as a security feature. "500 integrations" is a statement about breadth, not about scope granularity. Ask instead: can I give one agent read-only on this server and another agent nothing at all?

Assuming the API-less systems are safer. They aren't, they're just reached differently — through file exports or screen automation, as covered in connecting a legacy ERP. Screen automation in particular carries the credential of whoever is logged in, which is usually broader than any OAuth scope you'd have granted.

How this works in Oido

Concretely, so the claim is checkable.

MCP servers are registered per organisation, not per user — one registry, an owner, and an enable/disable switch that takes effect without redeploying anything. OAuth tokens are stored per server rather than shared across them, so revoking one connection does not mean rotating everything. Servers in production use across deployments include Postgres, Slack, GitHub, Notion, Google Drive and Stripe.

Authorisation is per tool, per agent. An agent definition carries an explicit tool list, and a skill can narrow it further at runtime — so the finance agent and the support agent sharing a Postgres connection genuinely do not share reach. Every tool call is written to an audit log with its agent identity.

For the irreversible steps there is a durable approval gate: the agent suspends, an approval request goes to Slack or Telegram with the action summary, and the run resumes only when a human presses the button. It survives restarts, because an approval that expires when a process dies is not a control. The same reasoning shapes the controls on the browser agent, where the credential in play is a live session rather than a scoped token.

The takeaway

You are not securing a protocol. You are deciding, per server, what a system you don't control is allowed to make your agent do.

Four questions answer it. Who approved this server and can they be named? What scope does its credential carry, versus what its tools claim to need? Which agents can reach which of its tools? And what does it have to ask a human before it does?

Get those right and the container-isolation checklist stops being your problem — it belongs to whoever runs the server. Get them wrong and no amount of TLS helps, which is exactly what the 2025 incident list demonstrates.

Want the connection surface mapped for your stack before anything gets a credential? That is the first conversation we have — see how the platform connects.