An MCP security review examines the server as a boundary between an AI host and protected business capabilities. The protocol can expose tools, resources, and prompts through negotiated capabilities and structured messages, but a valid protocol exchange does not prove that the caller may read a record, send a message, or change an account. Reviewers must follow the path from advertised metadata through identity, tool arguments, downstream credentials, effects, returned content, and logs.
This procedure complements Edilec's MCP architecture guide, business-system MCP design guide, and audit logging guide. It assumes familiarity with the deployment's transport and trust model. Review the pinned protocol version actually implemented; this article cites the 2025-11-25 MCP specification.
Scope the MCP server, principals, and authoritative effects
Inventory server endpoints, transports, hosting identities, tenants, tools, resources, prompts, notifications, model hosts, authorization servers, downstream APIs, data stores, queues, and observability systems. Name four principals where applicable: initiating user or service, AI host or client, MCP server workload, and downstream resource owner. Document who owns each and which identity is expected in every hop. Shared service credentials can erase user accountability or silently combine privileges across tenants.
For each exposed capability, classify data sensitivity, write authority, reversibility, financial or legal effect, user visibility, idempotency, and maximum scope. Identify the authoritative system that commits the effect. Review test, local, and administrative tools as well as the public catalog; forgotten diagnostic capabilities often have broad access. Draw trust boundaries and data flows, including redirects, webhooks, file staging, caches, and callbacks that do not appear in the tool schema.
| Review surface | Primary question | Evidence | Critical failure |
|---|---|---|---|
| Discovery and initialization | Does the client learn only accurate, allowed capabilities? | Version negotiation, capability config and catalog tests | Hidden or tenant-inappropriate tool is reachable |
| Authorization | Is each token intended for this resource and operation? | Metadata, token validation and negative tests | Token accepted for wrong resource or issuer |
| Tool schema | Can ambiguous or oversized input reach business logic? | JSON schema, bounds and parser tests | Unknown fields or injection reach downstream API |
| Execution | Does domain authorization protect every object and effect? | Policy traces and authoritative API decisions | MCP layer bypasses record-level control |
| Output and logs | Are sensitive data and secrets minimized and traceable? | Response samples, redaction and event schema | Credential or cross-tenant record is returned |
Review discovery, initialization, and version behavior
Test supported protocol versions, capability negotiation, session handling, message-size limits, timeouts, cancellation, and invalid sequence behavior. Reject unsupported or downgraded combinations predictably. Ensure tool lists and descriptions come from an owned release, not mutable unreviewed content. Catalog entries should state consequence and constraints without exposing secrets or manipulating model selection. A renamed tool or schema change is a security-relevant release because clients may select or populate it differently.
Check that discovery is audience- and tenant-aware when capabilities vary. A hidden UI control is not a server restriction. Confirm that notifications do not leak catalog changes across connections and that cached tool lists expire appropriately after revocation. Test duplicate request IDs, malformed JSON-RPC, oversized batches where supported, reconnects, and concurrent sessions. Rate limits should protect both the MCP surface and downstream services while preserving useful error semantics.
Validate OAuth metadata, resource binding, and token handling
Follow the MCP authorization specification for the deployment profile. Verify protected-resource metadata discovery, authorization-server selection, secure redirect handling, PKCE where required, client registration assumptions, scope presentation, and canonical resource identifiers. The server should validate issuer, audience or resource, signature, expiry, not-before, subject, client, tenant, and scopes. Do not accept a token merely because its signature is valid.
Apply OAuth 2.0 Security Best Current Practice to authorization flows, including protections against mix-up, redirect abuse, token leakage, replay, and unsafe grant choices. Never pass an MCP access token unchanged to a different downstream API. Use a workload identity or controlled token exchange to obtain a credential intended for that API, with narrower scopes and short lifetime. Keep tokens out of prompts, model-visible errors, URLs, analytics, and ordinary logs.
Review tool schemas and authorize the exact transaction
Inspect every input schema for strict types, required fields, enums, lengths, numeric ranges, normalized identifiers, URI schemes, file constraints, and rejection of unknown properties. Determine whether descriptions accurately distinguish read, draft, preview, commit, delete, and administrative effects. Avoid polymorphic catch-all payloads that shift parsing into prompts or downstream string templates. Fuzz malformed nesting, duplicate keys, Unicode normalization, boundary values, injection payloads, and references to objects in another tenant.
Authorization must occur after validation and against current state. Evaluate initiating identity, tenant, object, operation, arguments, purpose, approval, cumulative limits, and business invariants at the effect-owning service. Tool-list filtering improves usability but does not replace call-time checks. For dangerous tools, require preview and explicit confirmation from trusted structured fields. Preserve idempotency keys for writes and resolve unknown outcomes before retry. Deny requests whose user attribution or delegation chain cannot be established.
Trace downstream APIs, network egress, and side effects
Review adapters line by line or through equivalent evidence. Identify URL construction, DNS and redirect behavior, TLS validation, proxy use, retries, timeouts, pagination, webhook verification, serialization, and error mapping. Prevent server-side request forgery with destination allowlists and private-network controls. Avoid command or query construction from model-supplied strings; use typed client libraries and parameterized interfaces. A read tool should not call an endpoint with hidden write side effects.
Map partial failure. If the downstream API commits but the MCP response times out, a blind retry can duplicate payments, messages, or records. Require stable operation IDs, idempotent effect owners, reconciliation, and compensating procedures. Verify transaction and rate limits across a sequence, not only per request. The OWASP agentic-threat guide helps broaden review to tool misuse, memory, planning, identity, and multi-agent interactions that can compose individually allowed calls into harmful outcomes.
Control returned content, logs, administration, and incident response
Treat downstream content as untrusted. Minimize fields, preserve provenance, label sensitivity, cap size, sanitize active content before rendering, and prevent errors from exposing stack traces, queries, credentials, or neighboring records. Tool output can contain prompt injection that influences the host's next step; return typed facts where possible and keep policy outside free text. Test cross-tenant reads, inference through error differences, and excessive enumeration.
| Abuse test | Expected control | Evidence to retain | Release blocker |
|---|---|---|---|
| Token for another resource | Reject before business logic | Validation reason without token content | Any successful call |
| User requests another tenant's object | Domain service denies object access | User, tenant, object and policy decision | Record data or existence leak |
| Unknown schema field changes backend query | Strict parser rejects request | Normalized request and validation result | Field reaches adapter |
| Write response is lost then retried | Same operation is returned or reconciled | Idempotency ledger and authoritative ID | Duplicate effect |
| Tool result contains hostile instructions | Content cannot expand authority or trigger action | Provenance, policy decision and next-step trace | Unapproved follow-on tool call |
Logs should reconstruct discovery, session, principal chain, normalized tool call, policy result, downstream operation ID, outcome, latency, and version without storing secrets or excessive content. Restrict administration, signing keys, catalog publication, and configuration change. Monitor denials, unusual enumeration, cross-tenant probes, tool-sequence anomalies, and output volume. Incident playbooks should support token revocation, tool withdrawal, tenant isolation, downstream reconciliation, evidence preservation, customer notice, and safe catalog recovery.
Inspect the MCP server supply chain and deployment boundary
Review source ownership, dependencies, build provenance, artifact signing, vulnerability handling, deployment permissions, configuration secrets, and update channels. For locally installed servers, verify publisher identity, package integrity, filesystem and process access, auto-update behavior, and how users distinguish similarly named packages. For remote servers, inspect tenant isolation, edge controls, administrative access, regional routing, backups, and disaster recovery. Pin dependencies and protocol libraries where practical, then test upgrades against authorization and schema behavior. A secure tool implementation can still be undermined by a compromised package, mutable container tag, overprivileged runtime, or unreviewed catalog release. Ensure rollback removes revoked capabilities from every client cache and active session.
Deliver the review as an actionable risk record. For every finding, identify affected tool or component, exploit preconditions, maximum credible effect, evidence, current safeguards, owner, remediation, retest, and release decision. Distinguish protocol defects from application authorization and deployment weaknesses so fixes reach the right team. Re-run high-risk negative tests after remediation and preserve request and authoritative outcome identifiers. A server should not pass merely because no scanner reported a vulnerability; reviewers need evidence that forbidden principals, objects, arguments, sequences, and downstream destinations are denied under realistic sessions and failure conditions.
Key takeaways for an MCP security review
- Review the full identity and data path from host discovery to authoritative downstream effect.
- Bind access tokens to the intended MCP resource and obtain separate narrow credentials for backend APIs.
- Use strict schemas, call-time object authorization, transaction limits, and domain invariants.
- Treat tool output as untrusted content and preserve provenance without leaking secrets into model context.
- Test retries, cross-tenant access, malformed messages, tool chains, and incident withdrawal before release.
FAQ about MCP server security reviews
Does protocol compliance mean a server is secure? No. Compliance establishes interoperability; deployment, authorization, domain logic, and operations determine security. Can scopes replace record-level authorization? No. Scopes bound classes of action, while current object and tenant policy must decide each transaction. Is local stdio MCP automatically trusted? No; local servers can access files, credentials, and processes, so distribution and execution deserve review. Should every response be logged? Log reconstructable metadata and authoritative IDs, but minimize sensitive content and never log bearer tokens.
Conclusion: assess MCP as a real application boundary
An MCP server may look like a thin adapter, yet it concentrates discovery, delegated identity, model-selected inputs, business APIs, and returned content. A strong review follows each of those responsibilities to its owner and proof. When resource-bound authorization, strict schemas, domain enforcement, bounded credentials, idempotent effects, untrusted-output handling, and useful logs work together, MCP can expose powerful capabilities without becoming a shortcut around the controls that protect them.