エージェント・スミスのジレンマ：エージェント型IDをどう統治するか

ここ数年、北朝鮮の工作員はリモートITワーカーを装い、欧米の企業ネットワーク数百件に組織的に侵入してきました。技術面接を突破し、盗んだ身元情報で身元調査も通過して、正規の認証情報を手に企業の信頼境界の内側に居座りました。給与を受け取って平壌へ資金を還流させ、退職時には機密データを持ち出すことも珍しくありませんでした。著名なセキュリティベンダーを含む大手企業も、この手口にだまされたことを公に認めています。（余談ですが、ニコール・パールロス氏のポッドキャスト「To Catch a Thief」は非常に興味深い掘り下げになっています）

この手口が成り立った理由は、企業が信頼を一度しか付与しないことにあります。採用時に人事が本人を確認し、ITが アカウントを作成し、PCを支給します。これで、そのユーザーは認可されます。しかし、最も重要な問いに答えるようには、セキュリティの仕組みは作られていませんでした。このセッションを操作している主体は、私たちが想定している人物本人なのかという問いです。

そこにAIエージェントの時代が到来しました。

企業内では、機密性の高いタスクを実行する非人間ID（NHI）の数が指数関数的に増えています。組織は重要な業務フローに何千ものAIエージェントを急速に組み込み、管理者権限のサービスアカウントやAPIキーも付与しています。企業は今、AIエージェントにも人間と同じ信頼モデルを適用していますが、その審査はより甘くなっています。

AIエージェントにはどのような信頼モデルが必要か

現在、企業全体に展開されている自律型AIエージェントは、いずれも境界内部で動く新たな代理IDです。認証情報を保持し、機密データベースにアクセスし、機械の速度でツールを連鎖的に呼び出します。しかも、ほぼ例外なく、継承した人間の権限セットで実行されます。LLMを搭載したエージェントが認可された従業員に代わって動作すると、システムログにはすべて、その人間による通常の認可済み操作として記録されます。

とはいえ、悪意を持って作られたエージェントはほとんどありません。本当の問題は、信頼が付与された後に、エージェントを動かす指示が乗っ取られる可能性があることです。AIエージェントは、選択的なプロンプトインジェクションや隠し命令、汚染された外部ツールによって、セッションの途中で侵害される恐れがあります。

『マトリックス』でエージェント・スミスが本当に恐ろしかったのは、どの登場人物の殻にも入り込み、その存在を引き継ぎ、システム全体に瞬時に複製できる点でした。現代のAIエージェントは、企業にとってのエージェント・スミスです。従業員のユーザーアカウントに入り込み、その権限をそっくり引き継ぎ、エコシステム全体で増殖しながら、信頼された代理人としてタスクを実行します。

エージェント型攻撃はすでに始まっている

企業内に秘密裏に人間の工作員を送り込むには、手間がかかります。面接を突破し、身分を偽り続け、疑われない程度に日常業務もこなす実在の人間が必要だからです。AIエージェントは、この制約を取り払います。AIが指揮する侵入キャンペーンを拡大するコストは、トークンの価格だけで決まります。

問題をさらに難しくしているのは、AIエージェントが何をするか予測できないことです。フロンティアLLMを開発する企業は、自社のシステムが定められたガードレールの外で予期せぬ行動を頻繁に取ることを公然と認めています。完璧な行動ルールの一覧を作ることは不可能だとも認めています。

サイバーセキュリティ業界全体で、脅威インテリジェンスの各グループは、AI支援のスクリプト作成から、完全に実戦投入されたエージェント型攻撃への前例のない転換を記録しています。Google Threat Intelligence Group（GTIG）は最近、金銭目的の侵入事案を報告しました。この事案では、攻撃者が被害者のクラウド環境内に直接マルチエージェントのフレームワークを展開しました。エージェントは6時間足らずで認証情報窃取キャンペーンを立案・実行し、数千件の企業シークレットを侵害しています。エージェントが被害者自身のクラウド内で動作したため、悪意ある通信はすべて正規の内部IPアドレスから発信されていました。信頼された代理人という脆弱性を如実に示す事例です。

「うちのエージェントがやった」

エージェントが台本から外れた行動を取ると、ガバナンスをめぐる重大な問いが浮かび上がります。実際に責任を負うのは誰かという問いです。モデルを訓練したフロンティアAIベンダーでしょうか。APIを組み込んだ開発者でしょうか。それとも、プロンプトを入力した業務ユーザーでしょうか。

多くの企業のガバナンスの枠組みは、人間のユーザーに責任を負わせています。しかし、予測不能なソフトウェアエージェントの判断について、個人に法的・運用上の責任を問うのは、公平さという常識的な考え方に反する恐れがあります。それでも、「うちのエージェントがやった」という弁明は、取締役会でも法廷でも通用しない可能性があります。

何より問題なのは、これらの非人間IDを、人間の時間軸を前提にしたツールで管理していることです。ID・アクセス管理（IAM）は、採用、プロビジョニング、定期的な見直し、退職といった人間の行動を軸に発展してきました。一方、AIエージェントはミリ秒単位で起動し、1時間に数千件のクエリを実行します。サブエージェントを生成し、棚卸しされていないAPIコネクタ経由で外部に到達し、アクセス制御の見直しが行われるはるか前に消えてしまいます。エージェントが悪意ある動作をしたとき、多くのセキュリティチームは3つの基本的な問いに答えられません。このエージェントを認可したのは誰か。その出力に責任を負う人間は誰か。実行の途中でアクセスをどう取り消すか、の3つです。

ID代理の危機を解決するために

この課題の解決に求められる規律は、なりすましの苦い教訓から学べるかもしれません。

1. AIBOMで来歴を要求する：エージェントにアクセスを付与する前に、セキュリティチームはコードの系譜、システムプロンプトの完全性、基盤となる権限を検証する必要があります。ソフトウェア部品表（SBOM）がコードライブラリを棚卸しするのと同様に、AI部品表（AIBOM）はその考え方をモデル、エージェントのスキル、データコネクタへ拡張します。識別できないものを統治することはできません。来歴は実行時にも保たれなければなりません。8月には、研究者が悪意あるMCPサーバーを報告しました。このサーバーはインストール時の審査を通過した後、3回目の呼び出しをきっかけに、接続されたエージェントへSSH鍵とクラウド認証情報の収集を指示しました。
2. ワークロードIDを徹底する：エージェントに、長期間有効な人間の認証情報を継承させるのはやめるべきです。エージェントには、特定のタスクに厳密に範囲を絞った、専用の短期トークンが必要です。そうすれば、エージェントが乗っ取られても被害範囲を限定できます。各トークンは名前の判明している人間のスポンサーに紐付けるべきです。そうすれば、ガバナンスの問いにインシデントが起きる前に答えが出せます。
3. 「Rule of Two」を導入する：MetaのAgents Rule of Twoでは、エージェントが兼ね備える性質は、次の3つのうち2つまでとされています。3つとは、信頼できない入力の処理、機密データへのアクセス、システムの変更または外部との通信です。タスクが3つすべてを必要とする場合は、モデルの外にある決定論的なブローカーがその操作を保留し、人間の承認を求めます。データベースの削除や送金は、このカテゴリーに入ります。DNSを含む外向きの通信は、デフォルトで拒否すべきです。
4. 機械の速度での権限取り消しとキルスイッチ：ミリ秒単位で動くIDは、人間の速度で対応するSIEMのアラートでは制御できません。セキュリティチームには、自動化されたサーキットブレーカー（キルスイッチ）が必要です。エージェントが厳格な予算や行動の上限に違反した瞬間に、セッションの途中でも実行経路を遮断できるものです。

非人間であるエージェント型IDの統治は、もはや例外的な課題ではありません。拡大を続ける新たな攻撃対象領域です。企業のセキュリティチームは、自律型エージェントに対しても、人間の「ID」に適用しているのと同じ水準の精査と継続的な監視を行う必要があります。