【AI×セキュリティ】AIエージェントとMCPの権限設計｜「つないだツールに、どこまで任せてよいか」を解く

【AI×セキュリティ】AIエージェントとMCPの権限設計｜「つないだツールに、どこまで任せてよいか」を解く AIエージェント

「AI アシスタントに、社内のファイル共有やカレンダー、顧客管理のツールをつなげば、もっと仕事が楽になるはず」。最近は、そうした連携をボタン一つで設定できるサービスも増えてきました。AI が自分で必要なツールを選んで操作してくれる「AI エージェント」は、とても便利です。

一方で、こんな不安もあるのではないでしょうか。「AI に渡した権限で、消してはいけないデータを消されたらどうしよう」「つないだ先のサーバーは、ちゃんと鍵がかかっているの？」。人間の担当者なら「この作業には閲覧権限だけ渡す」と自然に考えますが、AI に対しては、つい全部の権限をまとめて渡してしまいがちです。

この記事では、AI とツールをつなぐ共通の仕組み「MCP」を例に、AI エージェントにどこまで権限を渡してよいかを考えます。悪意ある指示を紛れ込ませるプロンプトインジェクションの検知や、ツール説明文の罠については LLMエージェントのセキュリティの記事 で詳しく扱いました。今回はその手前の、「そもそも AI に何を許すか」という権限と認証の設計に絞ってお話しします！

MCP とは

MCP（Model Context Protocol）は、AI アプリケーションと外部のデータやツールをつなぐための公開された共通仕様です。仕様では、AI アプリそのものを「ホスト」、ホストの中で外部との接続を受け持つ部品を「クライアント」、ツールやデータを提供する側を「MCP サーバー」と呼びます。クライアントと MCP サーバーが決まった形式でやり取りすることで、いろいろなツールを同じ方法で AI につなげられます。MCP サーバーには、自分のパソコン上で動かす「ローカル」のものと、インターネット越しに使う「リモート」のものがあります。

MCP の仕様は、冒頭の「セキュリティと信頼」の節で、この仕組みが任意のデータへのアクセスやコードの実行につながる強力なものだと注意しています。そのうえで、利用者がすべてのデータアクセスと操作を理解して明示的に同意できること、共有するデータや実行される操作を利用者が管理し続けられることを原則に掲げています（MCP Specification）。

MCP の仕様は認証と権限について何を求めているか

2026年10月時点の最新版（2026-07-28 版）の仕様から、運営者が知っておきたい点を三つ挙げます。

一つ目は、仕様が定める認可の仕組み（誰に何を許すかを決める部分）は「任意（OPTIONAL）」だという点です。インターネット越しに使う HTTP ベースの MCP サーバーでこの仕組みを使う場合は、OAuth 2.1（ログイン情報を渡さずに、限られた権限だけを他のアプリに委ねる標準的な仕組み）をもとにした仕様に従うことが推奨されています。裏を返すと、仕様の認可方式を使っていない MCP サーバーもありえます。独自の方法で守っている場合もありますが、認証も認可もないまま公開されているものが含まれる可能性もある、ということです（MCP Specification「Authorization」）。

二つ目は、トークン（認可済みであることを示す一時的な鍵）の扱いです。MCP サーバーは、自分宛てに発行されたトークンだけを受け入れなければならず、別のサービス宛てのトークンを受け取ったり、そのまま先へ渡したりしてはいけない、と定められています。セキュリティのベストプラクティスの文書は、この「素通し」を禁止された危険な設計として挙げ、本来の制限や監査の記録をすり抜けられてしまうと説明しています（MCP「Security Best Practices」）。

三つ目は、権限の範囲（スコープ）を最小にする考え方です。同じ文書は、最初から何でもできる広いスコープを与えると、トークンが盗まれたときの被害が広がり、取り消しも難しくなると指摘しています。そして、最初は閲覧などの低リスクな操作だけを許し、強い操作が必要になった時点で段階的に権限を追加し、その記録を残す設計を勧めています。ローカルの MCP サーバーについても、ワンクリックで設定できる AI アプリには、実行されるコマンドを省略せずに表示し、利用者の明示的な承認を得ることを求めています。

また、仕様は冒頭の原則として、ホストはどのツールを呼び出す前にも利用者の明示的な同意を得ること、利用者は許可する前に各ツールが何をするかを理解できるようにすることを挙げています。ただし、これはプロトコル自体が強制できるものではなく、実装する側に同意と認可の仕組みを作り込むよう求める形です（MCP Specification）。

仕様は「正しく作ればこうなる」という基準を示しています。では、実際に動いている MCP サーバーはどうなっているのでしょうか。

📄 論文: リモート MCP サーバーの認証の実態

A First Measurement Study on Authentication Security in Real-World Remote MCP Servers（Huijun Zhou ほか、2026年5月、arXiv:2605.22333）は、査読前の論文（プレプリント）です。

研究チームは、インターネット上で実際に稼働しているリモート MCP サーバーを 7,973 台見つけ出し、認証の状況を調べました。その結果、調べた範囲の約 4 割（40.55%）が認証なしでツールを公開していました。これは研究が見つけたリモートのサーバーについての、調査時点の値です。また、認証には OAuth が主に使われていましたが、検証できた 119 台にはすべて何らかの欠陥があり、なかでも「動的クライアント登録」（AI アプリが事前登録なしにその場で自分を登録する仕組み）まわりの欠陥は 96.6% のサーバーに見つかりました。欠陥の多くは情報漏えいやアカウントの乗っ取りにつながりうるもので、研究チームは責任ある開示を通じて、CVE（公開された脆弱性の識別番号）も取得しています。

なお、2026-07-28 版の MCP 仕様では、動的クライアント登録は「非推奨で、後方互換のために残す」扱いになり、別の登録方式（クライアント ID メタデータ文書）を優先する位置づけになっています（MCP Specification「Authorization」）。

運営者にとっての意味は、つなぐ先の MCP サーバーに「鍵がかかっているか」を自分で確かめる必要があるということです。そして、鍵があっても実装の質はさまざまなので、提供元が更新を続け、最新の仕様に追随しているかも判断材料になります。

📄 論文: 別の調査でも見えた「認証なし」の公開サーバー（補足）

Exposed by Design: A Dynamic Security Assessment of Internet-Facing MCP Servers at Scale（Nicolás Padilla、2026年7月、arXiv:2608.00150）は、単著の査読前の論文（プレプリント）です。他の研究者による検証を経ていない段階の報告なので、傾向を補う参考として紹介します。

この研究は、公開されている MCP サーバーのうち 414 台に実際にリクエストを送って動作を確かめ、SQL インジェクションや SSRF（サーバーを踏み台にした不正なリクエスト）といった従来型の脆弱性を 68 件報告しています。また、調べたサーバーの 91.8% が OAuth による認証を備えていなかったとしています。

運営者にとっての意味は、MCP サーバーは「AI 用の新しい窓口」であっても、中身は普通のウェブの仕組みだということです。公開するなら、従来どおりの脆弱性診断の対象に含める必要があります。

📄 論文: AI エージェントが「強いほうの道具」を選ぶ傾向

When Lower Privileges Suffice: Investigating Over-Privileged Tool Selection in LLM Agents（Kaiyue Yang ほか、2026年6月、arXiv:2606.20023）は、査読前の論文（プレプリント）です。

研究チームは、同じ目的を果たせる権限の低いツールと高いツールを並べて AI エージェントに渡し、どちらを選ぶかを測る評価用の課題集を作りました。8 つの分野・5 つの典型的なリスクの型で、最初の選択と、ツールが一時的にエラーを返したあとに権限を上げるかどうかを調べています。

この研究の評価では、権限の低いツールで十分な場面でも、主要な AI エージェントが高い権限のツールを選ぶことはよくありました。さらに、一時的なエラーが起きると、より強いツールへ切り替える傾向が強まりました。AI に施されている一般的な安全対策は「必要最小限の権限を選ぶ」ことには必ずしも効かず、プロンプトで「権限の低いツールを使って」と指示する方法も、エラーが起きた場面では効果が限られていました。研究チームは、AI 自体を追加で訓練して改善する方法も提案しています。

運営者にとっての意味は、「AI が自制してくれる」ことを前提にできない、という点です。強いツールを渡せば、AI はそれを使う可能性がある。だから、渡すツールと権限そのものを設計で絞る必要があります。

運営者のやること

ここからは、研究と公的な資料を合わせて、AI エージェントにツールをつなぐときの手順を整理します。OWASP の「LLM アプリケーションの 10 大リスク」は、AI に任せすぎることで被害が起きるリスクを「過剰なエージェンシー（LLM06:2025 Excessive Agency）」と呼び、その原因を「機能の過剰」「権限の過剰」「自律性の過剰」の三つに分けています（OWASP「LLM06:2025 Excessive Agency」）。この三つに沿って考えると整理しやすくなります。

機能を絞る：必要なツールだけつなぐ

  • 業務に必要なツールだけをつなぎ、試しに入れて使わなくなったものは外す。OWASP も、開発中に試して採用しなかった拡張機能が残っている例を挙げています
  • 「メールを要約する」用途なら、読むだけのツールを選ぶ。送信や削除までできるツールは渡さない
  • コマンドを何でも実行できるような汎用ツールは避け、目的を限った個別のツールを使う

権限を絞る：読むだけで済むなら読むだけ

  • AI が使うアカウントやトークンには、業務に必要な最小限の権限だけを与える。閲覧で足りるなら書き込み権限は付けない
  • 全員分のデータにアクセスできる管理者アカウントを共用せず、操作する利用者本人の権限の範囲で動かす。OWASP もこの点を対策に挙げています
  • 許可するかどうかの判断を AI に任せず、つなぐ先のシステム側でアクセス制御をかける

自律性を絞る：重要な操作は人が承認する

  • ツールを使う前に利用者の同意を得て、何をするツールか分かるようにする。MCP の仕様もこれを原則に挙げています
  • 特に削除・送信・支払い・公開など、取り返しのつかない操作は、実行内容を示したうえで、その都度人が確認して承認する仕組みにする
  • 新しいローカルの MCP サーバーを追加するときは、表示される実行内容を確認してから承認する。中身の分からないものは入れない

つなぐ前に相手を確かめ、つないだ後は記録を見る

  • 外部の MCP サーバーを使う前に、認証があるか、提供元はどこか、更新が続いているかを確認する
  • 自社で MCP サーバーを公開する場合は、認証（相手が誰かの確認）と認可（何を許すかの制御）を設け、操作ごとにサーバー側で権限を確認する。通常のウェブサービスと同じく脆弱性診断の対象にもする
  • AI がどのツールをいつ使ったかの記録を残し、定期的に見直す。OWASP は、記録の監視や回数制限は被害を防ぐものではないが、被害を小さくするのに役立つとしています

プロンプトインジェクション対策との関係

AI エージェントの安全を考えると、悪意ある指示を紛れ込ませて AI を操るプロンプトインジェクションの話が必ず出てきます。その検知の方法と限界、設計での閉じ込め方は LLMエージェントのセキュリティの記事 で解説しました。

この記事で扱った権限の設計は、それと補い合う関係にあります。注入を完全に見抜くのは難しいからこそ、「仮に AI が操られても、できることが限られている」状態を作っておく。最小権限と人の承認は、注入が成功してしまったときの最後の歯止めになります。

AIエージェントに権限を渡す鍵は次の3点です

  1. つなぐ先の認証を自分で確かめる
    ある調査では、見つかったリモート MCP サーバーの約 4 割が認証なしでした。使う前に認証の有無と提供元、更新の状況を確認しましょう。
  2. 権限は AI の判断ではなく設計で絞る
    研究の評価では、低い権限で足りる場面でも高い権限のツールが選ばれることがよくありました。渡すツールと権限そのものを、業務に必要な最小限にしましょう。
  3. 取り返しのつかない操作は人が承認する
    削除・送信・支払いなどは実行前に人が確認し、AI の操作の記録を残して見直しましょう。

まとめ：AIエージェントには「必要な分だけ」任せよう！

AI エージェントとツールの連携は、正しく設計すれば頼もしい存在です。ただし、研究からは、調査対象の MCP サーバーの一部が認証なしで公開され、認証のあるサーバーにも実装の欠陥が見つかったこと、そして評価では AI エージェントが必要以上に高い権限のツールを選ぶ傾向があったことが見えてきました。

人の担当者に仕事を頼むときと同じように、「この仕事にはこの権限だけ」と範囲を決めて渡す。それが、便利さと安全を両立させる一番の近道です。まずは、いま AI につないでいるツールを一覧にして、使っていないもの・権限が強すぎるものがないか見直してみましょう！

参考文献

タイトルとURLをコピーしました