MCP Security
Make the MCP server a bounded production integration, not a trust shortcut.
30 minutes. Bring the evidence, trace, or deadline.
This page is for
- Platform teams shipping remote MCP servers for customers or internal automation
- Security engineers reviewing OAuth, tool scopes, and downstream service access
- AI product leaders who need an MCP launch gate and an evidence-backed retest plan
Start here
The short answer
Direct answer
An MCP security assessment examines the server and its tools as a privileged integration boundary. It validates audience-bound authentication, tenant-aware authorization, tool schemas, command and URL handling, audit events, idempotency, rate limits, and the behavior of a client that sends malformed or adversarial input.
Search intent this page serves: You are moving an MCP server from internal experiment to customer-facing or multi-tenant production and need evidence that tools cannot exceed their declared scope.
System boundary
What the assessment follows
The assessment starts with the real trust boundaries. Every included surface has a corresponding scenario, evidence expectation, or retest condition.
Representative flow
- Client request → transport and token validation → tenant/session context
- Tool discovery → scope and side-effect policy → argument validation
- Validated tool call → downstream resource authorization → result sanitization
- Result and audit event → client response, monitoring, revocation, or recovery
Risk and controls
The control matrix is specific to this system
A finding is useful only when the team can locate the control, observe the failure, name the evidence, and decide what happens next.
| Surface | Failure or risk | Control to inspect | Evidence | Priority |
|---|---|---|---|---|
| Token audience and issuer | A token minted for another service or environment is accepted by the MCP server. | Validate issuer, audience, signature, expiry, client, tenant, and environment before session or discovery. | Token rejection tests, issuer configuration, key rotation record, and auth logs. | Critical |
| Tool authorization | Tool discovery or model-generated arguments bypass the user’s tenant, scope, or resource permissions. | Derive scope from the authenticated principal and authorize every call against the downstream resource. | Tool policy, scope matrix, denied calls, and resource-level authorization trace. | Critical |
| Command and URL handling | Untrusted tool arguments reach a shell, filesystem, internal URL, or arbitrary network destination. | Use typed allowlisted operations, destination controls, argument validation, and isolated execution. | Malicious argument cases, egress policy, shell absence or sandbox, and blocked request logs. | Critical |
| Tenant isolation | A long-lived session, cache, or server process retains context or credentials across tenants. | Bind context and credentials per request or isolated session; clear state and test reuse explicitly. | Session lifecycle, cache policy, cross-tenant replay, and teardown logs. | High |
| Audit and recovery | A tool side effect cannot be attributed, repeated safely, or reversed after a timeout. | Log actor, tenant, tool, arguments hash, target, decision, outcome, correlation ID, and idempotency key. | Audit event samples, retry drill, reconciliation report, and kill-switch runbook. | High |
| Operations | A vulnerable tool or client remains active because revocation and rate limiting are unclear. | Version tools, expire sessions, rate-limit by principal and tenant, and provide a tested disable path. | Revocation test, rate-limit alert, release record, and incident contact matrix. | Medium |
Reproducible testing
Scenarios that exercise the boundary
These cases are intentionally concrete. They can be run in a production-adjacent environment with synthetic data and become regression fixtures after remediation.
Wrong-audience token acceptance
- Precondition
- The server trusts an OAuth issuer shared by multiple services or environments.
- Exercise
- Present valid tokens with the wrong audience, environment, client, tenant, and expiry combinations.
- Expected control
- Only tokens intended for this server, environment, client, and tenant reach discovery or tool execution.
- Evidence captured
- HTTP decisions, auth configuration, key/issuer metadata, and security event logs.
Tool scope escalation
- Precondition
- A client can discover tools and the model constructs arguments for a resource operation.
- Exercise
- Request a permitted read while mutating tool names, resource IDs, tenant IDs, scopes, and role claims.
- Expected control
- The server ignores model-provided authority and enforces resource authorization for the authenticated principal.
- Evidence captured
- Tool manifest, policy decision, denied call, downstream audit, and response body.
SSRF or command injection through a tool
- Precondition
- A tool accepts a URL, path, command-like string, or remote content location.
- Exercise
- Supply internal IPs, metadata endpoints, shell metacharacters, encoded paths, and redirect chains.
- Expected control
- The operation is rejected or runs in a constrained sandbox with allowlisted destinations and no secret exposure.
- Evidence captured
- Request traces, egress decision, sandbox result, and synthetic-secret canary.
Timeout and duplicate side effect
- Precondition
- A tool writes to an external system and the client retries after an ambiguous timeout.
- Exercise
- Delay the downstream response, retry with the same and changed payload, then revoke the session mid-flight.
- Expected control
- The operation is idempotent, state is reconciled, revoked calls stop, and the audit trail shows the outcome.
- Evidence captured
- Idempotency key, downstream request IDs, revocation event, and reconciliation result.
Scope and handoff
What the team receives, and what access is needed
The fixed scope is designed to leave behind implementation artifacts, not a report nobody can rerun.
Deliverables
- MCP transport, identity, session, and downstream trust-boundary map
- Tool manifest and authorization matrix with side-effect classifications
- Token, scope, injection, tenant-reuse, and retry scenarios
- Production readiness checklist for audit, rate limits, revocation, and kill switch
- Priority implementation changes with negative tests and evidence links
- Retest report for the exact MCP server version and deployment boundary
Access requirements
- MCP server configuration, tool manifest, transport, and deployment topology
- Test client credentials for normal, admin, expired, and wrong-audience cases
- Sandboxed downstream resources or dry-run modes for side-effect tools
- Read-only access to audit events, rate limits, and revocation configuration
- Owners for authentication, tool implementation, and incident response
Day 1
Server boundary
Inventory transport, issuer, audience, session, tenant, tools, downstream systems, and deployment isolation.
Days 2–3
Control inspection
Review token validation, tool scopes, schemas, egress, audit fields, rate limits, revocation, and retries.
Days 4–5
Preflight scenarios
Run wrong-audience, scope escalation, injection, tenant reuse, and ambiguous-timeout cases.
Day 6
Launch decision
Deliver pass/conditional/fail results, fixes, negative tests, and the versioned retest gate.
Retest and limitations
How the result stays current
Rerun the full Critical suite for changes to token validation, tool authorization, command/URL handling, or tenant/session state. Rerun affected High cases after tool schema, downstream API, retry, audit, or deployment changes. Keep the server version and client version in every retest record.
Scope limit
The assessment covers the MCP server and its declared downstream boundary, not every MCP client or host application.
Scope limit
A clean tool manifest does not prove the implementation is safe; runtime negative tests are required.
Scope limit
This is not a protocol certification, formal penetration test, or compliance certification.
Sources and limits
References used for the operating model
These sources provide the framework or vocabulary. The page adds product-boundary tests, evidence requirements, and implementation decisions so the result can be inspected in a live system.
Use it to structure MCP-specific cases around command injection, confused-deputy behavior, authorization, and supply chain risk.
Provides a threat-model-based reference for autonomous systems, tool use, planning, and multi-agent behavior.
FAQ
Questions buyers and engineers ask
What makes an MCP security assessment production-focused?
It tests authentication, authorization, tenant/session lifecycle, egress, side effects, auditability, rate limits, revocation, and recovery around the actual server deployment. It does not stop at inspecting tool descriptions.
Do you test the client too?
The agreed scope includes client behavior where it affects the server boundary, such as discovery, malformed calls, retry, and token presentation. A separate client or host review is recommended for client-side secrets and UI behavior.
Can a server pass if a tool relies on model refusal?
No. Model refusal can reduce accidental misuse, but the server must enforce identity, scope, resource authorization, validation, and side-effect constraints independently.
Next step
Turn this page into an owned engineering decision.
Bring the questionnaire, trace, failed workflow, or provider deadline. We will help decide whether a focused implementation is the right scope.
30 minutes. No deck. Leave with a clear next step.