Inside an MCP Pentest
Overview
MCP is moving from experiment to production faster than the security guidance around it. Useful resources exist, OWASP's MCP Top 10, MITRE ATLAS, Adversa's MCP Top 25, but most are catalogs of risks rather than end-to-end assessment methodologies. This post tries to close that gap.
The risks are real. Prompt injection has triggered unintended tool execution. MCP servers have been deployed with far more privilege than they needed. Connected knowledge bases have been used to exfiltrate data. Misconfigured connectors have exposed internal systems. Because MCP often sits between an LLM and sensitive data or high-impact tools, weak access control turns into a high-value target fast.
Coming from AppSec, a lot of this feels familiar, over-permissioned components, weak auth between trust boundaries, secrets sitting in config files. What's new is the trust topology between the LLM, the host, the clients, the servers, and the tools each server exposes. That's what makes a written-down approach worth having.
This post is for red teamers, security consultants, detection engineers, and platform owners who assess or operate MCP-enabled environments.
Identifying the Engagement Drivers
Start by asking why the assessment is happening. The driver, a recent breach, a compliance deadline, the rollout of a new MCP-enabled system, or an expansion in model capabilities, sets the scope, the depth, and the focus of the work. Time is always limited, and this single question usually decides what gets tested first and what gets cut or at least prioritized.
Mapping the MCP Architecture
Before testing anything, get the architecture on one page. Map the host, the clients, the servers, the tools each server exposes, and the resources behind those tools. Note where privileges sit and how authentication and authorization are enforced at each hop. Trust boundaries and data flows become obvious once they're drawn.
Defining the Scope for the Assessment
Scope decides what assurance you can give. Without precise boundaries, components get missed or assumptions creep in unnoticed.
Start with the MCP servers in scope and what each one exposes, different servers usually carry different risk. Document privileges, authentication, and integration points. Review the client configuration: a quick read of the config files often reveals hardcoded credentials, insecure endpoints, or scopes that are wider than they should be. Note whether the deployment uses Static Client Registration (SCR) or Dynamic Client Registration (DCR).
Key scoping items:
Number of MCP servers (production, staging, development)
Capabilities each server exposes (tools, APIs, file access, automation, external integrations)
Privilege levels (least privilege vs over-permissioned)
Client configuration (local vs remote)
Configuration file review (hardcoded secrets, insecure endpoints, loose permissions)
Authentication and authorization between client and server
SCR vs DCR
Host environment and what it can access
Third-party MCP integrations and plugins
Profiling the MCP Server and Capabilities
Profiling answers a simple question: what can this thing do, and what can it touch? Enumerate every tool, resource, and predefined prompt the server exposes. For each one, check the privilege level, how input is handled, and how it executes.
Pay close attention to authentication and authorization. Where are tokens stored? How are they passed? Which trust relationships are implicit rather than enforced? Implicit trust is where most MCP problems live.
Then look at the client side. How does it connect, local stdio or remote HTTP? How is session state managed? What stops it from invoking a tool that shouldn't be invoked, or accepting a prompt manipulation that should be filtered?
Threat Analysis
Threats split across three layers, and the assessment should cover each.
The LLM: prompt injection, jailbreaks, model manipulation, and unsafe tool invocation triggered by crafted input.
The MCP server: authentication bypass, privilege escalation, insecure configurations, input validation gaps, and abuse of exposed capabilities.
The tools and resources: data exfiltration, command execution abuse, excessive permissions, and unauthorized access to downstream systems.
Each layer has its own attack vectors, but the interesting findings usually come from combinations, a prompt injection that triggers a tool that has more privilege than it should.
Automated Approach
Automation handles volume. Manual testing handles depth. You need both.
Garak : testing LLM robustness against prompt injection, jailbreaks, and unsafe behaviors.
MCP-Inspector : enumerating servers, listing exposed tools, resources, and prompts, and surfacing obvious configuration weaknesses.
Burp Suite : intercepting client–server traffic, testing authentication flows, manipulating requests, and finding API-layer bugs.
Run the automated pass first to establish a baseline. Then expand into manual exploitation wherever the baseline raises flags.
Manual Approach
Automated tools won't catch chained attacks or contextual logic flaws. That's where manual testing earns its time.
Anchor the work in emerging guidance, the OWASP Top 10 for MCP and adversarial techniques in MITRE ATLAS, but treat them as starting points, not checklists.
Spend real time on the client registration model. SCR and DCR carry different trust assumptions, and weak identity enforcement on either side opens impersonation paths. Test the registration flow itself, not just what happens after.
Then push hard on authorization and session management. Confused Deputy attacks, insecure token passthrough between services, scope enforcement gaps, and session fixation all show up here. If I only had a day to test, this is where I'd spend it.
Report Writing
A good MCP report translates technical findings into business risk. Each issue needs a clear description, the affected components (LLM, server, tool, or resource), a proof of concept, a risk rating, and remediation guidance the team can actually use. Map findings to OWASP or MITRE ATLAS where it fits.
The goal isn't a list of vulnerabilities. It's a deployment that's safer next quarter.
Conclusion
MCP sits in a high-value spot, between an LLM and the systems it can act on, which makes it both useful and dangerous. The protocol itself is solid; most of the risk lives in how it's deployed.
If you're scoping your first MCP assessment, start with two artifacts: an architecture map and a list of capabilities each server exposes. Half of what you'll find usually surfaces from those two alone.