MCPサーバーに認証がない問題、Prometheus連携で何が起きるか

Claude DesktopやCursorからPrometheusやGrafanaを操作できるMCPサーバーを社内基盤に立てている、あるいはこれから立てる予定があるインフラ担当者に向けた内容です。MCP（Model Context Protocol、AIエージェントが外部ツールやAPIに接続するための通信規格）には、実は認証・認可・監査ログの仕組みが規格として定義されていません。この空白部分がオンプレ由来の監視基盤をクラウドやAIエージェント経由で操作可能にした瞬間、思わぬ運用リスクに変わります。

何が起きるか

Prometheus、Grafana、Gitea、Ollamaなどを自宅サーバーやオンプレ環境で運用し、それぞれにMCPサーバーを立てるケースを考えます。典型的な実装はサービスごとにFastMCP（Python製のMCPサーバー実装ライブラリ）で数十行のコードを書き、APIキーをハードコードしてツールを登録するというものです。

この構成には見落としがちな穴があります。MCPサーバーはプロセスが到達できる範囲すべてにアクセス可能です。

たとえばPrometheus用に作ったツールサーバーが、同じホスト上のGrafana APIやGitea APIにも到達できてしまう状態が起こり得ます。スコープ（権限の及ぶ範囲）を絞る仕組みがMCPの規格側にないためです。

さらに深刻なのは監査ログの欠如です。Claudeがサービス再起動やデータ削除のツールを呼び出しても、誰が・いつ・どのパラメータで呼んだかの記録が残りません。

障害対応の現場で最も困るのはこの部分です。障害発生後に「AIエージェントが何かを実行したか」を追跡できず、根本原因分析（RCA）の材料が最初から欠落します。

もう一つの見落としが読み取り専用と書き込みの区別です。MCPの仕様上、ツールは「存在するかしないか」の二値でしかなく、query_prometheusのような安全な参照系ツールと、restart_serviceのような破壊的操作を区別する概念がありません。

なぜ起きるか

原因を段階的に分解すると、まず規格そのものの設計思想があります。MCPはクライアントとサーバーの通信手順を定義するプロトコルであり、サーバーが何をしてよいかは意図的に範囲外としています。

次に、実装側の実務的な事情があります。数個のサービスをつなぐだけなら、APIキーを環境変数や設定ファイルに直書きして数十行のPythonスクリプトを書く方が圧倒的に早く動きます。

9個のMCPサーバーを立てれば、9か所に平文の認証情報が散らばり、それぞれにアクセスポリシーがない状態になります。これは秘密情報管理の観点で見ると、Kubernetes Secretsやクラウドのシークレットマネージャーが解決してきた課題を、MCP層で再び生み出してしまっている構図です。

さらに厄介なのがツールの組み合わせによって生まれるリスクです。Claudeが複数のMCPサーバーに同時アクセスできる場合、サーバーAで機密データを読み取り、サーバーBで外部APIに送信するといった、どちらの開発者も意図していない呼び出しの連鎖が起こり得ます。

単体のサーバーごとにレビューしても防げない、複合的なリスクという点が運用監視の設計を難しくしています。

自分のプロジェクトが該当するか確認する方法

まず、自分の環境にMCPサーバーがいくつ立っているか棚卸しします。Claude Desktopの設定ファイル（macOSなら~/Library/Application Support/Claude/claude_desktop_config.json）を開き、mcpServersキー配下に登録されているエントリ数を数えてください。

次に、各MCPサーバーの起動スクリプトやYAML設定を確認し、以下を1つずつチェックします。

APIキーがコード中や設定ファイルに平文で書かれていないか
ツールにread（読み取り）とwrite（書き込み）の区別が明示されているか
呼び出しログを記録する仕組みがあるか（アクセスログ、監査ログの有無）
同一プロセスから複数の内部サービス（Prometheus、Grafana等）にアクセスできる状態になっていないか
そのMCPサーバーが動作しているホストで、他のポート（9090番のPrometheus API等）にlocalhost経由で到達できるかcurlで試す

この5項目のうち2つ以上に当てはまる場合、認証・認可・監査ログのいずれかが欠落した状態で本番相当の監視基盤にAIエージェントを接続していることになります。

対策の手順

応急的な対策から、恒久的な設計変更まで段階的に進めます。

1. ネットワークレベルでのスコープ制限

MCPサーバーのプロセスを、対象サービス以外に到達できないようネットワーク的に隔離します。コンテナで動かしている場合はDockerのネットワーク分離（--networkオプションで専用ネットワークを割り当てる）を使い、Prometheus用コンテナとGrafana用コンテナを別ネットワークに置きます。

2. 認証情報の集約管理

環境変数や設定ファイルへの平文保存をやめ、シークレット管理ツール（HashiCorp Vault、AWS Secrets Manager、あるいは簡易的にはOSのキーチェーンなど）に移行します。MCPサーバー起動時にランタイムで解決する方式にすると、設定ファイルをGitにコミットしても認証情報が漏れません。

3. read/writeの明示的な分離

参照系のツール（クエリ実行、アラート一覧取得など）と操作系のツール（再起動、削除など）を別のMCPサーバーに分割します。操作系サーバーは別途承認フローを挟むか、常時起動せず必要なときだけ手動で立ち上げる運用にします。

4. 呼び出しログの記録

MCPサーバー側でツール呼び出しのたびに、呼び出し元・ツール名・パラメータ・タイムスタンプをログファイルやログ収集基盤（Fluentd、Loki等）に送る処理を追加します。障害対応時にAIエージェント経由の操作を追跡できるようにするための最低限の備えです。

# Claude Desktopに登録されているMCPサーバーの一覧を確認する例
cat ~/Library/Application\ Support/Claude/claude_desktop_config.json | jq '.mcpServers | keys'

# 特定ポートへのローカル到達性を確認し、スコープ漏れがないか調べる例
curl -s -o /dev/null -w "%{http_code}
" http://localhost:9090/api/v1/alerts

こうした自前実装が手間に感じる場合、MCPプロトコルとバックエンドAPIの間にディスパッチ層を挟み、レート制限・アクセスモード検証・入力検証を通過させてからHTTPリクエストを実行する構成を検討する余地もあります。信頼レベルを段階的に設定し、参照専用の設定では書き込み系メソッドを実行時にブロックするといった仕組みは、設定ミスの早期発見に役立ちます。

まとめ

MCPは規格として認証・認可・監査ログを持たず、その責任は実装者に委ねられています。

オンプレの監視基盤をAIエージェント経由で操作可能にする場合、この空白がクラウド移行時のIAM設計とは別レイヤーで新たなリスクになります。

次の一歩として、自分の環境のMCPサーバー設定ファイルを開き、APIキーの保存場所とread/writeの区別、呼び出しログの有無を確認してください。

該当箇所が見つかった場合は、ネットワーク隔離とシークレット管理ツールへの移行から着手するのが現実的な優先順位です。