AIエージェントがマシン上で動作する必要がある場合、クリーンなルートはModel Context Protocol(MCP)です。MCPサーバーは定義されたツールセットを公開し、エージェントがそれを呼び出します。許可されていることはリストが短く書かれているため判断できます。その後、エージェントがコネクタのない社内チケッティングシステムや2012年以降誰も触っていない業務アプリなどを必要とすると、状況は変わります。タスクを完了しようとするエージェントは別の扉を探し、その扉はほとんどの場合コマンドラインです。
オンライン上のMCP対CLIの議論の多くは、トークンコスト、OAuth、および資格情報の取り扱いに集中しています。これは正当な議論ですが、エージェントがMCPのパスを外れた後にエンドポイントが実際に何を実行するかについてはほとんど問われておらず、その部分はIT管理者が担当することになります。
MCP vs CLI
この2つのアプローチは、エージェントに非常に異なる権限を与えます。MCPでは、エージェントは定義されたツールのリストのみを取得し、それ以外はありません。CLIでは、エージェントがシェルを操作し、シェルはログインユーザーのすべての権利を持ちます。以下で説明する新しいパターンのコードモードは、管理されたデスクトップ上で実行される場合、そのラインのCLI側のように動作します。なぜなら、エージェントが自分のプログラムを書き、マシンがそれを実行するからです。
MCP | CLI | Code mode |
|
|---|---|---|---|
|
What the agent gets |
A defined list of tools |
A shell |
A program it writes itself |
|
Whose rights apply |
The scope of the tool and its credentials |
The logged-in user |
The logged-in user |
|
Where to control it |
The MCP server or gateway |
The endpoint |
The endpoint, plus the sandbox if there is one |
この違いは、開発者がCLIを好む理由を説明しています(トークン消費が少なく、エージェントはgitやdockerのようなツールに慣れているため)およびセキュリティチームがMCPを好む理由(短いリストは監査が容易で、OAuthは中央認証を提供するため)。両者に一理あります。どちらも解決しないのは、agentが誰も承認していないものを実行するのを止めるものが何か、ということです。ツールリストを離れると。
エージェントはCLIにフォールバックします
開発者がエージェントにそのチケッティングシステムからデータを取得するよう依頼したとします。コネクタがないため、エージェントはスクリプトを書き、ヘルパーバイナリをダウンロードし、いくつかのコマンドをつなげますが、MCPのガバナンスはそれを一切見ていなかったため、誰も承認していません。エージェントは完全にMCPの世界を離れました。これは、セキュリティチームが正面の金庫に数か月間取り組んでいる間に、クルーが荷捌き場から入ってくる強盗映画のようなものです。ここでのクルーは善意のソフトウェアであり、荷捌き場は同様に開かれています。
フォールバックも静かです。MCPログにはエージェントが単独で実行したPowerShell commandの記録がないためです。
MCPによるコード実行は、エージェントが作成したコードをエンドポイントに配置します
MCP自体が変化しています。一度に1つのツールを呼び出し、すべての結果をモデルに戻す代わりに、エージェントはコードモードに移行しています。エージェントはMCPツールを呼び出し、返ってきたものをフィルタリングして結合し、全体を実行する小さなプログラムを書きます。Anthropicはこのパターンを自身のエンジニアリングブログで説明しており、1つのスクリプトで20回のツール呼び出しをモデルを通さずに行えるため、その魅力は明らかです。トークンを節約し、エージェントの能力を高めるため、広がりを見せています。
また、実際にエージェントが作成したコードをエンドポイントに配置します。MCPによるコード実行は、エージェントが呼び出せるツールから、エンドポイントが実行するプログラムへと制御の問題を移し、プログラムはそれを書いたものと同じくらい信頼できます。一部の環境ではそのコードをサンドボックスで実行し、サンドボックスは大いに役立ちます。ただし、管理されたWindowsまたはMacのデスクトップは通常サンドボックスではなく、マシンが渡されたものを何でも実行する場合、承認されたツールリストはあくまで提案に過ぎません。エージェントのコードはMCPサーバーを通過するのと同じくらい簡単に回避できるからです。
ローカル管理者権限で悪意のあるシェルやエージェントスクリプトができること
被害はエージェントが借りている権限によります。ローカル管理者の場合、CLIフォールバックはマシンを完全に制御できるため、誰にも許可を求めずにソフトウェアをインストールしたり保護を無効にしたりできます。標準ユーザーのエージェントでも、自分のミスやプロンプトインジェクションが埋め込まれた文書を読んで実行ファイルを実行することがあります。
コードが実行される場所で制限を適用する
多くのチームは、システムプロンプト、ガードレール、わかりやすいポリシーでエージェント自体を制御しようとします。それは役立ちますが、AI側で行われるため、エージェントは混乱したり操作されたりする可能性があります。確実な方法は、コードが実行される場所で制限を強制し、エージェントが何を試みても結果が安全に保たれるようにすることです。エンドポイントはITがすでに所有しているスタックの一部であり、そこで PolicyPak が機能します。
PolicyPakがMCPとCLIを扱う方法:最小権限と許可リスト
PolicyPakは問題に二方向から取り組み、最初の方向は最小権限です。PolicyPak Least Privilege Managerは、ユーザーからローカル管理者権限を削除し、WindowsおよびMac上で必要な特定のアプリケーションとタスクにのみ管理者権限を付与します。標準ユーザーとしてCLIに戻るエージェントはドライバーをインストールしたりセキュリティツールを改ざんしたりできず、付与した例外は指定したアプリに限定されます。
2つ目は許可リストです。PolicyPak SecureRunはファイル所有権に基づいて動作します。標準ユーザーまたはその代理として動作するエージェントによって導入された実行ファイルは、ソフトウェア展開ツールや管理者などの信頼されたアカウントが所有していない限り実行されません。これはコードモードで重要です。エージェントがスクリプトを書いたりヘルパーバイナリを配置した場合、SecureRunはそのファイルを信頼せずブロックします。これがワンクリックのランサムウェア防止として機能する理由でもあります。ハッシュごとのメンテナンスなしで包括的な許可リストを取得でき、既に使用しているツールを取り除く必要もありません。
エージェントは、コネクターが存在する場所ならどこでもMCPを使い続けることができます。コネクターがない場合、CLIフォールバックはユーザーに管理者権限がないマシン上で実行され、エージェントが書き込んだファイルには信頼できる所有者がおらず、MCPによるコード実行が通常の場合でもこれが当てはまります。
Netwrix PolicyPakでローカル管理者権限を削除
無料で試すMCP対CLIのよくある質問
共有する
もっと詳しく
著者について
Jarosław Bogalecki
プロダクトマネージャー
ジャロスワフ・ボガレツキはNetwrixのプロダクトマネージャーで、PolicyPakとPassword Policy Enforcerを担当しています。2019年から技術職に従事し、製品戦略、AI、実際の顧客課題に基づくソリューション構築に情熱を持っています。プロダクトマネジメント以前は、アプリケーションエンジニアリングと技術コンサルティングに従事していました。