エージェントが長いタスクをこなす様子を見れば、企業セキュリティの未来が見えてきます。
Claudeが長時間のタスクに取り組む様子を観察してみてください。実はフォルダだったCSVファイルの読み込みに4分間も四苦八苦し、諦めた末に中身を一覧表示するスクリプトを自分で書いて、ようやく目的を達成する——そんなことが起こります。結果的にはうまくいくのですが、あなたが頭の中で思い描いていたやり方とは、決して一致しません。
これこそが「大規模な推測」であり、欠陥ではありません。LLMはそのように動作するからこそ強力なのです。エージェントは確率的に推論し、次に取るべき最善の行動を選択し、結果を観察し、適応していきます。このループこそがエージェントを強力にしている一方で、予測可能なワークフローを前提としたセキュリティモデルが破綻する理由でもあります。
AIエージェントは即興的に振る舞うように設計されており、それこそが有用性の源泉です。しかし、この即興性が広範なアクセス権限と組み合わさると、一つひとつの誤った選択がセキュリティリスクへと変わってしまいます。
そこで問題となるのは、次の一手を予測できないシステムを、どうやって守るのかということです。
誰も答えたがらない問い
エージェントを導入するどのチームも、たいてい気づかないうちに同じアクセス権限の判断に直面します。
- 役立ちそうなツールはすべて与えるべきか、それとも本当に必要なものだけに絞るべきか
- まれなケースに備えて管理者権限を付与すべきか
- エージェントには広範なアクセス権を与えるべきか、それとも今まさに処理しているリクエストの範囲に限定すべきか
これらのコネクタは本当にすべて必要なのでしょうか。どれに管理者権限が必要なのでしょうか。すべてのセッションで必要になるものなのでしょうか。
これらの問いのどれ一つとして、明快な答えはありません。なぜなら、最小権限の原則を適用すること自体が難しいからです。すべてのエージェントに、しかもそのエージェントが実行するセッションごとに最小権限を適用するとなると、難易度は桁違いに跳ね上がります。
そこで多くのチームは、人間らしい対処をします。つまり、フルアクセスを与えてそのまま先に進んでしまうのです。広範な権限付与は最も抵抗の少ない道であり、エージェントはデフォルトでその権限を引き継ぐことになります。
ほとんどのチームがこれらの問いに答えられないのは、そもそも棚卸しができていないからです。Token Securityは、環境内で稼働するすべてのエージェントと、その背後にあるID、そして各エージェントが保有するアクセス権限を洗い出します。
セキュリティ・バイ・デザインでAIを守る
シャドーAIとエージェントの乱立は、セキュリティチームの対応能力を上回るスピードで拡大しています。
Token Securityはすべてのエージェントを検出し、リスクの高いアクセスをマッピングし、意図ベースのポリシーを自動的に適用します。イノベーションの速度や制御力を犠牲にすることなく、AIを安全にスケールさせましょう。
従来の手法が通用しない理由
この2年間、AIセキュリティの取り組みの大半は、モデルの応答の仕方を制御することに費やされてきました。プロンプトフィルタリング、入出力の制約、振る舞いの制御といったガードレールです。これらは多くの場面で有用ではあるものの、今直面している問題に対しては層が間違っています。
プロンプトフィルタは振る舞いを制約しようとします。しかし、自然言語がインターフェースであり、想定しうるプロンプトが無限に存在する以上、必ず別の抜け道が見つかります。99パーセントの確率で機能するフィルタリングであっても、失敗は避けられません。なぜなら、無限の1パーセントもまた無限だからです。
さらに重要なのは、ガードレールはアクセス権限がすでに付与された後に作動するという点です。エージェントが本番システムの認証情報を一度手にしてしまえば、セキュリティ境界はすでにその背後に置き去りにされています。フィルタはエージェントの「発言」を制御できても、エージェントに「許されていること」を取り消すことはできません。
予測というアプローチも、同じ構造的な理由で失敗します。従来のIDおよびアクセス管理(IAM)が答えられるのは「このIDは何にアクセスできるか」という一点だけです。このモデルはAIエージェントに対してはあまり役に立ちません。まったく同じ権限を持つ2つのエージェントでも、それぞれが達成しようとしている目的によって、振る舞いはまったく異なるものになり得るからです。
目標駆動型のシステムを、過去の振る舞いをプロファイリングすることで守ることはできません。なぜなら、次の行動はまだ遭遇していない文脈に依存するからです。
なぜ今、急を要するのか
すでに規模の面では臨界点を超えています。Palo Alto Networksによれば、非人間IDと人間IDの比率は109対1に達しており、その中には79個のAIエージェントも含まれています。エージェントはこの曲線をさらに加速させています。なぜなら、誰でも数分でエージェントを立ち上げることができ、しかもそのほとんどがセキュリティレビューの外側で行われているからです。
エージェントのリスクは、「アクセス権限」×「自律性」として捉えるべきです。アクセス権限が被害範囲を決定し、自律性が人間による介入の余地を狭めます。就業時間中にログインし、四半期に一度レビューされる人間を前提に書かれた静的なIAMポリシーは、決して眠らず、MFAも使わず、めったに廃止されることもないエージェントを想定して設計されたものではありません。
唯一機能する制御プレーンは「ID」
モデルもプロンプトもフレームワークも取り払っても、一つだけ変わらないものがあります。それは、エージェントが取るすべての行動が、必ず何らかのIDを経由するという事実です。サービスアカウント、APIキー、OAuthグラント、クラウドロール、トークン——エージェントはこれらを使って認証します。データの読み取りからインフラの変更に至るまで、すべての行動はエージェントのIDが持つ権限に依存しています。
だからこそ、エージェント型AIにおける制御プレーンは、プロンプトフィルタリングではなく「ID」なのです。IDはエージェントが触れるあらゆるシステムを横断する層であり、一貫した制御を実施できる唯一の場所です。IDがアクセスを制御し、意図(インテント)がそのアクセスを安全なものにします。
欠けていた次元、それが「意図」
従来のアクセス制御が問うのは「このIDは何ができるか」です。しかしエージェントにとってはそれだけでは不十分です。安全な振る舞いと危険な振る舞いを分けるのは、その「目的」だからです。
失敗したデプロイを修復しようとするエージェントと、データを窃取しようとするエージェントは、低レベルではほぼ同じ操作を行う場合があります。ログを読み、APIを呼び出し、データベースにアクセスする——IAMの視点からは両者は同じに見えますが、その意図はまったく異なります。
意図ベースのセキュリティは、この欠けていた文脈を補います。「このエージェントは何にアクセスできるか」ではなく、「このエージェントが目的を達成するために、どこまでアクセスできるべきで、それ以上は許すべきではないか」を問うのです。意図が定義されれば権限を厳密に絞り込むことができ、その境界の外側で起きたことは、単なる日常的な異常ではなく、対応すべきセキュリティシグナルとして扱われるようになります。
これは現実に耐えうる唯一の最小権限のあり方でもあります。すべてのエージェント、すべてのセッションについて、権限を手作業で調整することなど不可能だからです。
しかし、各エージェントの意図をモデル化し、それに対してアクセス制御を自動的に適用することは可能です。この転換こそが、最小権限の原則を「理想論」から「実運用」へと変える鍵となります。
可視化は当然の前提、肝心なのは「強制力」
ほとんどのツールは可視化止まりです。エージェントの棚卸しは必要ではありますが、それだけではエージェントに許されていることは何も変わりません。問題があると知ることと、それを解決することは別物であり、ユーザーは仕事を早く終わらせるためにできる限り多くのアクセス権限を求め続けるものです。
実際にリスクを減らす取り組みは、予防的かつ継続的なものでなければなりません。
- 発見:クラウド、SaaS、エンドポイント、AIプラットフォームを横断して、すべてのエージェントとそれが使用するIDを、誰も登録していないシャドーエージェントも含めて洗い出す
- 把握:各エージェントが何にアクセスでき、何をすべきなのかを理解し、権限を意図に合わせて適正化する
- 強制:その範囲を自動的に適用し、エージェントが廃止された際にはアクセス権を取り消し、作成から廃止までのライフサイクル全体を統治する。リスクは作成時に発生するのではなく、アクセス権限が積み重なり、所有者の所在が曖昧になるにつれて蓄積していくものだからです
エージェントは推測します。それがエージェントの本質であり、変わることはありません。あなたが変えられるのは、誤った推測がもたらす被害の範囲です。それはID層において、意図に応じて範囲を絞り込むことで実現でき、行動が起きた後に釈明するのではなく、行動が起きる前に強制すべきものです。
あなたのエージェントは、これからも即興で動き続けます。問題は、それがあなたが定めた境界の内側での即興なのか、それとも一度も引かれたことのない境界の中での即興なのか、ということです。
