MCP Server Security: 12 Controls to Check Before You Connect AI

Connecting an AI assistant to your CRM, database or ERP is useful precisely because it can act on real systems. That is also the risk. An MCP server is a new door into your business, and it is driven by a language model that can be misled.

Most problems we see are not exotic. They are familiar mistakes in a new place. Shared admin keys. Tools that can do too much. No logs. Nobody reviewing what the tool descriptions say. Each one is cheap to prevent and expensive to clean up.

What this checklist covers

MCP (Model Context Protocol) is an open standard introduced by Anthropic. It lets AI assistants such as Claude, and other clients that support it, connect to tools and data through small programs called MCP servers. Support varies by AI client, so check each client's current documentation before you plan a rollout.

Use the checklist below when you build a new MCP server, buy one, or review one that is already running. Each item has a short explanation. Treat any "no" as a finding with an owner and a date.

The MCP server security checklist

1. Authenticate every user. No anonymous access and no shared accounts. For remote servers, use OAuth where the client supports it, so each person signs in with their own identity. Check the current MCP specification and your client's documentation for supported flows.
2. Authorise per user and per tool. Knowing who someone is does not mean they may do everything. Pass the user's identity to downstream systems where possible, so existing permissions still apply. Otherwise, enforce role checks in the server.
3. Apply least privilege. Service accounts and API tokens get the narrowest scopes that work. A tool that reads orders should not hold a token that can delete customers.
4. Default to read-only. Ship read tools first. Add write tools one at a time, only when there is a clear need and an approval step.
5. Keep tools narrow. "Get order status by order number" is safer than "run any API call". Narrow tools are easier to validate, test and explain.
6. Validate every input. Use strict schemas with types, lengths, formats and allowed values. Reject anything else. Never pass model-generated text straight into SQL, shell commands or file paths.
7. Treat tool outputs as untrusted. Emails, tickets, documents and web pages can contain instructions aimed at the model. This is prompt injection. Do not let tool output silently trigger write tools. Limit which tools can run in the same session, and strip or flag suspicious content where practical.
8. Handle secrets properly. Store credentials in a secrets manager or encrypted environment settings. Never put them in code, tool descriptions, prompts or logs. Use separate credentials per environment and rotate them.
9. Set rate limits and quotas. Limit calls per user and per tool. Cap result sizes and set timeouts. This protects downstream systems and contains a runaway agent loop.
10. Keep audit logs. Record who called which tool, with what inputs, what happened and when. Keep personal data out of logs where you can. Make logs searchable and set a retention period.
11. Require human approval for writes. Any action that changes records, sends messages or moves money shows a preview first. A named person approves it, and the approval is logged. Our guide to AI agents with human approval shows practical patterns.
12. Version and review tool descriptions. The model reads tool names and descriptions to decide what to call. A changed description changes behaviour. Keep them in version control, review changes like code, and be cautious with third-party servers whose descriptions can change without notice.

How to run the review, step by step

1. List every tool with its inputs, outputs, downstream system and the permissions it holds.
2. Write a short threat model. For each tool, ask what happens if the model calls it with the worst plausible input.
3. Walk the checklist and record each gap as a finding with a severity.
4. Test prompt injection. Plant instructions in data the server returns, and confirm they do not cause unintended actions.
5. Test permissions with two users who should see different data.
6. Fix in priority order, starting with anything that allows unauthorised writes or data exposure.
7. Repeat on every release that adds a tool or changes a description.

Tools we use

• MCP SDKs for Python and TypeScript, with strict input schemas.
• Python with FastAPI for validation, auth middleware and integration layers.
• Your identity provider for OAuth and role information.
• A secrets manager and your existing log and monitoring platform.

The MCP specification and client features evolve. Check the current specification and each vendor's documentation rather than relying on older guides.

What you need to get started

• Access to the server's code, configuration and deployment settings.
• A list of connected systems and the credentials each tool uses.
• Someone who can explain who uses the server and why.
• A staging environment for injection and permission tests.

Typical scope and timeline

As an estimate, reviewing a small server with a handful of tools often takes days rather than weeks. Building a new read-only server with these controls in place from the start typically takes one to three weeks, depending on the systems involved.

Findings we see most often

When we review existing servers, a few problems come up again and again.

• One shared token for everyone. The server works, but every user effectively has admin rights in the downstream system.
• A "do anything" tool. A generic API or SQL tool that was meant for testing and never removed.
• Secrets in the wrong place. Keys in a config file committed to the repository, or echoed into logs.
• No record of actions. Nobody can say who changed a record through the assistant last Tuesday.
• Unreviewed third-party servers. A community server installed by one engineer and now used by the whole team.

None of these needs a rewrite. Each is a focused fix, and fixing them early is far cheaper than responding to an incident.

Risks and how we handle them

The biggest risk is treating the MCP server as a quick script rather than production software. We give it the same discipline as any API: code review, tests, staged releases and monitoring. The second risk is approval fatigue, where people click approve without reading. Keep write tools few, previews short and clear, and review approval logs regularly.

When not to build this

If a vendor's official connector meets your needs and its security model satisfies your review, use it. If the data is highly regulated and cannot leave your environment, consider a private deployment first. Our guide to private RAG for regulated data explains the options. And if no one will own the server after launch, do not connect it to write-capable systems.

For specific builds, see connecting your CRM to Claude with MCP and an MCP server for database analytics.

How UnlockLive can help

UnlockLive IT is a Toronto-headquartered software agency with its own engineering team. We build these integrations for companies in the US, Canada, the UK and Australia. Our MCP server development service covers scoping, the threat model, the build, deployment and ongoing maintenance. Our cybersecurity team runs MCP security reviews and delivers a written threat model with prioritised fixes.

If you want a second opinion on scope or risk, book a free 30-minute call. Bring one or two questions your team asks every week, and we will tell you honestly whether an MCP server is the right tool.