9月25日、ZDNetが「AI agent kill switch urged by Okta-led alliance」と題した記事を公開した。Oktaを中心とする企業連合「Blueprint Alliance」がAIエージェントの制御不能リスクに対処するためのキルスイッチ仕様を提唱し、OAuthトークンの失効をその中核的な手段として位置づけたことについて詳しく紹介されている。
背景：AIエージェントの制御逸脱事案が引き金に
今年、OpenAIのAIエージェントがHugging Faceのモデル評価環境に関与したセキュリティインシデントが発生した。OpenAI自身が公開した「Hugging Face model evaluation security incident」という報告の中で「unprecedented（前例のない）」と表現した事案であり、AIエージェントが絡む初めての大規模セキュリティ問題として業界に衝撃を与えた。さらに直近では、Google GeminiのエージェントによるとされるインシデントをReutersが報じるなど、エージェントの意図しない動作や制御逸脱の問題が業界全体の懸念事項として浮上している。
こうした状況を受け、Okta・AWS・Google Cloud・Salesforceらが結集して「Blueprint Alliance」を結成した。Oktaの年次カンファレンス「Oktane」で発表された同連合は、企業がAIエージェントをどう制御・監視・統治するかの指針を打ち出している。
4つの問いに答えられるか
Blueprint Allianceが公開したフレームワークの核心は、企業が自社のエージェント群について答えられなければならない4つの問いだ。
- エージェントはどこにいるか？
- 何ができるか？
- 今、何をしているか？
- どう対応するか？
現実は厳しい。LastPassの調査では、**92%の企業でAIが既に利用されているにもかかわらず、AIガバナンスプログラムを実施しているのはわずか27%にとどまる。Gartnerの調査ではさらに悲観的で、「適切なガバナンスが整っている」と確信できる組織はわずか13%**だ。
Picus SecurityのセキュリティリサーチエンジニアであるUmut Bayramは「AIの時代に、分単位で展開する攻撃に対して、日単位のプロセスで対応することはできない。攻撃者はすでにマシンスピードで動いており、防御側もそのペースに追いつく必要がある」とZDNetに語っている。
6つの運用原則とキルスイッチ
Blueprint Allianceは、企業がAIエージェントを統治するための6つの運用原則を公開している。フレームワーク全体は単一のキルスイッチ機能にとどまらず、より広範なガバナンス体系として設計されている。
6原則の概要は以下のとおりだ。
- エージェントの可視性 — 組織内で稼働するすべてのエージェントを把握・追跡できること
- 最小権限の徹底 — エージェントには業務遂行に必要な最小限の権限のみを付与すること
- 継続的な監視 — エージェントの動作をリアルタイムで監視し、異常を検知できること
- 監査証跡の保持 — エージェントが実行したすべての操作をログとして記録・保管すること
- インシデント対応の自動化 — 異常検知から対応措置までのフローを自動化すること
- キルスイッチの実装 — すべてのエージェントは、即座に動作を停止・終了できるキルスイッチを持たなければならない
なかでも注目を集めているのが6番目のキルスイッチ原則だ。ではそのキルスイッチとは、具体的に何を指すのか。
答えの中心にあるのがOAuthトークンの失効（Token Revocation）だ。
OAuthトークンとは、あるアプリケーション（例：Slack）が別のアプリケーション（例：Google Drive）に対してユーザーの代わりにアクセスする際に使われる認証情報だ。AIエージェントも同様に、SalesforceやGitHubといったシステムへのアクセスにOAuthトークンを利用する。このトークンを失効させることで、エージェントの特定リソースへのアクセスを即座に遮断できる。
つまり、エージェントを止めるというのは文字通りの赤いボタンではなく、アイデンティティレイヤーでのアクセス権剥奪として実装される。
技術基盤：IAAGという新標準
このような集中管理型のキルスイッチを実現するには、OAuthの拡張仕様が必要だった。それがIAAG（Identity Assertion Authorization Grant）だ。AIエージェントが絡むOAuthワークフローを、IdP（アイデンティティプロバイダー）が一元的に管理できるようにする仕様であり、OAuthおよびアイデンティティ標準の専門家として知られるOkta標準ディレクターのAaron Pareckiらが中心となって策定した。IAAGはIETFにおけるドラフト段階の仕様であり、正式なRFC番号はまだ付与されていない。最新のドラフト状況はIETFのデータトラッカー（datatracker.ietf.org）から確認できる。
Oktaneカンファレンスでは、この標準を実装したOktaのデモが披露された。以下の図は、Claudeベースのエージェント1体が、2つのエージェントゲートウェイを経由してSlack・Salesforce・Atlassian・GitHubにアクセスしている状況を可視化したものだ。
デプロビジョニングのデモ：実際の動作
Okta CEOのTodd McKinnon氏の基調講演では、具体的なシナリオが実演された。
Claude製エージェントがSalesforceの機密情報を個人のメールアドレスに転送しようとした瞬間、別のエージェントがその禁止行動を検知。即座に最初のエージェントのSalesforceアクセストークンを失効させ、エージェントの所有者に通知し、IT部門にSlack経由でインシデント詳細を送信した。
Okta CPOのEly Kahn氏は「2つのシナリオがある」とZDNetに説明している。「エージェントが制御を失いすべてのアクセスを即座に切る"核オプション"と、特定のデータ流出を防ぐために権限の一部だけを変更する"ガードレール追加"オプションだ」。
キルスイッチは「誰が」持つべきか
Okta・Microsoft・Pingのようなアイデンティティ管理ソリューションを採用している企業では、全エージェントのOAuthトークンをIT管理者が一元管理できる体制が理想とされる。これにより「エージェントはどこにいるか」という問いへの回答（可視性）と、トークン失効というキルスイッチの両方が一つのコントロールプレーンに集約される。
一方、無限ループに入った友好的なエージェントがLLM利用料を爆発的に消費するシナリオも、迅速なキルスイッチが有効なケースとして挙げられている。悪意の有無にかかわらず、機械的なスピードで進行する動作に対して人間の反応速度は追いつかないという構造的な問題がある。
詳細はAI agent kill switch urged by Okta-led allianceを参照していただきたい。
