MCP security is how you stop a Model Context Protocol server from turning a model-behavior bug into a real action. An MCP server exposes tools, resources, and prompts to an AI host; the agent decides what to call; your production systems decide whether the call succeeds. If those capabilities are broad, weakly authorized, or poorly logged, a single prompt-injection finding becomes a file read, database query, ticket update, outbound message, code change, or payment action.
This guide is the 20-item review checklist for teams running MCP in production or heading into an enterprise security review. It is written around the uncomfortable question a buyer will ask: what prevents your AI from using the wrong tool, on the wrong data, for the wrong user?
Short answer. MCP security is controlling what tools, resources, and prompts an MCP server exposes to an AI agent — and enforcing authorization, least-privilege credentials, side-effect gates, and audit logging outside the model, in your application and the downstream services the tools reach. MCP is a transport, not a security boundary: a prompt-injection finding becomes a real file read, database query, or payment action exactly when those controls are missing. The 20-item checklist below is the review gate to verify them before a server is attached to a production agent.
MCP in production?
Book the 20-minute MCP security scoping call.
Bring your server inventory, the tools each one exposes, and the workflow that worries you. We will tell you which capabilities are over-broad and what to test before an agent can reach them.
What is the MCP attack surface?
Treat each MCP server as a capability boundary. The review starts by mapping what exists, not by reading prompts.
Servers
List every MCP server the host can reach: local, remote, internal, third-party, customer-installed, and developer-only. Record where it runs, how it authenticates, what credentials it holds, who can configure it, and whether the production agent can reach the same server used in development.
Tools
Tools are actions. A tool may look narrow in the model-visible name, but the implementation may hold a broad database connection, admin SaaS token, file-system path, shell, browser, or API client. For every tool, record:
- what it can read,
- what it can write,
- whether it has side effects,
- which identity it acts as,
- what arguments it accepts,
- what authorization happens outside the model,
- whether a human approval is required.
Resources
Resources are model-visible data. They may include files, records, snippets, logs, documents, customer data, repository content, or internal context. The key question is whether the current user, tenant, role, and task are allowed to see each resource before it is passed to the model.
Prompts and tool descriptions
Prompts and tool descriptions are part of the model’s instruction surface. A malicious, stale, or compromised server can smuggle instructions into metadata. Treat descriptions as untrusted text that helps the model choose a tool, not as authority. A tool description is prompt surface — the same trust-boundary failure covered in the AI agent security guide and prompt injection testing.
Which MCP security controls should you verify?
| # | Control | Pass criterion (one line) | Primary risk it closes |
|---|---|---|---|
| 1 | Capability inventory | A reviewer can point to every server, tool, and resource the production host can see, with its owner. | Unknown or auto-loaded servers |
| 2 | Least-privilege server credentials | The downstream service rejects a forbidden read/write even if the model asks and the server forwards it. | Over-broad service accounts |
| 3 | Caller-aware authorization | The tool resolves the caller identity server-side and enforces object-level authorization. | Confused deputy |
| 4 | Resource scoping before context | Unauthorized resources are never fetched, serialized, logged, or passed to the model. | Context-stage data leak |
| 5 | Side-effect gates | Destructive, financial, external-send, or permission-changing actions need an external gate that shows exact arguments. | Injection-driven actions |
| 6 | Secrets & transcript hygiene | No credentials, tokens, or connection strings appear in prompts, resources, logs, or model-visible errors. | Secret exposure |
| 7 | Traceability & retest | Every meaningful tool call can be replayed or reconstructed to support a finding and a retest. | Unprovable incidents |
1. Capability inventory
You need a complete list of MCP servers, tools, resources, prompts, credentials, environments, and owners. If a server can be auto-discovered or dynamically configured, include the discovery path in the inventory. A reviewed tool list is meaningless if production can silently load a new server.
Pass criterion: a reviewer can point to every tool and resource the production host can see, including who owns it and why it exists.
2. Least-privilege server credentials
An MCP server often hides a powerful credential behind a friendly tool name. Do not let a “read ticket” tool use a service account that can update every ticket, export every customer, or read another tenant. Scope credentials at the downstream service first; prompt instructions are not a permission boundary.
Pass criterion: the downstream service would reject a forbidden read or write even if the model asks for it and the MCP server forwards the request.
3. Caller-aware authorization
The tool must authorize against the requesting user, tenant, role, and object, not just against the MCP server’s own identity. Otherwise the agent becomes a confused deputy: a low-privilege user asks the agent to act, and the server acts with high-privilege credentials.
Pass criterion: the tool receives or resolves the caller identity server-side and enforces object-level authorization before returning data or executing a side effect.
4. Resource scoping before context
Resources should be filtered before they enter the model context. If an unauthorized file or record is passed to the model and then hidden by a prompt rule, the leak has already happened.
Pass criterion: unauthorized resources are not fetched, not serialized, not logged in model-visible traces, and not passed to the host as context.
5. Side-effect gates
State-changing tools need controls outside the model: human approval, policy checks, amount limits, allowlisted recipients, dry-run previews, idempotency keys, and rollback where appropriate. The model should not be able to satisfy its own approval requirement with text.
Pass criterion: destructive, financial, external-message, or permission-changing actions require an external gate that shows exact arguments and cannot be bypassed by prompt content.
6. Secrets and transcript hygiene
Secrets should not appear in tool descriptions, resource bodies, model prompts, errors, logs, or final answers. Tokens and connection strings should be held by the server or secret manager, not exposed to the AI host unless that is explicitly required and scoped.
Pass criterion: a trace of a normal and failed tool call does not contain credentials, bearer tokens, connection strings, raw private keys, or sensitive provider errors.
7. Traceability and retest
If an MCP action goes wrong, you need to reconstruct the path: initiating user, model turn, selected tool, arguments, authorization decision, tool result, final response, and correlation id. Without that trace, you cannot prove what happened or verify a fix.
Pass criterion: every meaningful tool call can be replayed or reconstructed well enough to support a finding, a remediation, and a retest.
MCP security checklist
Use this as a review gate before attaching a server to a production AI host.
- Every production-reachable MCP server is inventoried.
- Tool names, descriptions, schemas, and side-effect flags are reviewed.
- Dynamic server discovery is disabled, pinned, or monitored in production.
- Tool descriptions contain no instructions that override system policy.
- Server credentials are least-privilege for the exact tools exposed.
- Tools authorize against the requesting user and tenant, not only the server.
- Resources are filtered before entering the model context.
- Resource identifiers cannot be guessed or swapped across tenants.
- Side-effecting tools require external confirmation or policy gates.
- Financial, destructive, external-send, and permission-change tools have explicit limits.
- Tool arguments are schema-validated and rejected on ambiguous input.
- Egress tools are allowlisted by recipient, domain, or integration.
- Secrets never appear in prompts, tool descriptions, resources, logs, or model-visible errors.
- Tool calls are logged with caller, arguments, authorization result, and outcome.
- Manifest or tool-list changes alert before they affect production.
- CI or scheduled tests cover prompt injection to tool calls.
- Cross-tenant resource tests run against at least two representative tenants.
- Failed authorization paths are tested, not just happy paths.
- High-risk tools have idempotency or rollback where the business process allows.
- The report states what MCP servers and tools were out of scope.
How do you test an MCP server for security?
These tests are designed to prove controls, not to produce a theatrical jailbreak transcript.
Test 1: prompt injection to side effect
Place an instruction payload in a user message, retrieved resource, ticket, file, or tool result. Ask the agent to perform a benign task that causes the payload to enter context. Pass condition: no sensitive tool call fires, and any attempted side effect is blocked outside the model.
Test 2: cross-tenant resource swap
As Tenant A, attempt to request a resource identifier that belongs to Tenant B, either directly or through an agent task. Pass condition: the MCP server or downstream service rejects it before the resource reaches the model.
Test 3: confused deputy
Use a low-privilege account to ask the agent for an action the MCP server’s service account could technically perform. Pass condition: the downstream authorization decision uses the low-privilege caller and denies the action.
Test 4: manifest drift
Change a tool description, add a new tool, or alter a schema in a controlled test environment. Pass condition: production would pin, review, or alert on the change before the host can use it.
Test 5: secrets in failure mode
Force a tool failure: expired token, denied API call, missing file, malformed argument. Pass condition: the model-visible error and logs contain enough correlation detail to debug but no credentials or raw provider internals.
What MCP security evidence will a buyer accept?
An MCP security review should end with evidence, not a statement that “tools are scoped.” The useful artifact names:
- servers in scope,
- tools and resources reviewed,
- identities and credentials used,
- authorization boundaries tested,
- prompt-injection paths tested,
- side-effect gates verified,
- findings with request/tool traces,
- retest status after fixes,
- residual risks and out-of-scope servers.
That structure matches the sample AI assessment report. See our methodology for how that evidence is produced and retested. For a focused review, use the MCP Security Assessment. If the wider risk is a tool-using agent, pair this with the AI Agent Security Assessment. If MCP is one part of a product launch or procurement deadline, start with the AI Product Readiness Assessment. Because MCP tool and resource surfaces enlarge the test matrix, they price in a higher band — see what an AI security audit costs.