The MCP Security Playbook

The Model Context Protocol (MCP) has become the standard way to connect AI agents to tools, databases and SaaS systems. That success is exactly why it is now a security priority: MCP standardises how a model discovers and calls tools, but leaves authentication, authorisation and transport security to whoever builds each host, client and server. Between January and February 2026 researchers filed more than 30 CVEs against MCP servers, clients and infrastructure, and government and industry guidance — including a June 2026 joint security advisory and the OWASP MCP Top 10 — now treats MCP as a distinct attack surface. This playbook turns that guidance into a working checklist.

Related tools and comparisons: Best AI agent frameworks · Multi-agent orchestration playbook · Enterprise AI privacy compared.

---

1. Understand the threat model

An MCP deployment has three moving parts: a host (the AI application), clients inside it, and servers exposing tools and data. Risks concentrate in a few places:

• Prompt injection through tool output. Anything a tool returns — a web page, a ticket, an email — can contain instructions aimed at the model.
• Malicious or poisoned tool descriptions. A server can change what a tool claims to do after you approved it.
• Over-privileged servers. A server with a broad token turns one successful injection into full account access.
• Supply-chain compromise. Community MCP servers are code that runs with your credentials.
• Compounding exposure. Independent research from Palo Alto Networks Unit 42 measured a 78.3% attack success rate when five MCP servers were connected to a single agent — every additional server multiplies the risk.

2. Authenticate every connection

• Require authentication on every remote server; never expose an unauthenticated MCP endpoint to a network.
• Use OAuth-based flows with short-lived, narrowly scoped tokens rather than long-lived API keys.
• Give each server its own credentials so a compromise stays contained.

3. Authorise every tool call

Authentication answers who; authorisation must answer may this agent do this now. Apply least privilege per tool:

• Separate read tools from write/delete tools and put approval gates on the latter.
• Require human confirmation for irreversible actions: payments, deletions, external messages.
• Enforce authorisation on the server, not just in the prompt — instructions to the model are not a security control.

4. Protect tool-description integrity

Tool descriptions enter the model's context, so they are effectively instructions. Hash each tool description at deployment time and verify the hash on every tools/list response before the description reaches the model; alert on any change. Treat a changed description like a changed dependency.

5. Validate data in both directions

• Validate and constrain tool inputs (types, lengths, allow-lists) on the server.
• Treat all tool output as untrusted; strip or flag content that looks like instructions.
• Scan for sensitive data leaving through tool calls, and redact where possible.

6. Secure the supply chain

• Prefer servers from vendors you already trust; review the source of community servers.
• Pin versions, scan dependencies, and review changes before upgrading.
• Run servers in sandboxes or containers with minimal network and filesystem access.

7. Limit blast radius

• Connect only the servers a given agent needs. Fewer servers means a smaller injection surface.
• Use separate agents for separate trust zones (for example, one that reads the public web and one that touches internal systems), never both in the same context.
• Set rate limits and spending caps per agent.

8. Log, monitor and test

• Log every tool call with the caller, arguments and result size; ship logs to your SIEM.
• Red-team your agents with injection payloads before launch — Promptfoo can automate much of this.
• Trace production behaviour so you can investigate incidents; see the LLM evaluation & observability playbook.

9. Rollout checklist

1. Inventory every MCP server in use (including ones developers installed locally).
2. Remove any unauthenticated or unused servers.
3. Scope tokens to least privilege and rotate them.
4. Add approval gates to write and delete tools.
5. Pin versions and hash tool descriptions.
6. Enable logging and alerting on tool calls.
7. Run an injection red-team before each major change.
8. Review the list quarterly — servers accumulate.

The bottom line

MCP does not make agents unsafe; unmanaged MCP does. Treat servers as you would any third-party integration with production access — authenticate, authorise, pin, monitor — and assume tool output is hostile. Teams that do the basics above remove most of the risk that has produced this year's CVEs.