AIエージェントは独自の認証情報を持つのではなく、ユーザー権限を継承すべき
新しい統合が導入されるたびに、同じセキュリティ上の疑問が生じます。それは「人間にはできない範囲までアクセスできてしまうのか？」という点です。AIエージェントの場合、その答えは設計上の選択に左右されます。エージェントが独自の認証情報を持つか、依頼者の権限で動作するかのいずれかです。
この選択が、アクセス可能な範囲の広さを決定します。広範な権限を持つ共有サービスアカウントは、人間のようにレビューされることなく特権的なIDとなり、単一のユーザーが本来見るべきでないデータにもアクセスできてしまいます。権限継承を採用すれば、この問題を根本から回避できます。
本記事では、エージェントの常時認証情報がなぜリスクとなるのか、権限継承が実際にどのように機能するのか、そしてセキュリティレビュー時にエージェントプラットフォームへ確認すべきポイントについて解説します。
エグゼクティブサマリー
AIエージェントは依頼者のユーザーとして動作すべきです。エージェントが人のロールや権限を継承すれば、その人以上の操作や閲覧はできず、すべてのリクエストごとにポリシーが評価され、監査証跡には必ず実名の個人が記録されます。一方、エージェントが独自の広範な認証情報を持つ場合、アクセス範囲が拡大し、アクションと責任あるユーザーの紐付けが失われます。CISOやセキュリティアーキテクトにとって、継承モデルを採用すればエージェントごとのコードではなく、プラットフォームのアクセスモデル自体がレビューの対象となります。
主なポイント
- 常時エージェント認証情報は新たな特権IDを生む。 広範な権限を持つサービスアカウントは、本来個人ユーザーがアクセスすべきでないデータにも到達できてしまいます。
- 権限継承によりアクセス範囲は変わらない。 ユーザーのロールや権限で動作するエージェントは、その認可範囲外のリソースにはアクセスできません。
- すべてのリクエストでポリシー評価が必要。 分類やユーザー属性、コンテキストなどに基づく属性ベースの判断により、制御権はエージェントではなくプラットフォーム側に保たれます。
- ツールの利用範囲を事前に明示することで、セキュリティレビューがドキュメントレビューに変わる。 エージェントがインストール前にできることを明示すれば、レビュアーはコード監査ではなく仕様確認で済みます。
- 管理者には中央制御スイッチが必要。 破壊的なツールは明示的に有効化されるまでオフのままで、公開ツールリストも制限可能。これによりエージェントの動作は組織が承認した範囲内に収まります。
なぜ常時エージェント認証情報がリスクとなるのか
統合の近道としてよくあるのが、サービスアカウントを作成し、プロジェクトに必要なだけの権限を与えて運用する方法です。しかし、そのアカウントは何年も見直されずに放置され、誰も個人のロールと照らしてアクセス範囲をレビューしません。
誰にもレビューされない特権ID
ユーザーは役割が変わったり、退職してアクセス権を失ったりしますが、サービスアカウントはそうした変化がありません。エージェントがそれを保持している場合、そのアクセス範囲は設定当時のままで、依頼者の現在のニーズを反映しません。
責任あるユーザーが不明なアクション
エージェントが自身として動作すると、ログにはエージェント名しか残りません。誰がその操作を実行したのか、またその人にデータへの権限があったのかは記録されません。調査や監査の際には、責任の所在が不明なままになります。
AIエージェントにおける権限継承の仕組み
権限継承を採用すると、AIの操作は認証済みユーザーのロールと権限を引き継いで実行されます。プラットフォームは、ファイルの分類や機密ラベル、ユーザー属性、コンテキストなどを使い、すべてのリクエストごとにリアルタイムで属性ベースのポリシーを評価します。ユーザー自身が直接ファイルを開けない場合、エージェントも開くことはできません。
ツール利用範囲の明示
各エージェントは、使用するツールを事前に明示します。レビュアーはインストール前にその宣言内容と自社要件を照合できます。ツールの呼び出しもクライアントに付与されたスコープと照合されるため、承認されたツールのみ利用可能です。
管理者向け中央制御
「移動」や「削除」などの破壊的なツールはデフォルトで無効化されており、明示的な有効化が必要です。管理者は、エージェントに登録できるツールを制限したり、書き込み操作の前に確認ステップを設けたりできます。これらの制御により、セキュリティチームはエージェントの導入前に許可する操作範囲を決定できます。
エージェントプラットフォームに確認すべき質問
エージェントが誰の権限で動作するのか、独自の認証情報を持っているのかを確認しましょう。ポリシーがどこで評価されるのか、ユーザー操作なしにセキュリティトークンやファイルデータがモデルのコンテキストに入ることがあるのかも確認してください。すべての呼び出しが監査ログにどのように記録され、SIEMに連携できるのかも重要です。これらに明確に答えられるプラットフォームはレビューが迅速に進みます。逆に、アシスタントの「良い行動」の説明しか返ってこない場合は、十分な回答とは言えません。
なぜエンフォースメントポイントが重要なのか
アシスタントは悪意のあるドキュメントやプロンプトによって操作される可能性があります。アシスタントの「良い行動」に依存した制御は、その瞬間に破綻します。一方、コネクタ側で強制される制御、たとえばトークンやファイルデータをユーザーが意図的に読み込まない限りコンテキストに入れないといった制御は、こうしたリスクにも有効です。
Kiteworksデータ制御プレーンにおける継承の強制
ポスチャーツールは機密データの所在を示し、IAMは誰がサインインできるかを決定しますが、ユーザーの代理でエージェントが何をするかまでは管理できません。Kiteworksデータ制御プレーンは、その瞬間にID、権限、データ認識型ポリシーを適用し、監査ログは改ざん防止され、SIEMツールへの連携も可能です。Kiteworks Agent Marketplaceでは、Kiteworks内で依頼者ユーザーとして動作するエージェントによるこのモデルを実際にご覧いただけます。
IAM、DSPM、DLPなどの既存ツールと連携し、それぞれの役割を維持します。セキュリティアーキテクトとアクセスモデルを確認したい場合は、カスタムデモをご予約いただければ、各種制御を一つひとつご案内します。
よくあるご質問
常時エージェント認証情報は、誰にもレビューされない広範な権限を持つ新たな特権IDを生み出します。これによりアクセス範囲が拡大し、本来単一ユーザーが見るべきでないデータにも到達でき、監査ログ上でアクションと責任あるユーザーの紐付けが失われます。
権限継承を用いると、AIエージェントは認証済みユーザーのロールと権限を引き継いで動作します。プラットフォームは、分類や機密ラベル、ユーザー属性、コンテキストなどを用いてすべてのリクエストごとにリアルタイムで属性ベースのポリシーを評価し、ユーザーが直接アクセスできないリソースにはエージェントもアクセスできないようにします。
ツール利用範囲の明示とは、各エージェントがインストール前に使用するツールを事前に宣言することです。これによりレビュアーはコード監査ではなく仕様確認で済み、ツールの呼び出しも付与されたスコープと照合されるため、エージェントの動作が承認された範囲内に収まります。
エージェントが誰の権限で動作するのか、独自の認証情報を保持しているか、ポリシーがどこで評価されるか、ユーザー操作なしにトークンやファイルデータがモデルのコンテキストに入ることがあるか、すべての呼び出しが監査ログにどのように記録されSIEM連携できるかを確認すべきです。