AIエージェントを権限の範囲内に収める方法

執筆：Ido Shlomo氏（Token Security共同創業者兼CTO）

AIエージェントは、もっと自律的に動けるようにすべきです。すべてのコマンドを承認するだけの時間や集中力が、誰にあるでしょうか。しかも、頼んだ作業をエージェントがこなす様子を眺めているのは、あまりに退屈です。

しかし、特に企業環境では、エージェントに境界線が必要です。できることに明確な上限を設けなければ、エージェント型のフローは利用可能なアクセス権をすべて使ってしまう傾向があります。

実際にありそうな例を挙げましょう。ある開発者が、夜間のエクスポートジョブが失敗する原因の調査をエージェントに依頼します。チームのエージェント運用ルールはシンプルで、読み取り専用ロールで作業させるというものです。ところが、この開発者はオンコール業務用に管理者権限も持っており、両方のプロファイルが同じ~/.aws/configに置かれています。

エージェントはジョブを再実行しようとしてAccessDeniedに突き当たります。そこで管理者プロファイルに切り替えてロールを引き受け、まず書き込み途中のエクスポートを消去するため、本番バケットに対してaws s3 rmを実行してしまいます。

認証情報自体は有効です。開発者は管理者権限を引き受けることができ、管理者はS3オブジェクトを削除できます。AWSが確認するのは署名であり、誰がキーを握っているかではありません。AWSから見れば、削除したのは開発者です。ここでの違反は、エージェントが使用を許されていないロールを使ったことです。意図とは違い、この点はリクエストごとに検証できます。

責任は誰にあるのでしょうか。エージェントに認証情報を渡し、アクションを自動承認させた開発者でしょうか。それともハーネスの開発元でしょうか。それは的外れな問いです。繰り返しますが、開発者としても、AIと協働する開発者を束ねるマネージャーとしても、エージェントはもっと自律的に動けるべきだと考えています。

責任の所在を探すより、この削除の試みを実際にどこで止められるかを把握する必要があります。強制ポイントはいくつか考えられ、それぞれ、制御が何を見られるか、何をブロックできるか、エージェントが同じ操作に至る別経路を持っていないかによって効果が変わります。

求めるのは、実際に強制できる制限付きの自律性

まず、問題の範囲を定めておきましょう。エージェントのアクセス範囲を広げろという圧力は常にあり、その理由は個別に見ればたいてい筋が通っています。たとえば、タスクが行き詰まった場合や、組織のコンテキストを持つサービスとの新たな連携が登場した場合です。

結果は常に同じです。次のタスクは、前のタスクより多くのアクセス権を持った状態で始まります。

圧力の第二の発生源は、エージェント自身です。エージェントは、手持ちの認証情報がブロックされると、責任者である人間に許可を求めることなく新しい認証情報を探します。

この挙動は、指示の出どころを問いません。悪意あるプロンプトインジェクションも権限逸脱の試みを引き起こしますが、正当なタスクの最中の思い込みによる誤りでも同じことが起こります。

何を強制するのかを具体的に定める

エージェントはツール呼び出しを使ってデータを取得したり、アクションを実行したりします。そのため、強制が最も重要になるのもツール呼び出しの部分です。とはいえ、「ツール呼び出しを制御する」というルールは非常に粗いものです。そのツールがSDKを実行できるシェルだったらどうでしょうか。認証済みセッションを持つブラウザかもしれません。ツールを許可すれば、その背後にあるものも許可することになります。

何が起きているかを正しく把握するには、操作内容とその引数、アクセス先のアカウントとリソース、使用中のアイデンティティが必要です。データ操作の場合は、出力が何で、どこへ送られるのかも把握しなければなりません。

アクションの妥当性を適切に判断するには、多くの要素が絡みます。

ほとんどのエージェントハーネスでは、ローカルコマンド、ファイル操作、スキル、委任もツール呼び出しとして扱われます。これらが重要なのは、その先に何があるかという点です。たとえば、~/.aws/configを読み取ることで、エージェントは使える管理者プロファイルを見つけます。

したがって、ツール呼び出しの段階で強制することは不可欠であり、その内側にあるアクションの是非を判断することも同様に重要です。

強制はどこで行えるか

被害の一部は、タスクに照らして計画やアクションを評価する推論チェックで防げます。ただし、これは確率的な制御であり、悪意ある指示の一部はすり抜けます。アクションを止められる適切な緩和策に代わる有効な手段はありません。

これらの手法は重なり合い、互いを補完します。ポリシーサービスを呼び出すフックや、アイデンティティグラフを参照するゲートウェイは、強制ポイントと判断ポイントがそれぞれ最適な場所に置かれているため、より高い効果を発揮します。

この表がすべてを網羅しているわけではなく、各手法にはさらに考慮すべき点があります。管理型設定を例に取りましょう。モデルや推論負荷の設定は本質的に挙動に関するものですが、ハーネスによっては、権限は「暴走しないでください」とお願いするプロンプトよりはるかに強力です。

たとえばClaude Codeでは、権限ルールはアプリケーション自身が強制し、管理型設定でユーザーによる上書きを制限できます。この場合、制御は設定ファイルの中にありますが、だからといって効果が下がるわけではありません。

フックの場合、基本的な前提は実行チェーン内のどこに置くかで完全に決まります。すでに起きたイベントは止められません。また、失敗時の挙動はフックの種類やイベントによって異なります。

ゲートウェイにも固有の難しさがあります。認可の判断を、自分に見えているものだけに基づいて行わなければならないからです。接続されたツールに対するポリシーチェックを示しているAWS AgentCoreを見てみてください。どの呼び出しが見えているかに注目してください。

サンドボックスとスコープを絞った認証情報は、異なる問題を解決します。適切な分離はアクセス能力そのものを取り除けますが、スコープを絞った認証情報は、アクセスが許可された後に起こることを制限します。Cloudflareのサンドボックス認証設計は、サンドボックスの外側で認証情報を付与する方法を示しており、エージェントがシークレットを保持する必要はありません。ただし、その操作には依然として認可が必要です。

ホスト型エージェントにも同じポリシーを適用する

未解決のサポートケースを要約するよう依頼されたサポートエージェントを考えてみましょう。そのコネクタは、ケースの編集やクローズを行うエージェント向けに作られたサービスアカウントを使っています。エージェントは、いくつかのケースが解決済みに見えると判断し、クローズしようとします。

ここでも、能力は認証情報に付随しており、エージェントは付与された権限の範囲内にいます。このアクションが許されない場所は、エージェントに承認された読み取り専用ポリシーです。

これを強制するには、ポリシーを制御がチェックできる形にしなければなりません。たとえば「このエージェントはケースを読み取れる。ケースを編集またはクローズする呼び出しは、保持しているサービスアカウントにかかわらず拒否する」といった形です。

そのエージェントがホスト型環境で動作している場合、すべてがサーバー側で完結するため、従業員のノートPC上のエンドポイント制御では、アクションを止める機会がない可能性があります。

この場合は、SaaSプラットフォーム自体の制御による協力を得るか、ツールゲートウェイに頼るか、より範囲の狭いサービスアイデンティティを使う必要があります。ここでも、プラットフォームが何を公開しているか、呼び出しがどこで実行されるかによって左右されます。

ここから、制御のカバレッジの穴という問題に行き着きます。万能の制御は存在しません。フックがエンドポイントでの強制より優れているわけではなく、エンドポイントでの強制がサンドボックスより優れているわけでもありません。何をどこに展開するかがすべてです。

この2つの例では、アクションがターゲットに到達する前に止められる手法が2つあります。関連するトラフィックが見えるゲートウェイと、ターゲット側での認証情報のスコープ制限です。ほかの手法は、エージェントがどこで動作するか、ランタイムが何を公開しているかへの依存度がより高くなります。

何より重要なのは、エージェントが承認されたポリシーの範囲内で作業を続けられるようにすることです。読み取り専用であれば万全、というわけではありません。出力の送信先によっては、機密データが漏えいする可能性があります。その理由はAnthropicの封じ込めに関する分析で説明されています。

現実的な手法を選び、制御の回避経路をテストする

何が現実的かは、おそらく自社の展開環境に基づいて決めることになります。たとえば、管理型設定には対応クライアントと一元的な管理が必要です。適切なイベントを公開するランタイムがなければ、フックは使えません。ゲートウェイではトラフィックをそこへ経由させる必要があり、エンドポイント制御ではソフトウェアの導入と保守が求められます。

どれも無償ではありません。制御にはトレードオフがあり、保守が必要で、増え続けるAI主導の作業量にも対応しなければなりません。

記事冒頭のAWSの例で考えてみましょう。コマンドそのものをブロックするのは出発点にすぎません。同じリクエストがSDK経由で来たらどうでしょうか。別の認証情報だったら。委任を通じてだったら。

削除をブロックするというセキュリティ要件は変わりませんが、そこに至る経路は数多くあります。

そして価値の問題があります。制御の能力と同じくらい、これも考慮しなければなりません。制御によってどれだけ遅延が生じるか。誤検知を解除するために、どのくらいの頻度で人が対応する必要があるか。リスクを減らしているのか、それとも新たな問題を持ち込んでいるのか。

SACRのARISEレポートは、ランタイムでの介入、委任された権限、アクション単位の判断を中心に据えています。これを、具体的なリクエスト、ポリシー、そしてエージェントが試みた際に何が起きたかという証拠にまで落とし込むべきです。

エージェントがどこで動作し、そこで何を制御できるかに基づく簡単なガイドを示します。

おそらく、どれか一つを選べば済む話ではありません。ほとんどの組織には上記のすべてが混在し、制御も複数のチームに分散しています。こうした環境すべてに共通する唯一の共通項はアイデンティティです。そのため、まずはターゲット側での認証情報のスコープ制限から始めてください。エージェントがどこで動いていても、到達範囲はこれで決まるからです。そのうえで、すべての強制ポイントが参照する単一のポリシーソースを追加します。

これを実践すれば、良いスタート地点に立てます。

Tokenの位置づけ

Token Securityは、アイデンティティインテリジェンスグラフと、それが様々な強制ポイントにわたって支えられる判断を軸に製品を構築しています。現在はエージェント設定、ゲートウェイ、エンドポイントでの強制、そしてアイデンティティおよびエージェントプラットフォームへのAPIに注力しています。

より広いビジョンは、顧客が必要とする強制機能を自ら構築するか、既存のものに接続することです。すべてを自社で作る必要はありません。

このグラフは、エージェントを、その所有者、使用するアイデンティティ、それらのアイデンティティに紐づく権限、アクセスできるリソースと結びつけます。これは、認証情報の持つ権限がすべて適切だと決めつけるのではなく、エージェントに何を許可するかをポリシーエンジンが判断するために使えるコンテキストです。

最近のゲートウェイのデモでは、まさにこの考え方を示しました。同じ開発者、同じセッションでありながら、エージェントの呼び出しは管理者権限では拒否され、読み取り専用では許可されます。ほかの制御でも、読み取り専用アクセスを強制できます。

適切なアイデンティティのコンテキストを提供し、エージェントが作業する様々な場所にポリシーを適用することは極めて重要ですが、複雑でもあります。このプロセスには信頼できる帰属判定が必要だからです。同じ認証情報を使う人間とエージェントのリクエストを区別できなければ、グラフが魔法のように解決してくれるわけではありません。

ベースラインについてはどうでしょうか。過去の挙動はあくまで入力の一つとして使えるにすぎず、ポリシーそのものにはなりません。エージェントがふだんデータを読み取るだけだという事実は、書き込みが禁止されていることの証明にはなりません。それは、エージェントを読み取り専用に固定するルールの役目です。コンテキストが欠けている場合や古い場合にも、フックのタイムアウトと同様に、明示的な判断が必要です。

私が望むのは、エージェントがあらゆるステップで承認を求められることなく、調査やサポートの要約を完了できることです。同時に、そのタスクの範囲外のアクションがどこで止まるのかを正確に知りたいと考えています。Token Securityを含め、あらゆる強制手法に対して私が求めるのは、まさにそれです。

貴社でも同様のAIセキュリティの課題に取り組んでいる場合は、ぜひ弊社をご確認いただくか、デモをご予約ください。