Part 1: Understanding and Assessing MCP servers from an AppSec Perspective
Introduction
Hello everyone! Chances are, if you're involved in Application Security, you've already heard of - or even used the Model Context Protocol (MCP). As is often the case with new technologies, MCP introduces powerful capabilities, but also a new set of security challenges. Despite the rapid adoption, security best practices, formal guidelines, and mature documentation for MCP are still in development.
At the time of writing, the most relevant resource appears to be the OWASP MCP Top 10 project. While still in progress, the very existence of this project highlights that MCP presents distinct security risks not covered by traditional LLM or plugin assessments - even though those domains already have robust frameworks from OWASP, Google, and others.
What Is MCP and Why It Matters
Rather than go into exhaustive detail about the protocol, I'll defer to the official documentation here.
In brief, MCP is a protocol that connects your IDE (e.g., Cursor, Copilot, Claude-based tools) with various APIs and services (e.g., GitHub, Jira, internal APIs). It lets AI assistants handle developer tasks via "tool calls", so a prompt can update code, push commits, close Jira tickets, and even edit wiki entries - all through natural language.
Sound like a dream? It is. And that's exactly why developers, QA, and even DevOps teams are excited to integrate MCP today - while AppSec teams are scrambling to understand the implications.
With an expanding list of MCP servers, it's highly likely that organizations will adopt some of these servers without centralized oversight. Security teams will then find themselves tasked with reviewing these deployments often reactively.
Risk Landscape and Early Guidance
To assess any MCP integration securely, we must understand what we're defending against. While OWASP's official Top 10 for MCP is still a draft, an excellent interim list is provided by Philippe Bogaerts in his article: OWASP Top 10-alike Security Risks for MCP
The guidance in this article is largely inspired by Philippe's risk categories, adjusted to support security teams tasked with real-world reviews.
Step 1: Understand Usage Context
Your first question should always be: How is this MCP server going to be used?
There's a world of difference between:
- A local MCP instance used by a single developer
- A shared or production-like deployment used within a department
For local Docker-based usage, some hardening (e.g., OAuth) may not be relevant. But that doesn't mean the server is inherently safe - only that the risk exposure is narrower.
If the MCP server is part of the modelcontextprotocol/servers GitHub repo, that's a good sign: community-backed, open-source, usually well-documented and most likely this is an official MCP server from the supplier. That gives us a significant advantage for auditing. It's also worth thoroughly reviewing the official documentation provided for each server - especially when it's tied to a known tool or vendor. Well-maintained MCP servers often include detailed descriptions of supported actions and their corresponding permission levels (e.g., read, write, delete), which can greatly help assess the security boundaries of each integration.
Step 2: Source Code Review - Manual and Automated
I strongly recommend reading the source code manually, even if you're also using a SAST tool. Given how new MCP is, most SAST tools don't yet include MCP-specific rules.
When reviewing the code, pay particular attention to the prompt-handling logic. Evaluate how input prompts from users are passed to tool actions, and inspect any transformations, validations, or assumptions. Look for potential prompt injection vectors or logic that allows unsafe or overly permissive actions. Be aware of advanced patterns like tool poisoning, where the attacker manipulates prompt context or tool metadata to mislead the AI agent into executing unintended actions. This attack is especially relevant for MCP-based integrations. For a deeper understanding, see the detailed write-up from Invariant Labs: Tool Poisoning Attacks on MCP. Your goal is to ensure the MCP server does not allow untrusted input to result in unintended tool behavior - especially destructive operations like delete, overwrite, or privilege escalation.
You may also start by locating any access control logic. Example: Jira integration ACL in MCP-Atlassian
Step 3: Set Up a Controlled Test Environment
Typically, the MCP server is available as a Docker image, which makes it easy to launch and test. Deploy it and pair it with an IDE that supports MCP (e.g., Cursor).
I personally tested the GitHub and Atlassian MCP servers using this setup, which also allows configuration of per-action permissions for the AI agent.
Once configured, a tool call like "github-mcp-server push changes" will trigger a live request via Docker.
For more visibility and control, use MCP Guardian to wrap the interaction.
Setup Walkthrough for Cursor + MCP Guardian + GitHub MCP
Install MCP Guardian (Mac): Follow the instructions here
Configure MCP Guardian profile:
{ "cmd": "docker", "args": [ "run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server" ], "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "..." } }Register the server in Guardian collection:
{ "servers": [ { "mcp_server": "github-mcp.github-mcp", "guard_profile": "mcp-guardian.approve-tool-call-requests-and-responses" } ] }Add MCP config to Cursor IDE:
{ "mcpServers": { "github-mcp": { "args": [ "--mcp-server", "github-mcp.github-mcp", "--guard-profile", "mcp-guardian.approve-tool-call-requests-and-responses" ], "command": "mcp-guardian-proxy" } } }Run Docker Desktop, restart Guardian and Cursor
If it fails, ensure the token is inherited:
export GITHUB_PERSONAL_ACCESS_TOKEN=github_pat_11... open -a Cursor
Once working, you'll be able to inspect every MCP request going from the IDE to the MCP server via Docker logs and MCP Guardian.
Step 4: Recommendations and Decision-Making Guidance
After thoroughly testing the MCP server in this way, you'll be in a strong position to define installation requirements and usage constraints - including which tool actions should be allowed or disallowed. Based on the observed behavior, you can issue usage guidelines that align with your organization's internal policies and security posture.
To minimize risk, follow the principle of least privilege. Recommend configuring the MCP server to operate with minimal required permissions - use service accounts with tightly scoped access tokens. Clearly define which actions are permitted and restrict or disable high-impact operations unless explicitly needed.
Also, some MCP server providers publish their own hardening or security guidelines. For example, the Atlassian MCP server provides a SECURITY.md file with implementation notes and recommended practices.
If you choose to approve the MCP server for local use, keep in mind that your review applies to a specific version. It is strongly recommended to pin that version explicitly, either by forking the reviewed codebase or storing a vetted copy in your organization's trusted artifact repository. This ensures that future updates do not silently change the server's behavior without re-review.
Conclusion
In this article, we focused primarily on local MCP usage and how to approach reviews from an AppSec perspective. We covered how to evaluate source code, inspect behavior using MCP Guardian and Docker, and define usage recommendations and technical constraints based on real testing results
In the next part, we’ll dive into corporate MCP deployments, formal security best practices, CVE analysis, and a full checklist for reviewing and maintaining secure MCP usage at scale.