Securing a self-hosted MCP server before you point it at live business data
Self-hosting an MCP connector is the right call when the data is commercially sensitive. But “on our own infrastructure” is not the same as “secure” — it just means the responsibility is now yours. Here is the checklist worth working through before it sees production data.
1. Treat credentials as the whole problem
The connector holds API credentials for a system that knows your customers, your costs and your orders. Those belong in your platform’s secret store, not in source, not in a committed config file, and not in an environment file that ends up in a backup. Rotate them on a schedule, and make sure you know how to rotate them in a hurry — the day you need to is not the day to find out.
2. Start read-only, and be deliberate about ever changing that
A read-only connector has a bounded blast radius: the worst case is disclosure, not destruction. Write capability is a different risk class entirely and should be added tool by tool, with a reason for each, rather than switched on wholesale because it might be useful later.
3. Put authentication in front of it
An MCP endpoint on a public URL with no auth is an open API over your business. Whatever transport you deploy, require a credential to reach it, and make that credential per-client rather than one shared token that has been pasted into four laptops.
4. Log what was asked, not just that something happened
When someone asks in six months what the AI client could see, you want an answer. Log the tool called, the caller and the time. Be careful about logging full responses — that turns your log store into a second copy of the sensitive data, with weaker controls around it.
5. Know where the data goes after your server
This is the question a security reviewer or DPO will actually ask, and it is not about your server at all: which AI client is consuming the connector, under what terms, in which region. Self-hosting controls the connector; it does not control the model provider. Document both halves. Making connectors acceptable to a DPO covers the paperwork side.
6. Handle upstream failure without leaking detail
Rate limits, expired tokens and upstream outages are normal operating conditions, not exceptions — see rate limits and sudden 401s. Return a clean error to the client rather than passing an upstream stack trace through; error bodies leak more than people expect.
7. Review the code you deployed
The advantage of buying source over renting a service is that you can read it. Use that advantage: before deploying, read the auth layer and the client, and satisfy yourself about what each tool can reach. A connector you have read is a connector you can defend in a review.
The Linnworks MCP source ships as complete, unobfuscated TypeScript for Cloudflare Workers with read-only tools, precisely so that this review is possible. Find out more →
Questions, or want a tool we don't have yet? Email hello@grafto.co.uk — a real person replies.