MCP server security is the work of limiting what an AI agent can reach through the Model Context Protocol. An MCP server gives a model tools and data, so every weakness in it becomes something a model, or an attacker steering the model, can use. Before you connect AI to a CRM, a database or a payments system, check four things: who the server trusts, which tokens it accepts, how narrow the permissions are, and what gets logged.
This guide is for CTOs, founders and product leads who are about to approve an AI agent project. It draws on the official MCP security guidance and the OWASP MCP project. It is a review aid, not a full audit.
Why MCP changes your risk
A normal integration has a fixed set of calls written by your engineers. With MCP, a model chooses which tool to call and with what arguments, based on text it reads. That text can come from a user, a web page, a ticket or a document. If any of it is hostile, the model may act on it.
The OWASP MCP Top 10 lists ten risk categories, and the names show where trouble starts:
MCP01 covers token mismanagement and secret exposure. Keys in config files and logs are the usual leak.
MCP02 is privilege escalation through permissions that grow over time until one token can do far too much.
MCP03 covers tool poisoning, where a tool's description or output carries instructions meant for the model.
MCP05 and MCP06 cover command injection and prompt injection through content the model reads.
MCP07 is insufficient authentication and authorization on the server itself.
MCP08 is missing audit and telemetry. MCP09 is shadow servers nobody approved.
The OWASP page lists the full set as MCP01 to MCP10, including supply chain attacks (MCP04) and context over-sharing (MCP10). The project was still in its beta and pilot phase when we read it, so expect the wording to change.
The attacks the official guide names
The MCP Security Best Practices page for the 2026-07-28 specification describes concrete attacks and what each one needs to succeed.
Confused deputy. An MCP proxy server that talks to a third-party API with one static client ID can be tricked into skipping user consent. The guide says such proxies must keep a per-client consent registry, show the user which client and scopes they are approving, and match redirect URIs by exact string.
Token passthrough. This is an anti-pattern where the server takes a token from the client and forwards it downstream without checking it was issued for the server. The guide states that servers must not accept any token that was not explicitly issued for them. The authorization specification adds that a server must not pass a client's token on to upstream APIs and should use a separate upstream token.
SSRF. A malicious server can point a client at internal addresses during OAuth discovery, including cloud metadata endpoints. The guide recommends HTTPS, blocking private IP ranges, validating redirect targets and using an egress proxy. It also warns against writing your own IP checks, because encoding tricks fool custom parsers.
State handle hijacking. MCP has no protocol-level sessions in this version, so servers hand out their own handles such as a cart or workflow ID. The guide says possessing a handle must never count as authentication, and handles should be random and bound to the verified user.
Local server compromise. A local server runs with the user's privileges. The guide asks clients to show the exact command, unabridged, before running it, and recommends sandboxing.
Scope minimization. The guide warns against publishing every possible scope and against wildcard scopes such as * or full-access. It prefers a small starting scope and step-up requests when a riskier action is first attempted.
What the authorization spec requires
The authorization security considerations give rules you can hand to an engineering team as acceptance criteria:
The same page asks for HTTPS on authorization endpoints, and redirect URIs that are either localhost or HTTPS and exactly matched against the registered value. Ask your vendor or team which of these they actually implement.
The model is not your access control
The OWASP MCP Security Cheat Sheet makes one point that is easy to miss: enforce authorization in application code, not in model judgment. A system prompt that says "only read, never delete" is a hint to the model, not a control. If the token can delete, a manipulated model can delete.
The cheat sheet also tells you to treat tool responses as untrusted input. A search result or a ticket body can contain text that tries to give the model new orders. Never let such content widen what the agent is allowed to do.
A 10-point review checklist
- 1Inventory the serversList every MCP server in use, including ones staff installed themselves. Shadow servers are an OWASP risk.
- 2Check the token audienceConfirm each server rejects tokens issued for another service. No passthrough.
- 3Narrow the scopesStart with read-only. Add write scopes per action, not per server.
- 4Separate credentialsGive each server its own short-lived credentials, not one shared key.
- 5Gate risky actionsRequire human approval for destructive, financial and data-sharing actions, with full parameters shown.
- 6Validate inputsCheck arguments, allow-list URLs and block private IP ranges to stop SSRF.
- 7Pin and review toolsRead the full tool definitions. Pin them by hash and alert when they change.
- 8Sandbox the serversRun servers in containers with minimal file and network access. Separate sensitive ones.
- 9Log every callRecord the tool, parameters, user and time. Redact secrets from the logs.
- 10Vet the supply chainVerify checksums and publishers, and watch for look-alike package names.
Items 7 and 10 come from the OWASP cheat sheet's advice on tool poisoning and supply chain risks. It describes a "rug pull," where a tool changes its definition after you approved it. Pinning and change alerts are the defence.
Common mistakes
Teams new to agents tend to repeat the same errors:
- Giving the agent an admin token "just for the pilot" and never narrowing it.
- Trusting a tool's description because it came from a popular package.
- Logging full request bodies, which then store secrets and customer data.
- Skipping a threat review because the first demo only reads data. Read access to the wrong data is still a breach.
How we approach it at XOSOFT
Our AI and machine learning practice builds generative AI apps and agentic systems, with evaluation harnesses to check behaviour. Security and architecture decisions on our projects are human calls, and our engineers review every line of code. Testing matters just as much, and our QA and testing practice covers API testing and release sign-off for the systems an agent will call.
If you are planning an agent project, you can see how we run engagements on the how we work page. When you want a second pair of eyes on your design or your checklist, book a technical call. It is a technical conversation, not a sales pitch.
Frequently asked questions
What is an MCP server?
An MCP server exposes tools and data to an AI application through the Model Context Protocol. The AI client calls those tools, so the server decides what the model can read or change.
What is token passthrough and why is it forbidden?
It is when an MCP server accepts a client's token and forwards it to a downstream API without checking it was issued for the server. The MCP security guide says servers must not accept tokens that were not explicitly issued for them.
Should the AI model decide who is allowed to do what?
No. The OWASP MCP cheat sheet says to enforce authorization in application code, not in model judgment. The model can be manipulated by text it reads.
Do all MCP actions need human approval?
Not all. OWASP recommends human approval for destructive, financial and data-sharing actions, with the full parameters shown before the user confirms.
Is a local MCP server safe by default?
No. Local servers run with the privileges of the client. The MCP guide asks clients to show the exact command before running it and recommends sandboxing.
Need help with AI and machine learning?
Talk to the engineers who would do the work. We reply within one working day.