Securing Remote MCP Servers
This week, I had the pleasure of speaking at FWD:Cloudsec about securing remote MCP servers. As I normally speak about security data analytics, it was a welcome break to research and educate about something topical.
For those of you who prefer to read rather than watch, I’ve curated my speaker notes below:
What is MCP?
MCP is essentially a spec for writing APIs with built-in documentation for easier LLM integration. MCP servers might be remote resources or local executables, registered with clients like ChatGPT, Claude desktop, or IDEs.
Securing Locally Hosted Servers
If the deployment instructions say NPX or UVX run github.com/yayada/mcp.py, you’re essentially hosting an executable or library. Treat it like typical developer code:
- Scan the code and dependencies more frequently post deployment than you would normally. Many of the common libraries for MCP servers are maintained by small teams or individuals and have a lot of eyes on them.
- Host proprietary code in private git repos, use build pipelines, and containerize deployments for better isolation.
- Trendy installations like npx or uvx are effectively “curl piped to bash,” making them risky. Use signatures where possible or commit hashes where not.
Securing Remote Hosted Servers
Here things get more complex. Let’s step back and explore the technologies involved.
Transports:
MCP is officially a transport agnostic protocol but the following are commonly used and discussed in the spec:
- Server Sent Events (SSE): Solid for streaming responses but requires multiple endpoints, also can expose CSRF vulnerabilities (it uses GET requests) if using through a browser client. Technically deprecated but still used.
- Streamable HTTP(S): A new Anthropic-created standard using POST. Better bidirectional support, but watch for DNS rebinding attacks and ensure proper origin header checking.
Session Isolation:
MCP flips traditional browser security on its head. Instead of isolated sites, every MCP tool can interact with others, like browser extensions with excessive permissions. The result? Imagine online banking when all your browser tabs could access each other.
Most headline-making threats (rug pulls, poisoning…) are due to client-side implementations rather than MCP itself. While this problem is best solved on the client level, server mitigations can be effective as well.
Authorization
The spec demands OAuth and forbids simple token passthrough, but many implementations ignore this, simplifying things but creating risks such as:
- Harder auditing, potential data exfiltration, and tricky rate-limiting.
- Technical debt if OAuth implementation becomes necessary later.
If you use OAuth:
- Watch out for the confused deputy problem with third party auth servers.
- Track and bind tokens per client, validate request URIs, match auth codes to sessions….
- Implement forced re-consent for new clients and bind sessions securely.
Peter Horrigan wrote an excellent deep dive on this with code samples
API Gateways and Middleware
Many enterprise customers I talk to are using an API gateway. The big vendors already have AI and MCP support to some degree. I like this method (and platform security in general) because it centralizes authentication, session token generation, request validation, and unified logging. OAuth is complex and MCP is new, so taking a platform engineering approach reduces that complexity.
Consider middleware restricting session access to unique MCP tools to enhance governance as well. I haven't seen this in the wild but I think its a good idea.
Logging and Observability
Due to MCP’s agentic nature (LLM-determined parameters) and the fast pace of MCP development, extensive logging is crucial:
- Log everything: parameters, tokens, commands, and user metadata.
- Retain logs for extended periods. Tomorrow’s Indicators of Compromise (IOCs) might emerge from today’s unknown unknowns.
- A security data lake offers flexibility, linking contexts together effortlessly.
Tools and Resources

- Check the Awesome MCP Security repo by Maciej Pulikowski.
- Engage with the MCP community on Discord (ask around for an invite), GitHub, and through the official spec and best practices document.
Feel free to reach out as well, I’m active here, on LinkedIn and on the Cloud Security Forum slack.
Thanks for reading!
This article originally appeared on Medium.