An MCP server is how an AI agent reaches your real systems — files, databases, APIs, internal tools. That makes it one of the most powerful things you can give an agent, and one of the most dangerous if you build it carelessly. An MCP server is a security boundary. Treat it like one. Here is the checklist we run on every one we build.
1. Expose the Least, Not the Most
The instinct is to expose a broad, flexible tool — “run any query,” “call any endpoint.” Resist it. Each tool should do one specific, bounded thing: get order status, not query the database. The narrower the tool, the smaller the blast radius when something — a prompt injection, a bug, a confused model — tries to misuse it.
2. Start Read-Only
Ship the first version with no ability to change anything. Let it read, query, summarize, and recommend. Add write capabilities later, one deliberate action at a time, each with its own permissions and approval. Most of the value of an agent shows up in read-only work anyway — and you learn how it behaves before you give it the ability to break something.
3. Authenticate the Transport
The connection between the agent and the MCP server must be authenticated and encrypted. An unauthenticated MCP endpoint on your network is an open door to whatever it exposes. Use proper credentials or tokens, rotate them, and never bake them into client-side code.
4. Validate Every Input
The arguments an agent passes to a tool are untrusted input — the model can be manipulated into sending hostile values. Validate types, ranges, and formats at the server, exactly as you would for a public API. A tool that takes a file path is a path-traversal risk; a tool that takes a query fragment is an injection risk. Assume the caller is adversarial.
5. Enforce Permissions Server-Side
Access control belongs on the server, not in the prompt. “Only answer for data this user can see” is not a rule you can trust the model to follow — it is a rule the server must enforce, on every call, based on the acting user’s real permissions. If your MCP server does not know who it is acting for, it cannot protect anything.
6. Log Everything the Agent Does
Every tool call, its arguments, its result, and the identity behind it should be logged. When something goes wrong — or when an auditor asks — you need to reconstruct exactly what the agent did and why. Audit logs are not optional for anything touching real data.
7. Gate Consequential Actions With Human Approval
Anything irreversible or expensive — sending money, deleting records, emailing customers — should require explicit human sign-off before it executes. The agent proposes; a person approves. This one control prevents the majority of “the AI did what?” incidents.
8. Test the Ways It Fails
Before production, probe it: can a prompt injection make it call a tool it should not? Can a malformed argument crash it or leak data? Can user A get a result sourced from user B’s data? These are not hypotheticals — they are the standard failure modes of agent infrastructure, and they should be tested deliberately.
Build It Like Infrastructure, Review It Independently
An MCP server is production security infrastructure, and it deserves an independent look. Software Depo builds MCP servers to this checklist; for a separate security assessment, our sister practice BulletproofSoft reviews AI and MCP deployments — a different team, by design.
Tell us what systems your AI needs to reach and we will design the server — and the security model — around them.
