MCP security for a business: what the AI can touch, and what it cannot
The sentence that worries people is “we connected the AI to the warehouse system”. The reassurance is not a promise about the model. It is the fact that a connector can only do the things it has tools for.
The capability model, plainly
An MCP server publishes a list of named tools. The assistant can call those tools and nothing else. It cannot browse your database, improvise an API call, or reach a function nobody exposed. If there is no tool that cancels an order, no amount of persuasion cancels an order.
That is a genuinely useful property, and it is why the first security question is not “is the AI safe?” but “what is on the list?”
Read and write are different risk classes
Worth separating properly. A read tool’s worst case is disclosure: something is shown to someone who should not have seen it. A write tool’s worst case is change: something is altered or created that should not have been. These need different levels of nerve.
Our own Linnworks connector ships seventeen tools — thirteen read and four write. The write four are create an order, set a retail price, archive stock items and unarchive stock items. They are deliberately a small, specific, boring list, and they are separable: delete them from the source before you deploy and the connector is incapable of changing anything at all.
That is not a lesser deployment. For most businesses it is the right first deployment, and for some it is the only one they ever need. Start with a connector that can look, and add the ability to touch only when there is a named reason for each tool.
The questions to ask of any connector
- What is the full tool list, and which of them write? If the answer is vague, that is the answer.
- Where does it run? Your infrastructure or someone else’s. This determines who is in your data path.
- Where do the credentials live? They should be secrets in your own platform, not pasted into a config file in a repository.
- Can I read the code? Unobfuscated source means your own developer can audit the whole surface in an afternoon.
- Who can reach the endpoint? An MCP endpoint on the public internet needs bearer-token auth at minimum. An unauthenticated one is an open door to your order data.
- What is logged? You want to know which tools were called. You do not want full customer records sitting in log retention forever.
Prompt injection is the real one
The underrated risk is not a rogue model. It is untrusted text. If the assistant reads a customer’s order note and that note contains instructions, the instructions are in the context. With read-only tools the worst outcome is a confused answer. With write tools it is an action you did not authorise.
Two mitigations, both unglamorous: do not grant write capability you do not need, and keep a human approving anything consequential. “The AI drafts, a person commits” is a boring pattern that survives contact with reality.
Least privilege at the Linnworks end too
Give the connector its own Linnworks application credentials rather than reusing an existing integration’s. One credential, one purpose, revocable in isolation on a bad day. Rotate the bearer token when someone leaves.
Because the Linnworks MCP server ships as complete, readable source, the audit above is something your own developer can actually do — and the read-only deployment is a deletion rather than a feature request. Longer version: securing a self-hosted MCP server.
Questions, or want a tool we don't have yet? Email hello@grafto.co.uk — a real person replies.