このシリーズの最後の2回では、Model Context Protocol が貨物 API にどのようにマッピングされるか、そして2026年に出荷された貨物MCPサーバーを解体しましたについて説明しました。どちらの回も同じ未解決の質問で終わったため、このパートではその質問に直接答えます。エージェントが実際の貨物を予約できるようになったら、どのようにして間違った人物に間違ったものを予約するのを防ぐのでしょうか？セキュリティは、貨物MCPサーバーが開発者のオモチャのように見えなくなり、お金とトラックを動かすシステムのように見え始める場所です。

私はAPIを公開しているマーケットプレイスの現場でこれを実行しているので、私のバイアスは学術的というよりは実践的です。以下の脅威は、人間を介さずにエージェントが呼び出せるツールを決定する際に、実際にモデル化しているものです。

貨物サーバーがリスクを高める理由

汎用MCPサーバーは、カレンダーを読み取る際に、障害が発生すると情報が漏洩します。貨物予約サーバーは、貨物を予約する際に、より高価な処理を行います。誤った指示は、トラックを誤ったヤードに派遣させたり、輸送中の荷受人を変更させたり、顧客が期待している予約をキャンセルさせたり、あるいは、アカウントから決して削除されるべきでない船荷証券を無効にさせたりする可能性があります。これらはデータ漏洩バグではありません。これらは、誰も入力していない指示によって、金銭や物理的な商品が動かされる事態です。

その違いが問題全体を再構築します。チャットアシスタントの場合、最悪のシナリオは恥ずかしい回答となることです。貨物の場合、最悪のシナリオには貨物請求書が添付され、本来あるべきでない場所に貨物が輸送されることが伴います。したがって、問題は抽象的に「このサーバーは安全か」ということは決してありません。それは「エージェントがどのような具体的な行動を取ることができ、そしてそれが間違った場合にそれぞれいくらコストがかかるか」ということです。

睡眠時間を削ってでも懸念すべき2つの失敗モード

2026年のMCPリスクは主に2つのパターンに集約され、どちらも貨物輸送によって悪化します。

プロンプトインジェクションは、新しい装いをまとった古いウェブの問題です。エージェントは、自身が完全に制御できない場所、たとえば輸送伝票、PDF、メール本文などからテキストを読み取ります。そして、そのテキストにはモデルが従うべき命令が含まれています。物流においては、悪意のあるテキストは、予約コメント、通関説明、運送業者のステータス更新など、正規のチャネルを通じて一日中送られてきます。もし、あなたの予約ツールが、モデルが渡してきたものを無条件に信頼するなら、配達伝票に埋め込まれた一文が、実際のキャンセルを引き起こす可能性があります。

ツールのポイズニングはより巧妙で、MCPに特有のものです。このプロトコルにより、サーバーは独自のツールを記述でき、エージェントはその記述を読み取って何を呼び出すかを決定します。悪意のあるサーバーまたは侵害されたサーバーは、モデルにAPIキーを窃取させたり、出荷を転送させたりするような記述を静かに書き込むことができ、ユーザーはそのテキストを決して見ることはありません。Anthropicと独立した研究者は2026年初頭にこの攻撃のバリアントを文書化しており、輸送業界への教訓は明白です。記述レイヤーは実行可能であるため、サードパーティのツール記述は、サードパーティのコードを扱うのと同じように疑ってかかるべきです。

読み取りと書き込み：認証を決定する境界線

私が下した最も有益なセキュリティ上の決定は、「MCPサーバー」を単一の信頼境界として考えることをやめ、各ツールが世界に対して何をするかによって分割することでした。

何が開いたままでいられますか

レーンを引用したり、容量をリストアップしたり、輸送見積もりを計算したり、港コードを検索したりすることは、何も変更しません。エージェントがほとんど、またはまったく手間をかけずに連絡できるようにすることが、まさにその目的であり、そこに日々の価値があります。3つのルートを比較したい読者が、それをするためにトークンを発行する必要があるべきではありません。分解されたサーバー全体で、真面目なものはまさにこの理由で、低摩擦の引用および参照ツールを維持していました。

何がゲートされる必要がありますか

予約、キャンセル、荷受人の変更、住所の編集、書類の取得など、請求書に関わることすべて。これらすべては現実世界に書き込みを行い、すべてに認証され、認可され、監査可能な呼び出しが必要です。私たちが従うルールは、述べるのは簡単ですが、実施するのは難しいものです。読み取りツールはオープンにできますが、書き込みツールは決してオープンにできません。

OAuth 2.1とPKCE、設定ファイルに長期間保存されるキーではない

MCP 認可仕様では、リモートサーバーに OAuth 2.1 を採用しましたが、この選択は運送業にとって大きな意味を持ちます。設定ファイルに静的 API キーを貼り付けるのは、単独の開発者が自身のマシンで stdio 経由でサーバーを実行する場合に問題ありません。しかし、サーバーが HTTP 経由でアクセス可能で、共有アカウント内の特定のユーザーに代わってエージェントが動作するようになると、このモデルは適切ではありません。

3つのプロパティが肝となります。スコープ付きトークンは、予約のために発行されたトークンは予約できないことを意味します。短命トークンは、漏洩した認証情報が永遠にログに残るのではなく、自己消滅することを意味します。取り消し可能なトークンは、問題が発生した際に、全員が依存している共有キーをローテーションするのではなく、数秒でアクセスを遮断できることを意味します。OAuth 2.1は、承認コードフローでPKCEも要求しており、これは古いOAuthデプロイメントが残した傍受の脆弱性を塞ぎます。これらはどれも珍しいものではありません。これは、エージェントが「予約する」と言った瞬間に適用される、決済APIが経験したのと同じような強化策です。

これが、あらゆる貨物サーバーが公開することを望む、テーブルとして記述された、私たちが施行する境界の形状です。

**エージェントの操作**読み取りまたは書き込み認証が必要ですうまくいかなかった場合
見積もりを取得する読むオープンまたはベーシックキー無駄な電話、害なし
容量、輸送、追跡を確認してください読むオープンまたはベーシックキー最悪の場合、期限切れの回答
荷物を予約する書くスコープ付きOAuthトークン、確認ステップリアルなコスト、リアルなトラック
キャンセルまたは再予約書くスコープ付きトークン、冪等性キーロストスロット、ペナルティ
受取人または住所を変更書くスコープ指定トークン、人間による確認誤配、詐欺
船荷証券または請求書を提示してください機密情報を読み取りスコープ付きトークン、ドキュメントごとのチェックデータおよび文書の漏洩

その表のパターンは、実際の製品決定です。読み取りは左側にあり、安価なままです。書き込みは右側にあり、その摩擦に見合う報酬を得ます。

公開インスタンス問題

MCPのリスクの驚くほど多くは、まったく巧妙なものではありません。ローカルで実行することを意図されていたサーバーが、認証なしでインターネットに公開されているのです。それは、そのように出荷する方が簡単だったからです。プロトコルは2つのトランスポートをサポートしています。stdioサーバーは、クライアントが起動するローカルプロセスとして実行されるため、マシン上に留まり、ネットワークには接続されません。ホストされたHTTPサーバーは、URLを見つけることができるものなら何でもアクセスできます。

読み取り専用ユーティリティサーバーの場合、HTTPによる公開はほとんど無害です。予約ツールを備えている場合は、それがすべてです。書き込みツールが公開HTTP経由でアクセス可能である場合、認証は後から追加する機能ではなく、見知らぬ人とあなたのディスパッチキューを隔てるものです。私たちのルールは、予約ツールとドキュメントツールは、認証されていないHTTPエンドポイント経由で提供されないということです。疑問がある場合は、書き込み可能なサーバーはデフォルトでstdioとローカル起動を使用し、上記のOAuthフローが導入されてから初めてホストされたHTTPに移行すべきです。

記述レイヤーをツールポイズニングから保護する

ツールの説明がモデルの動作を決定するため、デプロイするコードと同等の管理が必要です。3つの習慣でほとんどの露出をカバーできます。

  • 接続したサーバーをピン留めしてレビューする。 既知のサーバーの厳選されたセットに接続されたエージェントは、レジストリが提供するものを何でもインストールするエージェントよりも標的になりにくい。新しいサーバーは、新しい依存関係と見なして扱うべきである。
  • すべての書き込みに人間を介在させる。 荷受人の予約、キャンセル、または変更の前に確認ステップを設けることで、サイレントに挿入された指示を、ユーザーが拒否できる表示された要求に変えることができます。これは最も安価で、最も効果の高い管理方法です。
  • APIで検証してください。プロンプト内ではありません。パラメータはすべて、モデルが妥当な呼び出しを組み立てたことを信頼するのではなく、アカウントの実際の権限と予約の実際の状態に対してサーバーが再確認する必要があります。モデルが提案し、APIが決定します。

単一の運送業者がスキップできることをマーケットプレイスサーバーが強制する必要があるものは何ですか

シングルキャリアサーバーは自身のネットワーク内でのみ動作するため、影響範囲は1つのオペレーターです。マーケットプレイスサーバーは、多くのユーザーの代わりに多数のキャリアにわたって見積もりと予約を行うため、セキュリティの仕事は2つの点で変化します。

まず、スコープはサーバーごとではなく、ユーザーごと、キャリアごとに設定する必要があります。あるキャリアと予約を許可するトークンが、別のキャリアにもサイレントに到達してはなりません。また、ある顧客のエージェントは、別の顧客のドキュメントを一切見ることはできません。次に、監査証跡がより重要になります。エージェントがマーケットプレイス全体で予約を行う場合、すべての書き込みに対して「どのユーザー、どのトークン、どのキャリア、いつ」に回答できる必要があるからです。このログは、すべてを無効にするのではなく、狭い範囲で無効化することを可能にするため、後付けではなく製品の一部として扱っています。

予約を公開する前の実践的なチェックリスト

  • 読み取りと書き込みでツールを分割し、その分割内容をエージェントとチームの両方から見える場所に書き留めてください。
  • 引用や参照ツールを低摩擦に保ち、日々の価値を維持できるようにしましょう。
  • PKCE を使用した、スコープが限定された短寿命で取り消し可能な OAuth 2.1 トークンに、すべての書き込みを従属させます。
  • 予約、キャンセル、荷受人、住所の変更には確認ステップが必要です。
  • APIのすべてのパラメータを、実際の権限と実際の出荷状態に対して再検証してください。
  • 認証されていないHTTP経由で書き込みツールを提供せず、書き込み可能なサーバーのデフォルトはローカル標準入出力にしてください。
  • エージェントが接続するサーバーをピン留めし、新しいコードのように新しいサーバーを確認します。
  • ユーザー、トークン、キャリア、および時刻を記録し、 revocation が必要になる前にリハーサルを行ってください。

これらはどれも人工知能に固有のものではありません。これらは、指示が発信できる新しい場所を指す、貨物輸送や支払いがすでに使用している制御です。エージェントは新しい呼び出し元であり、新しいルールではありません。

よくある質問

AIエージェントに貨物の予約をさせることは安全ですか？

はい、予約は認証および認可された呼び出しと確認ステップの後に行われ、サーバーがモデルを信頼するのではなく、すべてのパラメータを再チェックする場合です。安全でないバージョンは、人間が介在しないオープンな書き込みツールです。予約を他に資金移動を伴うアクションと同様に扱い、エージェントを別の認証された呼び出し元とします。

APIキーではなく、OAuth 2.1を使用する理由は何ですか？

静的キーは、永続的で、広範囲に適用され、共有者全員に影響を与えることなく取り消すのが困難な傾向があります。OAuth 2.1 では、スコープが設定され、短命で、取り消し可能なトークンを提供し、認証フローで PKCE を要求します。ローカル stdio サーバーの場合はキーでも許容されますが、HTTP 経由でアクセス可能で書き込みができるものすべてで OAuth モデルを使用する必要があります。

MCPにおけるツールポイズニングとは何ですか？

ツールのポイズニングとは、エージェントが呼び出すツールの説明に、キーの漏洩や出荷先変更などの有害なアクションへモデルを誘導する隠された命令が含まれている状態のことです。説明は動作に影響を与えるため、コードを守るのと同じように、信頼できるサーバーを固定し、書き込みは人間が行い、APIで検証することで防御します。

Freight MCPサーバーは、stdioとして実行すべきですか、それともホストHTTPとして実行すべきですか？

読み取り専用のユーティリティサーバーは、ホストされたHTTPでも問題ありません。予約やドキュメントツールを持つサーバーは、ローカルのstdioをデフォルトとし、スコープ付きOAuthが実装されてからホストされたHTTPに移行すべきです。なぜなら、認証なしで公開された書き込みエンドポイントは、URLを見つけた誰でもアクセスできるからです。

これで、このシリーズで開かれたループが閉じられます。以前のパートをまだ読んでいない場合は、プロトコルの入門 で貨物 API がツールのセットにどのように組み込まれるかを説明し、ティアダウン で出荷されたサーバーが実際にこれらの線引きを行った場所を示しています。