ある組織が明らかにしたAIエージェントのリスク

購読する

市民開発者がコードを生成

この組織では、AIエージェントを利用する従業員の50%がエンジニアリング部門以外に所属しています。マーケティング、人事、営業、法務、財務の各部門が日常的にAIエージェントを使っており、単にチャットをしているだけではありません。エンジニア以外の利用者のうち、平均42%が、エージェントにコードの実行、ビルド、パッケージのインストール、クラウドやクラスタのコマンド実行をさせていました。 

ツールを作る財務担当者が、エンジニアと同等のセキュリティ知識を持っている可能性は低く、同じレビュー体制が最初から整っているとも限りません。だからといって、ものづくりを止めるべきではありません。組織は、インストールやCLI呼び出しを監視するとともに、安全に開発できるサンドボックス化された承認済みの環境を提供する必要があります。 

エージェント自身による行動の記録だけでは不十分

この組織のエージェントが記録したツール呼び出し1件につき、カーネルは7件のプロセスを捕捉していました。エージェントのログはユーザーがセッションをデバッグする際には役立ちますが、記録を書くのがエージェント自身であるため、監査の証拠として使うことは想定されていません。カーネルは、どのツールやAPIを使ったかにかかわらず、プロセスレベルで実際に実行された内容を把握します。ただし、追加のデータからは、全体像を把握するにはセキュリティチームが両方を必要とすることがわかっています。たとえば、エージェントが認証情報ファイルを読み取った場合、エージェントのログに記録がなかったケースが82%に上りました。一方、カーネルはすべての読み取りを記録していました。

未検証の拡張機能をエージェントに接続

この組織で使われていたMCPサーバーのほぼ半数（47%）は、サードパーティのレジストリやベンダー由来でした。各サーバーは信頼関係の一つであり、設定をわずか1行書くだけでエージェントに接続でき、接続された時点でアクセス権を持ちます。サーバーはバックグラウンドで気付かれないうちに更新されることもあり、先週信頼したサーバーが、今日動いているものと同じとは限りません。

タスクに合ったモデルの選択

この組織のAI関連支出の50%超が、重複したプロセスや機能に使われていました。各エージェントの背後にいるチームやユーザー単位で、どのモデルが使われているかを可視化できれば、組織はタスクに応じてモデルを選び、重複を削減できます。

完全版レポートの内容

ここで紹介したのは、1カ月間のエージェント活動から明らかになった内容のごく一部です。完全版レポートでは、さらに次の点を詳しく取り上げています。

• セキュリティ上重要な検知が発生する頻度 
• 到達可能な範囲に応じてエージェントや拡張機能を許可するための、リスク階層フレームワーク
• データ流出の可能性、未承認のモデルプロバイダー、クラウド権限の変更など、実環境で発生した実際のアラート
• 従業員が日々実際に使っているモデルの階層
• チームにそのまま渡せるリスク低減表

おそらく、AIエージェントはすでにあなたの組織でも稼働しています。問題は、それがどこで動いているのかを把握しているか、そして何をしているのかを確認できるかどうかです。完全版レポートを読んで、この組織が何を発見したのか、そしてギャップを埋めるために何から始められるのかを確認してください。