How to secure an MCP server in a SaaS product
Secure SaaS MCP servers with caller authentication, per-tool authorization, input validation, tenant isolation, audit logs and current-protocol guidance.
In this guide
How do you secure an MCP server?
Secure a Model Context Protocol (MCP) server as a privileged API boundary. Authenticate the calling identity, authorize each tool and resource for the current user and tenant, validate every argument, constrain downstream effects, and record a privacy-conscious audit trail. MCP standardizes how clients discover and invoke capabilities; it does not decide whether a caller should be allowed to read a particular customer's record or approve a consequential action. The final 2026-07-28 protocol removed protocol-level stateful sessions, so application authorization must not depend on a legacy session identifier.
Inventory tools, resources and downstream effects
List each exposed tool, resource and prompt; identify its data classification, tenant scope, downstream API, side effect and owner. Describe what a tool can actually do in plain language, including indirect effects such as sending email, exporting a report or changing a billing setting. Remove unused capabilities and make read-only operations distinct from writes. A name or schema is not a security review.
Put authentication and authorization in trusted server code
Validate the OAuth access token for the intended resource, issuer, audience, expiry and required scopes. Bind the authenticated principal and tenant to server-side request context; never accept a model-generated tenant ID, user ID or permission claim as proof. Apply object-level authorization again when the tool accesses a record, because permission to invoke a tool does not imply permission to access every object it can address.
Keep privileged approvals outside the model
Require an explicit, informed confirmation for high-impact operations such as external sharing, payments, account deletion or permission changes. Show the user the exact target and effect before confirmation, then re-check authorization and policy at execution time. A prompt saying “ask first” is not an approval control, and an approval for one action should not silently authorize a later or broader action.
| Tool/resource | Data and tenant scope | Read/write effect | Required identity/scope | Approval and audit |
|---|---|---|---|---|
How should an MCP server validate requests and isolate tenants?
Treat tool arguments and returned content as untrusted
Validate types, lengths, enumerated values, identifiers and cross-field rules against a strict schema, then apply business validation in the underlying service. Use parameterized database operations and safe output handling. Tool descriptions help a model choose a capability; they do not sanitize arguments or make returned text trustworthy. Reject malformed or over-sized requests rather than trying to repair them silently.
Carry tenant context from verified identity to every data operation
Derive tenant scope from the authenticated principal or a trusted server-side mapping. Enforce it in the service and data layer, including searches, pagination, caches, background work and error paths. Test that a guessed identifier, stale reference, batch request or resource URI cannot cross tenant boundaries. Re-check authorization on each call; do not treat prior discovery or a previous tool result as continuing permission.
Constrain outbound connections and server privileges
Allowlist downstream hosts, methods and operations; block arbitrary URL fetches and internal metadata addresses. Use a dedicated service identity with only the permissions required by each capability, store credentials in a managed secret system, and rotate or revoke them through a tested process. Apply request, response, concurrency and time limits so a valid-looking tool call cannot exhaust the server or a downstream dependency.
How do you operate and test a secure MCP server?
Use current protocol authorization rules and safe deployment defaults
Follow the current MCP authorization specification for the transport and client you support, including issuer and resource validation. Do not copy older examples that rely on a protocol-level stateful session identifier: the 2026-07-28 final specification removed that mechanism. Keep any application-level actor, tenant and correlation identifiers separate from authentication credentials, and never use correlation data as authorization evidence.
Log decisions without copying customer content into logs
Record authenticated actor and tenant references, tool name, authorization outcome, policy version, request correlation ID, time, result status and downstream trace IDs. Minimize or redact arguments and outputs that may contain personal or confidential data; restrict log access and set retention. Ensure a security reviewer can reconstruct who initiated an action and what happened without making a broad transcript archive.
Test negative cases and revoke access quickly
Exercise expired, wrong-audience and wrong-issuer tokens; missing scopes; cross-tenant IDs; malformed arguments; replayed requests; hostile resource text; timeout and partial failure paths; and denied high-impact actions. Verify revocation and credential rotation, then test that incidents can disable a tool or client without taking unrelated service features offline. Re-run these checks when schemas, tools, providers or protocol versions change.
MCP server security FAQs
Does MCP authorization protect every tool call automatically?
No. MCP provides protocol mechanisms, but the server still needs to authenticate the caller and enforce authorization for each capability, object, tenant and consequential action.
Should an MCP server trust a tenant ID supplied in tool arguments?
No. Derive tenant context from verified identity and trusted server-side records. Treat any model- or client-supplied tenant value as an untrusted selector and verify it against the caller's permissions.
Does the current MCP protocol use a stateful session ID for authorization?
The final 2026-07-28 MCP specification removed protocol-level stateful sessions. Keep application correlation or workflow state only where your design needs it, and do not treat it as proof of identity or permission.
Can a model safely run a write tool after it recommends the action?
A recommendation is not user consent. For consequential operations, show the exact action to an authorized person, obtain explicit confirmation, and re-check policy immediately before execution.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- OWASP Top 10 for Agentic Applications 2026OWASP Gen AI Security Project
- A Practical Guide for Secure MCP Server DevelopmentOWASP Gen AI Security Project
- The MCP Protocol 2026-07-28 releaseModel Context Protocol
- OWASP Cheat Sheet: AuthorizationOWASP Foundation
- OWASP Server-Side Request Forgery Prevention Cheat SheetOWASP Foundation
- OWASP Cheat Sheet: LoggingOWASP Foundation
- AWS SaaS Lens: Testing multi-tenant SaaS reliabilityAmazon Web Services
- LLM05:2025 Improper Output HandlingOWASP Gen AI Security Project
- LLM10:2025 Unbounded ConsumptionOWASP Gen AI Security Project