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.
MCP control-to-evidence matrix
An MCP security assessment should verify the deployed trust boundaries, not assume that protocol conformance makes a tool safe:
| Boundary | Control assertion | Evidence that can prove or refute it |
|---|---|---|
| Client or host → MCP server | The server accepts only intended callers and server-issued credentials | Client identity, token audience, request, and server decision |
| User or agent → tool | Each sensitive operation is authorized for the current user, tenant, object, and action | Tool arguments, delegated identity, policy check, and downstream response |
| Server → resource | Resources are scoped before their content reaches model context | Resource identifier, owner and tenant metadata, authorization trace, and returned content |
| Content → prompt or tool choice | Untrusted resource text and tool descriptions cannot silently become policy | Source content, assembled context, model turns, and selected capability |
| Model → side effect | Destructive, financial, or external actions require policy or confirmation outside model text | Proposed action, confirmation state, executing identity, and result |
| Operation → audit and retest | A consequential call can be reconstructed and replayed after a fix | Correlated request, model, authorization, tool, result, version, and retest record |
The report should also name every server, client, tool, resource, prompt, identity, and workflow excluded from scope. Unlisted capabilities are residual risk, not an implied pass.
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.
Scope, access, process, and limits
Before testing, we agree the production-reachable MCP server inventory, clients and hosts, manifests, tool and resource schemas, prompts, representative users and tenants, controlled test host, caller and downstream authorization path, environment, and workflow boundaries. You provide controlled access and the tool-call traces needed to reconstruct each tested action; we use least privilege and do not require raw production secrets.
We map the servers, capabilities, identities, and trust boundaries first, validate the test host and evidence path, run the agreed authorization, resource-scope, injection, side-effect, secrets, and traceability tests, produce reproducible findings and a prioritized fix plan, and retest confirmed fixes once.
The assessment applies only to the named servers, clients, manifests, tools, resources, prompts, identities, environments, and workflows. It does not make MCP itself a security boundary or certify the consuming agent as safe. Untested capabilities and later manifest, permission, client, server, or workflow changes remain residual risk.
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. MCP and agent surfaces expand the test matrix, so they price in a higher band — what an AI security audit costs breaks down the drivers. 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.