MCP makes it easier to connect AI systems to tools and context. That also makes it easier to expose the wrong capability to the wrong model, user, tenant, or workflow. An MCP server can become a high-trust bridge into files, databases, SaaS APIs, code, tickets, billing, internal docs, or operational systems. The question is not whether the protocol works. The question is whether the capabilities it exposes are bounded, authorized, logged, and safe to use from an LLM-driven workflow.
This assessment reviews MCP systems as production attack surface: servers, tools, resources, prompts, clients, agent flows, authorization, and evidence.
Who it is for
You are using or building MCP servers for an AI product, internal copilot, developer tool, operations agent, research assistant, customer-support system, or enterprise integration. The MCP server may be internal-only, customer-deployed, or part of a SaaS feature. If an LLM can reach it, a reviewer will eventually ask what prevents unsafe tool use and data exposure.
What we test
Server and capability inventory
We enumerate MCP servers, exposed tools, resources, prompts, argument schemas, required credentials, and deployment boundaries. The first risk is often simple: the agent can see more capabilities than the user or task needs.
Tool permissions and authorization
Every state-changing or sensitive tool needs authorization outside the model. We test whether the MCP layer and downstream services enforce user, tenant, role, object, and business-policy checks. Prompt instructions are not a substitute for server-side checks.
Resource exposure
MCP resources can expose files, records, snippets, logs, or internal context. We test whether resources are scoped correctly, whether identifiers can be guessed or swapped, and whether one tenant or role can read another’s material.
Prompt and context injection
MCP systems can carry prompt templates, tool descriptions, resource text, and external content into the model. We test whether untrusted content can influence tool use, bypass policy, reveal hidden context, or turn a resource into an instruction channel.
Secrets and deployment posture
We inspect how credentials are stored, passed, rotated, and logged; whether servers run with least privilege; whether local and remote MCP deployments make different trust assumptions; and whether dangerous operations are isolated.
Auditability and retest
For every meaningful tool call, you should be able to reconstruct the initiating user, model turn, arguments, authorization decision, tool result, and final response. We test whether that evidence exists and can support remediation and retest.
What you get
- A map of MCP servers, clients, tools, resources, prompts, identities, and trust boundaries.
- Reproducible findings with request, context, and tool-call evidence.
- Severity tied to data exposure, unauthorized action, privilege escalation, or procurement risk.
- A fix plan for capability scoping, authorization, resource handling, secrets, and logging.
- One retest pass after the agreed fixes.
Controls we expect to verify
Strong MCP deployments usually have these properties:
- Narrow tools with explicit schemas and no hidden broad privileges.
- Server-side authorization for every sensitive read or write.
- Tenant and role scope enforced before resources enter the model.
- Secrets kept out of prompts, logs, and model-visible context.
- Destructive actions gated by external confirmation or policy.
- Complete traces for model decisions and tool calls.
- An eval or regression set for prompt injection and tool-abuse cases.
We verify those controls against your implementation and report the exact gaps.
Where this fits
MCP security overlaps with agent security. If the main risk is a tool-using agent, review the AI Agent Security Assessment. If the MCP servers and exposed capabilities are the focus, read the MCP security guide and then scope an MCP security assessment. For a wider product review that includes red-teaming, evals, and production-readiness, start with the AI Product Readiness Assessment. The sample report shows how MCP evidence is packaged, our methodology explains the test process, trust and data handling defines access, confidentiality, and retest boundaries, and the public verification profile collects proof links a buyer can inspect before signing.