最後に新入社員をオンボーディング（受け入れ）したときのことを思い出してほしい。アカウントを作成し、どのシステムへのアクセスが必要かを見極め、適切な権限を付与したはずだ。役割が変わればアクセスを更新し、退職すれば権限を取り消す。
では最後にAIエージェントをデプロイ（展開）したときはどうだったか。そうした手順を何か1つでも行っただろうか。
ほとんどの組織は行っていない。エージェントはすばやく立ち上げられ、仕事をこなすために広範なアクセスが与えられ、そのまま稼働し続ける。明確なオーナーも、定義されたスコープもなく、触れられる範囲を見直すプロセスすらないことが少なくない。これは、企業が10年前にサービスアカウントやAPI認証情報で犯したのと同じ過ちだ。違いは、より速く、しかも意思決定が可能なシステムが相手だという点にある。
アイデンティティセキュリティ（IDセキュリティ）は、そもそも人間だけの問題ではなかった。少なくとも大半はそうではない。人間のアイデンティティはごく一部で、せいぜい1〜2%にすぎない。残りはマシンだ。クラウドワークロード、DevOpsパイプライン、SaaS連携、自動化スクリプト、サービスアカウント。すべてが認証し、すべてがアクセスを必要とする。そしてその大半は、セキュリティチームが実際に運用しているアイデンティティガバナンス（ID統制）プログラムの外側に存在している。
AIエージェントが新しい問題を生むわけではない。何年も積み上がってきた問題に、ただ圧力をかけるだけだ。
従業員のように振る舞うエージェント、しかし説明責任はない
私は以前からこの比較をしてきたし、これからも繰り返す。AIエージェントは、あなたに報告するチームのように働く。CEOであれば、すべてを自分でこなすわけではない。財務担当VPには予算を、IT部門責任者にはインフラを、営業ディレクターにはパイプラインを任せる。彼らは仕事をし、報告し、あなたは提示された情報を基に意思決定する。AIエージェントも同じモデルだ。ただし、経営層だけでなく、誰もが使える形になっている。
違いは、人間の従業員には文脈があることだ。「記録を整理して」と言われても、それが本番データベースを削除せよという意味ではないと、経験から分かっている。AIエージェントにはそれがない。権限が許すことを、そのまま実行する。そして権限がタスクに必要な範囲を超えていれば、それを使わないように止めるものはない。
これが破綻したときに何が起こるかについては、すでに判例もある。ある航空会社がカスタマーサービス向けにAIチャットボットを導入した。チャットボットが顧客に対して料金に関する約束をしてしまい、航空会社が「それはAIであって当社ではない」と主張したところ、裁判所は認めなかった。あなたがデプロイしたのだ。あなたが代理として使ったのだ。何をしたかの責任は、あなたにある。
繰り返し見落とされる問い
セキュリティリーダーはAIについて多くの問いを立てる。モデルは安全か。学習データはクリーンか。誰かがプロンプトを操作したらどうなるか。いずれも重要だ。だが、より基本的で、見落とされがちな問いがある。このエージェントは実際、何にアクセスできるのか。
現実には、答えはたいてい「必要以上」だ。顧客データを要約するために作られたエージェントが、データベース全体への読み取り権限を持ってしまう。スケジューリングを任されたエージェントが、本来触れるべきでないカレンダーへの書き込み権限を持ってしまう。正確なアクセス権を設定するのは、広範なアクセス権を与えるより難しい。だから広範なアクセスが付与される。
最小権限（least privilege）は新しい概念ではない。何十年にもわたりIDセキュリティの中核をなしてきた原則であり、人間であれマシンであれ、どのアイデンティティも、目の前のタスクに本当に必要な範囲にのみアクセスすべきだ。これをAIエージェントに適用するのが難しいのは、「必要な範囲」が変動し得るからである。とりわけ、エージェントが複雑で多段のワークフローを連鎖（チェイニング）させる場合はなおさらだ。だが、難しいことは不可能と同義ではない。「複雑だから」はガバナンス戦略ではない。
ダニー・ブリックマンは、Oasis Securityの共同創業者兼CEOで、非人間アイデンティティの問題に幅広く取り組んできた人物だ。彼は私との対話で、要点をシンプルに表現した。「エージェントを扱うとき、可能な限りスコープを切る必要がある」と彼は言う。「必要なものにだけ権限を与えるか、何かおかしなことが起きないよう保護メカニズムを用意する」。例は具体的だ。エージェントにデータベースを読ませて要約させたいなら、読み取り権限だけを与える。書き込みではない。削除でもない。読み取りで十分だ。
ただし問題は、スコーピングが委任の際に自然と行われる思考ではない点にある。私たちは「これをやっておいて」と言って先に進む。「この3つのテーブルへの読み取り権限だけで、サービス境界の外には一切権限を与えずにやっておいて」とは言わない。エージェントが動き出す前に、壊れてからではなく、そこまでの精度に到達することは、組織にとって現実的な転換を伴う。
ガバナンスの空白はすでに開いている
エージェントはすでに企業環境で稼働している。カスタマーサポート、DevOps、財務、人事。これは将来に備えて計画すべき問題ではない。いま管理すべき現在進行形のエクスポージャー（露出）である。
クラウドの普及は、クラウドセキュリティを何年も先行して進んだ。SaaSのスプロール（無秩序な拡散）は、アイデンティティとデータガバナンスの問題を生み、組織はいまも後始末をしている。新たな技術の波が、それを管理するためのプログラムより速く動くたびに、同じことが起こる。そして反応はいつも「もっと理解できてから安全にする」という形になる。
ブリックマンは率直にこう述べた。「いま聞こえてくるのは、まずはイノベーション、セキュリティは後だ、という話だ。その結果がどうなるかは分かっている」
AIエージェントは、従来の自動化技術よりも高性能で、自律性が高く、業務プロセスに深く組み込まれる。エクスポージャーはより速く複利的に膨らむ。
実際に何をすべきか
セキュリティ組織は、ここでまったく新しいものを作る必要はない。すでにある分野が使える。IDセキュリティ、アクセス管理、ライフサイクルガバナンス。必要なのは、エージェントを含む非人間アイデンティティを対象にするよう、それらを拡張することだ。
まず答えるべき問いは、稼働しているエージェントが何体いるのか、どのアイデンティティで動いているのか、実際にどこへ到達できるのか、である。多くの組織は、いまこの問いに答えられない。最初に塞ぐべき空白はそこだ。
そのうえで、特権アイデンティティに適用されるのと同じ統制がここでも有効になる。デプロイ前にスコープを定義する。最小権限アクセスを徹底する。想定パターンから外れた挙動を監視する。エージェントの目的が終わったらアクセスを取り消すプロセスを持つ。従業員と違って、エージェントは辞職しないからだ。
これらは、将来世代のAIガバナンスツールが成熟するのを待つ必要はない。枠組みはすでにある。多くの組織がいまだに、エージェントのデプロイをソフトウェアの意思決定として扱い、アイデンティティの意思決定として扱っていないだけだ。そして両者は同じではない。
