MCPサーバーを本番環境に接続する前に確認するセキュリティ項目

検証基準：2026年8月27日

確認したMCP Stable Specification：2026-07-28

MCP Serverの本番接続は、LLMへAPIを一つ追加するだけではありません。Toolが顧客データの照会、ファイル変更、メッセージ送信、権限修正、配布を行うなら、MCPは運用システムの権限経路になります。

確認対象はOAuth対応の有無だけではありません。認証したユーザーとTokenの対象Serverを確認します。許可ToolとParameter、高リスク作業の承認者、SecretとTenantの隔離、権限回収も一つのArchitectureにつなぎます。

MCP自体を安全または危険と断定はできません。Host・Client・Serverの通信形式と権限フローを標準化しますが、Protocolだけでは全セキュリティ原則を強制できないと仕様も述べています。安全性はHost方針、Server権限検査、Downstream Credential、運用統制で決まります。

最新MCPで変わった前提

2026年8月27日時点の最新Stable Revisionは2026-07-28です。Modern Protocolは要求ごとにVersionとCapabilityを宣言するStateless構造です。以前のMcp-Session-Idは最新Streamable HTTPに含まれず、受信してもServerは無視します。

状態のセキュリティが不要という意味ではありません。Protocol Sessionがなくても、CartやWorkflowのHandle、OAuth Token、承認記録、Downstream Credentialは残ります。公式指針もHandleの所持を認証とせず、検証済みユーザーへServer-sideで結び、期限を設けるよう求めています。

OAuthの版も分けます。MCPの2026-07-28文書はOAuth 2.1 Draft-13を参照しますが、IETFの現在の草案はDraft-15です。最終RFCではないため、互換という表示よりresource、Audience Validation、PKCE、Issuer Validation、HTTPSの実装を確認します。^[6][7][8]

4つのIdentityを一つに扱わない

本番MCPには少なくとも4種類の主体があります。

公式ArchitectureではHostが複数Clientを管理し、接続権限、方針、ユーザー同意を統制します。各ClientはServerと1対1でつながり、Server間の境界を維持します。保護されたServerはOAuth Resource Server、Clientはユーザーの代理で要求するOAuth Clientです。

AuthenticationとAuthorizationを分離します。

会社アカウントのログインは認証結果です。特定Tenantのデータ参照や本番削除の許可は別判断です。ログインだけを確認してToolを実行せず、要求ごとにPrincipal、Tenant、Scope、Tool、Parameter、対象Resourceを合わせて評価します。^[6][7]

MCP Production Trust Boundary Diagram

[Resource・Prompt・Tool Resultなど信頼しないデータ]

非信頼データ → LLM Context → 作業提案 → Policy＋Authorization＋Approval → 通過時だけ実Tool実行

ここでLLMは作業を提案する主体であり、権限を与える主体ではありません。

ユーザーまたは業務主体

人・Service Account・自動化主体がログインし同意します。

Identity Provider / Authorization Server

ユーザーを認証し、MCP Server A専用Tokenを発行します。最小Scope、短寿命、Step-upを適用します。

MCP Host / Client

許可Serverとユーザー・Role別Allowlistを管理します。Tool・Parameterを表示し高リスクActionを承認し、Server間のCredentialとContextを分けます。

Trust Boundary 1: MCP Server A専用Access Token

resource / audience = MCP Server Aです。Issuer・Audience・期限・有効状態・Scopeを検証します。Principal・TenantをServer-sideで結び、Toolと正規化Parameterを権限検査します。Secret Broker・Audit・失効も担当します。

Trust Boundary 2: 別Downstream Credential

別のDownstream TokenまたはWorkload Identityを使い、Client Tokenを転送しません。

Downstream API / Database / SaaS

自身のResource・Scope・Tenant権限を検査し、Serverを独立Clientとして識別します。

Token AudienceをScopeと混同しない

Scopeは何ができるか、AudienceまたはResourceはどこでTokenを使えるかを制限します。

orders:writeのTokenでも、全注文APIやMCP Serverが受け入れてはいけません。特定Server向けに発行され、そのServerだけで有効であるべきです。

MCP仕様はAuthorization RequestとToken Requestの両方にresourceを含め、対象ServerのCanonical URIを指定するよう求めます。Serverは自分がIntended Audienceかを検証し、他向けTokenを受け入れたり転送したりしてはいけません。

運用では3つの質問に答えます。

Authorization Serverはどのresourceで発行するか？

MCP ServerはAudienceをどう検証するか？

同じTokenを別ServerやDownstream APIへ提示すると確実に拒否されるか？

最後は文書確認だけでなくNegative Testで検証します。

Token PassthroughはProxy実装の近道ではない

ClientのAccess TokenをServerがそのままDownstreamへ渡す方式がToken Passthroughです。最新仕様とSecurity Best Practicesは明示的に禁止しています。

許可すると本来のAudienceを無視し、Downstreamで実呼び出し経路やClient Identityを分けにくくします。Logには別主体が直接呼んだように残り、複数Resourceで再利用すると侵害範囲も広がります。

2つの独立Credentialに分けます。

MCP Client → MCP Server:

MCP専用Token resource / audience = MCP Server

MCP Server → Downstream API:

別途取得したDownstream Token resource / audience = Downstream API

第三者アクセスをユーザーが承認する場合も、CredentialをMCP Clientへ通してはいけません。Elicitation仕様はServerをユーザーが直接承認し、ServerがDownstream Tokenを保存管理するよう求めます。Protocol CoreがStatelessでも、外部連携のCredential Storeは状態を持ちます。^[7][8]

最小権限はScope一つで終わらない

read・write・adminを設けるだけでは最小権限は完成しません。少なくとも4段階のGateが必要です。

公式指針は全Scopeの初期発行より、低権限で始め、必要な作業の初回だけ最小Scopeを求めるProgressive Scope Modelを勧めます。不足時は403と正確なScope Challengeを返せます。

Tool AllowlistはServerとユーザーで変える

Serverが公開する全Toolを、全ユーザーとAgentへ自動提供してはいけません。

少なくとも次の単位で管理します。

許可したMCP Server

ユーザー・Role・Tenant別のTool

Development・Staging・Production別のTool

照会・変更・削除・外部送信などのAction

対象Resourceと最大作業量

自動実行か承認必須か

Tool名は全体で一意なSecurity Identityではありません。一意性はServer内部だけで、Server名も重複し得ます。delete_fileや表示名ではなく、信頼したServer IdentityとTool IDの組み合わせで方針を管理します。

JSON Schema検証と権限検査は別作業

inputSchemaはParameterの構造と形式を定義します。通過は形が正しいことを示すだけで、その値へのアクセス権を意味しません。

たとえば次がSchema上有効でも：

{ "tenant_id": "tenant-b", "record_id": "1234", "action": "delete" }

呼出者がtenant-bに所属しなければ拒否します。

Parameterは次の順で検査します。

形式と必須値の検証

Encoding・Path・Identifierの正規化

許可値と範囲の確認

PrincipalとTenantのResource所有関係

業務規則と現在状態

大量作業・外部送信・高リスクActionの評価

承認条件の確認

実行直前の権限再検証

Tool仕様も全入力検証、Access Control、Rate Limit、Output Sanitizationを要求します。Clientには機密作業の確認、呼出前の入力表示、LLMへ渡す前の結果検証、Audit記録を勧めています。^[6][7]

Human Approvalは権限検査を代替しない

確認ボタンを押しても、許可されない作業が許可済みになるわけではありません。

承認はServer-side Authorizationを通過した後、業務影響と意図を確認する追加Gateです。無権限の要求は承認画面の前に拒否します。

Action Risk別の承認基準

高リスク承認は次の値に結びます。

MCP Server

Tool

正規化したParameter

TenantとEnvironment

予想影響

承認ユーザー

短い期限

単一実行または明確な作業範囲

承認後にLLMがParameterを変更して再呼出するなら、以前の承認を再利用してはいけません。^[6]

Prompt InjectionとTool Useに強制境界を置く

文書・メール・Web・Tool Resultなどの非信頼データが判断に影響する問題がPrompt Injectionです。攻撃者は別Toolで内容を外部送信せよという指示を埋め込めます。

モデルの提案と、実システムによる許可を分けます。

非信頼データ

→ モデルのTool Call提案

→ Tool Allowlist → Server-side Authorization → Parameter Validation → 必要時のHuman Approval → 実行

Annotationも代替にはなりません。公式資料はAnnotationがInjection耐性を作らないと説明しています。非信頼ServerはreadOnlyを偽装でき、Annotation自体はEnforcementではありません。強い保証にはHost Policy、Server-side Access Control、Network Control、Sandboxが必要です。Model Context Protocol Blog

特に次の組み合わせは別方針で遮断するか、承認水準を上げます。

非公開データを読める

信頼しない外部コンテンツを読む

外部システムへ送信または変更できる

機密情報を送るなとモデルへ指示するだけでは制御できません。

Secret境界はPromptの外に置く

API Key、Refresh Token、Database Credential、Signing KeyをPrompt、Tool Description、通常Argumentへ入れてはいけません。

推奨境界は次のとおりです。

ClientはMCP Server専用Tokenだけを持つ

ServerはSecret StoreからDownstream Credentialを取得

Credentialはユーザー・Tenant・Integrationに結んで保存

Toolは実CredentialでなくReferenceかServer-side接続を使う

Token・SecretをLog・Error・URL・Tool Resultへ含めない

CredentialアクセスとTool実行の権限を別管理

第三者認可でもTokenはServerが管理しClientへ渡しません。Elicitation URLにはCredentialや個人情報を含めず、事前認証済みURLも渡してはいけません。^[6]

Local stdio Serverには別のリスクモデルがある

仕様上HTTP Authorizationは任意機能で、stdioは同じOAuthフローでなく環境からCredentialを得ます。ただしLocal Serverが信頼済みという意味ではありません。

Clientと同じユーザー権限で動く可能性があります。設置前に実Commandを示し、Filesystem・Networkを制限してSandboxと最小権限を使います。公式指針もOne-click設定で正確なCommand表示、明示承認、File・Network制限を求めます。^[7][8]

Tenantをモデルの送る値で決めない

マルチTenantで特に危険なのは、Argumentのtenant_idをそのまま信頼する設計です。

検証したServer-side根拠で決めます。

認証ユーザーとTenant Membership

Authorization Grant

Server-side Policy Mapping

接続したDownstream Account

Workload Identityと配布環境

ArgumentのTenantやProject IDは対象選択値にすぎず、呼出者がアクセス可能かを再確認します。

Cache、Handle、Downstream Token、承認にも同じ原則を使います。ユーザーとTenantを結ばない全体Keyは避けます。

悪い状態Key:

workflow:1234

推奨構造: tenant-a:user-42:workflow:1234

最新MCPにはProtocol Sessionがなくても、複数要求をまたぐWorkflow Handleは通常Argumentで渡せます。所持を認証とせず、検証ユーザーへServer-sideで結び、期限を設けます。^[8]

Credential LifetimeとRevocationを合わせて設計する

短寿命は流出被害を減らしますが失効を代替しません。逆に失効Endpointがあっても、古い権限結果を長くCacheすれば即時遮断できない場合があります。

MCPは短いAccess TokenとPublic ClientのRefresh Token Rotationを要求します。RFC 7009はAccess・Refresh Tokenの失効Endpoint、RFC 7662はActive・Expired・Revoked状態と権限Metadataの照会を定義します。

退職、Tenant移動、連携解除、事故時には次をまとめて処理できる必要があります。

ユーザーとMCP Server間のGrant失効

MCP Refresh・Access Token無効化

Server保有Downstream Grantの失効

ToolとTenant Policyの除去

State Handleと未使用承認の無効化

Server接続またはClient Registrationの停止

進行中の高リスク作業の取消

まもなく期限切れになるからと、失効経路を省いてはいけません。^[8]

AuditはPrompt全体を保存する作業ではない

このAuditはAgent Observabilityと目的が違います。Model Latency、Retrieval時間、Token量、Retry分析はTopic 020の範囲です。MCP Security Auditは権限判断と実Side Effectの再構成に集中します。

最低限、次を記録します。

検証したユーザーまたはService Principal

TenantとEnvironment

Server IdentityとAuthorization Server Issuer

Protocol Version

Tool IDとVersion

正規化ParameterのRedacted SummaryまたはHash

要求Scopeと実付与Scope

Audience・Token検証結果

適用Policy Version

Allow・Deny・Step-up判断

承認主体・時刻・範囲

Downstream ResourceとAction

実行結果とError

Credential・Grant・Server失効イベント

Tool一覧と権限設定の変更

一方、次は基本Auditから除外するか別の保護Storageへ分けます。

Access・Refresh Token原文

API KeyとSecret

Prompt・Completion全体

機密Tool Result全体

個人情報を含む原Parameter

認証済みURLやCredential Reference

仕様も利用記録を勧めますが、何を残すかは別のデータ最小化方針が必要です。^[6]

Server Trustを名前や説明で決めない

clientInfoは自己申告値であり、セキュリティ判断に使えません。Annotationも信頼したServer由来でなければ信頼できず、Server名も全体で重複し得ます。

Trust Recordには最低限、次を残します。

運用・配布主体

Remote EndpointまたはLocal Packageの正確な識別子

Package Version・Digest・Signature

Authorization Server Issuer

許可Redirect URIとClient Registration方式

公開Tool・Resource・Prompt一覧

Filesystem・Network・Downstreamアクセス範囲

データ保存・保持・削除方針

Update Channelと自動更新の有無

Security連絡先とIncident経路

接続停止・除去手順

Tool一覧変更では画面更新だけで終わらず、新Toolと既存Toolの権限・Risk差分を確認します。^[6]

第三者MCPは別Trust Domainとして扱う

人気より、次を確認してから外部Serverを接続します。

Remote Server

Endpointと運用主体は確認できるか

Issuerは期待値と一致するか

Client Credentialを別Authorization Serverと共有していないか

Discovery URLが内部IP・Cloud Metadata・Localhostを指すことを防げるか

ToolとScopeは目的より広くないか

どの地域とシステムへデータを保存するか

Tool・権限・規約の変更を検出できるか

即時停止のKill Switchはあるか

ClientはServer別にRegistration State、Credential、Tokenを分けます。Metadata Discoveryには内部やCloud Metadataへ向かうSSRFリスクがあります。HTTPS強制、Private・Reserved IP遮断、Redirect再検証、Egress制御が必要です。

Local Server

Package SourceとPublisherを確認したか

実CommandとArgumentをレビューしたか

自動更新で実行内容が変わるか

Home・SSH Key・Browser Profile・環境変数へのアクセスが必要か

外部Network Egressが必要か

Sandboxまたは別OS Userで動かせるか

除去後にCredentialやStateが残らないか

Local Serverは設置ファイルではなく、ユーザー権限で動くCodeです。Discoveryや便利な設置をTrust Approvalと見なしてはいけません。^[8]

MCP Production Security Checklist

一つでも明確に答えられなければ、全権限を一度につなぐ前にRead-only Sandboxか限定Tenantで検証します。

VersionとTransport 1

本番ClientとServerの対応Revisionを記録しました。

VersionとTransport 2

Modern Protocol 2026-07-28とLegacy Session版を区別しました。

VersionとTransport 3

HTTP要求ごとにVersionを検査し、不一致を拒否します。

VersionとTransport 4

Streamable HTTP ServerがOriginを検証します。

VersionとTransport 5

Local HTTPは既定でLocalhostか制限IPCだけにBindingします。

VersionとTransport 6

stdioが継承する環境変数とOS権限を確認しました。

Server Trust 1

許可EndpointとPackageをAllowlistで管理します。

Server Trust 2

表示名や自己申告serverInfoをSecurity Identityに使いません。

Server Trust 3

Remote運用主体、Domain、TLS、Issuerを確認しました。

Server Trust 4

Localの正確なCommand、Package Version、Digestをレビューしました。

Server Trust 5

Server・Tool一覧変更時に再承認かRisk Reviewを行います。

Server Trust 6

即時接続遮断のKill Switchがあります。

AuthenticationとAuthorization 1

ユーザーやService Principalを検証する認証境界があります。

AuthenticationとAuthorization 2

Serverが要求ごとにTokenを検証します。

AuthenticationとAuthorization 3

ユーザー認証とTool実行権限を分離します。

AuthenticationとAuthorization 4

Principal・Role・Tenant MappingをServer-sideで管理します。

AuthenticationとAuthorization 5

不足権限は401と403を分けて拒否します。

AuthenticationとAuthorization 6

低権限から始め、必要なActionだけStep-upします。

Token AudienceとPassthrough 1

AuthorizationとTokenの要求にServerのresourceを送ります。

Token AudienceとPassthrough 2

自身がIntended AudienceのTokenだけを受け入れます。

Token AudienceとPassthrough 3

別APIやServerのTokenを使うNegative Test要求は失敗します。

Token AudienceとPassthrough 4

TokenをQuery StringやTool Parameterで渡しません。

Token AudienceとPassthrough 5

Client TokenをDownstreamへ転送しません。

Token AudienceとPassthrough 6

Downstreamには別TokenかWorkload Identityを使います。

Token AudienceとPassthrough 7

Authorization Server別にCredentialとToken Storeを分けます。

ToolとParameter Policy 1

ユーザー・Role・Tenant・Environment別Allowlistがあります。

ToolとParameter Policy 2

モデルが選んだだけではToolを実行しません。

ToolとParameter Policy 3

全InputをSchemaと業務規則で検証します。

ToolとParameter Policy 4

Identifier・Path・URL・数量・日付を正規化してから権限検査します。

ToolとParameter Policy 5

ArgumentのTenant・Project IDをそのまま信頼しません。

ToolとParameter Policy 6

対象Resourceが呼出者のTenantに属するか確認します。

ToolとParameter Policy 7

大量作業・外部送信・反復呼出に別Limitを設けます。

ToolとParameter Policy 8

Outputを整形・検証してからLLM Contextへ渡します。

ToolとParameter Policy 9

Annotationは信頼したServerのHintとしてだけ使います。

Human ApprovalとHigh-impact Action 1

高リスクAction一覧とOwnerが定義されています。

Human ApprovalとHigh-impact Action 2

承認画面にTool・対象・Parameter・予想影響を示します。

Human ApprovalとHigh-impact Action 3

承認前にServer-side Authorizationを完了します。

Human ApprovalとHigh-impact Action 4

正確なTool・Parameter・Tenant・Environmentに承認を結びます。

Human ApprovalとHigh-impact Action 5

Parameter変更後は再承認します。

Human ApprovalとHigh-impact Action 6

削除・権限変更・本番作業・決済・大量Exportは要求ごとの承認対象です。

Human ApprovalとHigh-impact Action 7

必要なActionに再認証、Scope Step-up、二重承認を適用します。

Human ApprovalとHigh-impact Action 8

自動実行と人の承認が必要なActionを文書化しています。

Prompt Injection Boundary 1

Resource・Prompt・Tool Resultは既定で非信頼入力です。

Prompt Injection Boundary 2

LLM Tool Callは命令でなく提案として扱います。

Prompt Injection Boundary 3

Prompt内の指示はAllowlistや権限方針を変えられません。

Prompt Injection Boundary 4

非公開データ照会後の外部送信では承認水準を上げます。

Prompt Injection Boundary 5

モデル指示でなくHost・Server・Network方針でExfiltrationを制御します。

Prompt Injection Boundary 6

非信頼コンテンツを含む実行経路をAuditで識別できます。

SecretとTenant Isolation 1

SecretをPrompt・Description・URL・通常Argumentへ入れません。

SecretとTenant Isolation 2

Downstream TokenをServerの保護Secret Storeに保存します。

SecretとTenant Isolation 3

Tokenをユーザー・Tenant・Integration単位で分けます。

SecretとTenant Isolation 4

別TenantのCache・State・Credentialは参照できません。

SecretとTenant Isolation 5

State Handleを認証手段にしません。

SecretとTenant Isolation 6

HandleをユーザーとTenantに結び、期限を設けます。

SecretとTenant Isolation 7

ErrorやAuditにToken・Secretを含めません。

LifetimeとRevocation 1

Access Tokenを不必要に長期間有効にしません。

LifetimeとRevocation 2

Refresh Tokenを機密保存し、必要時にRotationします。

LifetimeとRevocation 3

ユーザーGrantとDownstream Grantに各失効経路があります。

LifetimeとRevocation 4

Server・Tool・Client Registrationを即時停止できます。

LifetimeとRevocation 5

退職・Tenant移動・接続解除時の自動失効手順があります。

LifetimeとRevocation 6

権限Cache時間は失効目標を超えません。

LifetimeとRevocation 7

Handleと未使用Approvalも同時に無効化します。

LifetimeとRevocation 8

進行中の高リスク作業を取消・遮断できます。

AuditとIncident Response 1

Allow・Deny・Step-up・Approval・Revocationを記録します。

AuditとIncident Response 2

ユーザー・Tenant・Server・Tool・Policy Version・結果を結ぶ記録があります。

AuditとIncident Response 3

ParameterをRedactionかHashで記録します。

AuditとIncident Response 4

通常LogへToken・Secret・機密Prompt全体を残しません。

AuditとIncident Response 5

ToolとScopeの変更履歴を保ちます。

AuditとIncident Response 6

異常呼出量・反復失敗・Cross-tenant試行を検出します。

AuditとIncident Response 7

Credential流出時に失効するGrantとDownstream接続を示すRunbookがあります。

AuditとIncident Response 8

事故後に実Side Effectを再構成する記録があります。

接続を保留する条件

次のどれかがあれば本番接続を保留します。

ServerがToken Audienceを検証しない。

Client TokenをそのままDownstreamへ渡す。

全Toolを全ユーザーに公開する。

TenantをPromptやArgumentだけで決める。

高リスク作業をモデル判断だけで自動実行する。

SecretがPrompt・Argument・Logに入る。

第三者の運用主体と実行権限を確認できない。

Credentialと接続を失効する経路がない。

結果をユーザー・Tenant・承認に結べない。

接続成功より拒否成功を試験する

接続してToolを呼べるだけでは、検証の半分も終わりません。

本番前に次が確実に失敗するかを試験します。

別AudienceのToken

期限切れ・失効Token

Scope不足Token

許可しないTool

別TenantのResource ID

承認後にParameterを変更した要求

別ユーザーのState Handle

許可しないDownstream Destination

停止したServerとClient Credential

本番接続の基準はAgentが作業できるかではありません。

誤ユーザー・Token・Tool・Parameter・Tenant・承認では実行できず、付与済み権限を素早く回収し、過程をAuditで再構成できるかです。

答えられるとき、MCPは接続機能に加えて、統制可能な運用権限経路になります。