What is an MCP server?

A Model Context Protocol (MCP) server exposes tools, resources and prompts to an AI agent through a standardised JSON-RPC interface. It lets an LLM read files, query APIs or trigger actions on systems you control. Because the server executes real operations on behalf of the model, it is a security-sensitive boundary that must be treated like any other production API.

Why do MCP servers need security testing?

An MCP server bridges untrusted model output and trusted infrastructure. A compromised or badly-scoped server lets a prompt-injection payload trigger unintended tool calls, leak data, or authenticate as a privileged user. Traditional web security testing misses these issues because they live in the model/tool interaction, not the HTTP layer.

Can prompt injection attack an MCP server?

Yes. If the agent reads external content through an MCP resource (a webpage, PDF, email) and that content contains injected instructions, the agent can be coerced into calling MCP tools in ways the user never intended. Hardening requires careful tool-call scoping, human-in-the-loop confirmation for sensitive actions, and content-source segregation.

How does an MCP server differ from a REST API?

REST APIs are usually called by deterministic application code. MCP servers are called by an LLM that may hallucinate arguments, combine tools creatively, or follow injected instructions. Authorisation must therefore be per tool-call and per resource, not per session; rate-limits must consider agent-driven bursts; and every call must be attributable to a human principal.

Does YUPL perform MCP and AI agent security assessments?

Yes. Our CREST-aligned team tests MCP servers, agent frameworks and LLM-integrated web apps against the OWASP LLM Top 10 and our own agent-security checklist. Engagements include tool-call abuse testing, prompt-injection payload discovery, and a remediation report mapped to ISO 27001 / SOC 2 controls.

MCP Server Security Checklist 2026

MCP Server Security: A Practical 2026 Checklist for UK Teams

Published: 19 Apr 2026 Reviewed by: Spencer Schotel 5 min read

Model Context Protocol (MCP) moved from interesting spec to "plugged into most serious agent stacks" in under a year. If you are shipping an MCP server — or letting an agent call one inside your production environment — you have a new security boundary that most traditional tooling misses entirely. This is a pragmatic, CREST-aligned checklist we use when assessing client MCP deployments.

It is deliberately stack-neutral: whether you host MCP servers in-process, over stdio, or over streamable HTTP, the failure modes and the controls are the same. At YUPL's AI development team we build these servers, and at our pen-testing team we attack them — so the advice below is informed by both sides.

1. Treat the MCP server as an authenticated API

The single biggest mistake we see is exposing an MCP server with no per-principal authentication because "only the agent talks to it". In practice, the agent is driven by user input, which is driven by untrusted content — emails, uploads, web pages. Every tool call must be attributable to a specific human principal.

Require per-user auth on every MCP transport — OAuth 2.1 with short-lived tokens over HTTP; signed environment tokens over stdio.
Scope tokens per-session with the minimum capability set the user actually needs for this interaction.
Reject anonymous sessions outright; do not rely on network-layer isolation alone.
Log the principal on every single tool-call invocation.

2. Scope tools aggressively, per call

Agents will call tools in combinations you never imagined. Build capability scoping into each tool, not just into the session.

No wildcard filesystem or SQL tools without a path/query allow-list enforced on the server.
Parameterise every query — never template user or model output into SQL, shell or OS paths.
Default to read-only; any write, delete or external-send capability should require explicit user confirmation or an out-of-band approval workflow.
Split destructive tools into two steps — plan and execute — so the plan can be audited before execution.

3. Harden against prompt injection and tool-poisoning

Prompt injection is the #1 OWASP LLM risk and the primary attack path against MCP. If an agent reads external content, it can be coerced into issuing tool calls the human user never requested. See our OWASP Top 10 walkthrough for the wider web-app context.

Segregate content sources in prompts — mark untrusted content with delimiters the model respects, and tell the model never to follow instructions inside those delimiters.
Require user confirmation for any tool call whose arguments were derived from external content (fetched web page, attachment, inbox).
Apply output-side filters to detect tool-call arguments that look like exfiltration — URLs to unexpected domains, base64 payloads, unexpected file paths.
Red-team with an offensive corpus of known injection payloads; we maintain one specifically for MCP tool abuse.

4. Rate-limit for agent-driven bursts

Classic per-IP rate-limits miss the mark: a single agent session can issue hundreds of tool calls a minute. Rate-limits must be per-principal and per-tool.

Budget tool calls per session and reject once the budget is exceeded, even for legitimate-looking calls.
Cap concurrent tool calls to prevent a runaway agent fanning out across expensive endpoints.
Cost-track every call — LLM cost, downstream API cost, latency — so abnormal usage is visible in dashboards, not just logs.

5. Log everything, sign what matters

When an agent does something unexpected — and it will — the only way to understand what happened is a complete, tamper-evident audit trail.

Log every tool call: principal, tool name, full arguments, origin (human prompt vs content-derived), timestamp, latency, result.
Hash the prompt chain that produced the call so you can reconstruct why the agent made it.
Ship logs off-host and sign them; a compromised MCP server must not be able to rewrite its own history.
Alert on tool-call anomalies: novel combinations, spikes in write operations, arguments resembling encoded exfiltration.

6. Test the MCP server like any other production API

Automated scanners catch the HTTP-layer issues — missing auth, weak TLS, verbose errors. Everything agent-specific still needs humans. Our web-app testing methodology applies, extended with agent-specific phases:

Unauthenticated access testing across every transport the server supports.
Tool-call abuse — what happens when the agent calls a tool with arguments drawn from an attacker-controlled document?
Authorisation bypass — can a user's session token be used to invoke tools scoped to a different tenant?
Prompt-injection red-teaming against the combined model + MCP server, not either in isolation.
Dependency review — MCP servers often depend on small open-source packages; a compromised dependency owns the server.

7. Plan for the governance questions your buyers will ask

By late 2026, every serious UK enterprise security questionnaire includes AI-agent-specific questions. If you want enterprise logos you need defensible answers to all of these:

Which MCP servers do you run, and what data can each access?
Who authenticates to each, and with what scopes?
How are prompt-injection risks tested and monitored?
How is tool-call auditability evidenced during an incident?
What is your agent kill-switch procedure?

These map cleanly onto ISO 27001 Annex A, SOC 2 CC6/CC7 and — for EU-market products — the Cyber Resilience Act. We build those mappings into every client engagement. For the wider UK compliance picture see our SaaS compliance playbook.

Where MCP security sits in your overall roadmap

If you already have a mature web-app and API security programme, adding MCP coverage is an incremental investment — not a whole new programme. The components overlap with classic web testing: authentication and session management (same principles, stricter scoping); input validation (now includes LLM-derived inputs); logging and monitoring (richer, more structured, with prompt provenance); pen testing (add an explicit agent-security phase).

If you are earlier in the journey, start by mapping every MCP server, documenting its capabilities, and running a focused assessment before your first external audit. Do not wait for an incident to surface the gap.

Next steps

We run MCP-focused security assessments alongside our standard web-app, API and Laravel engagements, producing a single CREST-aligned report that maps findings to your compliance framework. If you are deploying agents to production, or a buyer is asking questions you cannot currently answer, talk to our team.