MCP security is about controlling what an AI agent can reach through Model Context Protocol (MCP) servers, who authorises each connection, and how every tool call is logged and revoked. The 10 controls below cover server trust, authentication, least privilege, prompt injection, human approval, isolation, logging and incident response.
The Model Context Protocol is an open standard that lets AI applications connect to external tools and data through MCP servers. If you are new to the protocol, start with our guide MCP explained: how AI agents connect to business tools and data. This article focuses on what can go wrong once those connections are live.
An MCP server can expose tools that read files, query databases, call APIs or send messages. That is the value, and it is also the risk: every connected server widens what a single agent mistake or attack can touch.
MCP security checklist at a glance
- Keep an inventory of every MCP server and its owner.
- Trust only reviewed servers and pin their versions.
- Authenticate every remote server and user.
- Give each server the least privilege it needs.
- Never pass client tokens through to downstream APIs.
- Treat tool descriptions and tool outputs as untrusted input.
- Require human approval for high-impact actions.
- Isolate local servers and restrict network access.
- Log every tool call with user, agent and parameters.
- Prepare revocation and incident response.
Why MCP changes your security model
Before MCP, each AI integration was custom code that your team reviewed. With MCP, an agent can discover and call tools from many servers, some written by third parties. The agent decides which tool to call based on text, including text that comes from the tool descriptions and results themselves.
This creates several risks that sit alongside the general agent risks described in our AI agent security checklist:
- Prompt injection through tools: A tool result or description contains hidden instructions that redirect the agent.
- Tool poisoning and rug pulls: A server changes its tool descriptions or behaviour after you approved it.
- Over-privileged access: A server holds a broad token, so one mistake exposes far more data than the task needed.
- Confused deputy problems: A server acts with its own authority on behalf of a user who should not have that access.
- Supply-chain risk: An unreviewed package or third-party server runs code on your machine or network.
- Data leakage: Sensitive data returned by one tool is sent onward by another.
The OWASP Top 10 for Agentic Applications and the security guidance in the official MCP documentation are good references for this threat landscape.
1. Keep an inventory of every MCP server and its owner
You cannot secure servers you cannot list. Record for each server: its purpose, who owns it, where it runs (local or remote), which tools it exposes, which systems and credentials it can reach, and which agents and users may use it. Review the list on a schedule, and remove servers nobody owns.
2. Trust only reviewed servers and pin versions
Treat an MCP server like any other dependency that can run code. Prefer servers from vendors you already trust or that you build yourself, review the source or the vendor's security documentation, and pin versions so a silent update cannot change behaviour. Re-review tool descriptions whenever a server updates.
- Do not install servers from unknown sources just because they are popular.
- Check what permissions and network access the server requires.
- Alert when a server's tool list or descriptions change.
3. Authenticate every remote server and user
A remote MCP server that anyone can call is an open door to your data. The MCP specification includes an authorisation framework based on OAuth for remote servers, so use real authentication, tie each session to a user and apply the same access rules you would apply to any internal API.
4. Give each server the least privilege it needs
Create a dedicated identity for each server and grant only the scopes the task requires. A read-only reporting tool should not hold a token that can write or delete. Narrow scopes limit the damage when an agent is manipulated.
- Use read-only credentials wherever the use case allows.
- Limit database access to specific schemas or views.
- Prefer short-lived tokens that can be revoked.
5. Never pass client tokens through to downstream APIs
If a server accepts a token from the client and forwards it to another service, it can bypass the controls of the downstream system and blur who did what. Have the server obtain its own correctly scoped credential for each downstream service and validate that tokens were issued for that server.
6. Treat tool descriptions and tool outputs as untrusted input
Anything an MCP server returns can contain instructions aimed at the model, even if the server itself is honest, for example when it returns a web page, a support ticket or an email written by an attacker. Do not let tool output directly trigger sensitive actions.
- Separate untrusted content from instructions in your prompts.
- Validate parameters for every tool call in code, not only in the prompt.
- Restrict which tools can run after an agent has read untrusted content.
7. Require human approval for high-impact actions
Agents should be able to read and draft freely, but actions such as sending money, deleting data, changing permissions or messaging customers need a human to approve the exact action. Show the user the tool name and the actual parameters, not just a summary.
8. Isolate local servers and restrict network access
Local MCP servers often run with the same rights as the user who started them. Run them in a sandbox or container, limit file-system paths, block outbound network access that the tool does not need, and avoid running servers with administrator rights. For servers that fetch URLs, block requests to internal addresses to reduce server-side request forgery risk.
9. Log every tool call
When something goes wrong you need to know which agent called which tool, for which user, with which parameters and what came back. Keep logs that cover the complete workflow, protect them because they may contain sensitive data, and alert on unusual patterns such as bulk reads or tool calls at odd hours.
10. Prepare revocation and incident response
Decide in advance how you will disconnect a server, revoke its credentials and notify the people affected. Test that revocation works. Run regular red-team exercises that try prompt injection against your real MCP setup before attackers do.
MCP security questions to ask a development partner
If a vendor builds MCP servers or agent integrations for you, ask these questions before signing:
- How do you authenticate users and servers, and where are credentials stored?
- Which scopes does each server need, and how are they limited?
- How do you defend against prompt injection from tool outputs?
- Which actions need human approval?
- What is logged, and who can read the logs?
- How quickly can you revoke access and roll back?
Our guide to building production-ready AI agents covers the wider architecture, and the 15-point vendor checklist helps you evaluate partners.
Frequently asked questions
Is MCP secure by default?
No protocol is secure by default in every deployment. MCP defines how clients and servers talk to each other, but the security of a real setup depends on how you authenticate, scope permissions, isolate servers and review what each server can do.
What is the biggest MCP security risk?
For most businesses it is over-privileged access combined with prompt injection: an agent that can reach a lot of data and can be steered by untrusted text. Least privilege and human approval for risky actions reduce this the most.
Should we use third-party MCP servers?
You can, but treat them like any third-party code. Review them, pin versions, run them in isolation and give them only the access they need. For sensitive systems, building a small server yourself often gives more control.
Do local MCP servers need security controls too?
Yes. A local server often runs with your own user rights, so a compromised or malicious server can read files and run commands. Sandbox it and limit what it can access.
Plan secure MCP integrations with Nextchain
Nextchain.tech designs and builds AI agent systems, including integrations with business tools and data. If you want a second pair of eyes on an MCP design or an agent project, book a scoping call or write to contact@nextchain.kr.
