【ITニュース解説】Your AI agent has more permissions than your users

システムエンジニアを目指す皆さんにとって、日々の業務で多くのシステムを連携させ、効率化を図ることは非常に重要だ。近年、AI技術の発展により、私たちの仕事の進め方は大きく変わろうとしている。特に、AIエージェントやチャットボットが私たちの指示を受け、さまざまなシステム（Jira、GitHub、Slack、AWSなど）で自動的にタスクを実行してくれるようになったことは、業務効率を劇的に向上させる可能性を秘めている。しかし、この便利さの裏には、セキュリティ上の重大なリスクが潜んでいることを理解しておく必要がある。

想像してみてほしい。あなたは会社で開発プロジェクトのタスク管理をしているダナというエンジニアだ。日々の業務でAIアシスタントに「アシスタント、PAY-123のタスクを完了して、古いリリースブランチを削除してください」と依頼する。アシスタントは「了解しました✅」と返事をし、言われた通りの作業をあっという間に完了する。ところが、ダナ自身は、そのリポジトリのブランチを削除する権限を持っていない。これはどういうことだろうか。ダナができないはずの操作を、なぜアシスタントは実行できたのだろうか。

この現象は、多くの企業で実際に起こっている問題の核心をついている。AIエージェントやチャットボットの多くは、ユーザーの代わりに複数のシステムと連携し、タスクを実行するために、一つの「サービスアカウント」を使っている。このサービスアカウントは、誰からのどんな依頼にも対応できるよう、非常に広範なアクセス権限を持つことが多い。つまり、AIエージェントが持っている権限は、個々のユーザーが持っている権限よりもはるかに大きい場合があるのだ。その結果、エージェントに指示を出せる人であれば誰でも、本来アクセスできないはずの操作が、AIエージェントを経由することで実行されてしまうという、セキュリティ上の抜け穴を生み出す状況となる。

このような問題は、実はAIエージェントが登場する前から、ChatOps（チャットツール経由でシステム操作を行うこと）のボットでも存在していた。しかし、AIエージェントはさらに問題を複雑にする。AIエージェントは、人間が話すような自由な形式のリクエストを理解し、その場で判断して複数のツールを連携させたり、さらには説得されて意図しない操作を実行したりする可能性もあるからだ。

この問題に対して、いくつかの対策が試されてきた。最も手軽に考えられるのは、AIモデルに「ユーザーが許可されているアクションのみを実行しなさい」と指示する「プロンプトによる指示」だ。しかし、これは残念ながら機能しない。AIモデルは、ダナが具体的にどのシステムで何ができるのかという個別の権限情報を知っているわけではない。そして、実際にツールが実行されるときには、モデルが何を知っているかに関わらず、ボットが持つ広範な認証情報で処理が走ってしまう。プロンプトはあくまで「お願い」であり、システム上の実際の権限チェックとは何の関係もないのだ。権限のチェックは、AIモデルの外部で、コードによってツールが実行される前に厳密に行われる必要がある。

次に考えられる対策は、「ユーザーごとのOAuth」を使う方法だ。これは、AIエージェントが、ダナ自身の認証トークンを使ってシステムにアクセスするようにする方法である。こうすれば、システム側はダナの権限を正確に認識し、ダナが許可されている操作だけを実行させる。これが実現できれば、最もクリーンで理想的な解決策と言えるだろう。しかし、現実にはいくつかの課題がある。まず、KubernetesのRBACやAWSのIAM、あるいは多くの社内ツールなど、システムによっては「ボットがユーザーとして動作する」ようなシンプルな連携フローが用意されていない場合が多い。また、エージェントを使い始める前に、すべてのユーザーが、連携するシステムごとに同意画面を通過する必要があり、これは手間がかかる。さらに、エージェントがすべてのユーザーのリフレッシュトークンを保存することになるため、もしエージェントが攻撃された場合、単一の読み取り専用認証情報よりもはるかに大きな被害につながる可能性がある。

もう一つの対策として、「独自のポリシーエンジン」を導入する方法がある。これは、各システムの権限モデル（例えば、プロジェクトの役割、リポジトリのチーム設定、Jiraの権限スキーム、IAMポリシーなど）を、Open Policy Agent（OPA）やCedarといった外部のポリシーエンジン、あるいは設定ファイルにコピーして保存し、そこに対して権限チェックを行う方法だ。この方法は、導入当初はうまく機能するかもしれない。しかし、時間が経つにつれて、各システムの権限設定が変更されるたびに、コピーしたポリシーエンジン側の設定も正確に更新し続けなければならない。これを怠ると、ポリシー設定が現実と乖離してしまう。もしポリシーが誤って「許可」の方向にずれてしまうと、人々はそのチェック結果を信頼するため、チェックがない場合よりもかえって危険な状況を生み出してしまう。

では、どうすればこの問題を根本的に解決できるのだろうか。最もスマートな解決策は、「各システムがすでに知っている情報に直接問い合わせる」ことだ。どのシステムも、特定のユーザーが何ができるかという情報を正確に持っている。KubernetesにはSubjectAccessReview、Jiraにはユーザーごとの権限API、AWSにはプリンシパルのIAMポリシーをシミュレーションする機能、GitHubにはリポジトリでのユーザーの有効な役割をレポートする機能などがある。これらの機能を使えば、AIエージェントが何かを実行しようとする前に、そのシステムに対して「このユーザーは、このアクションを、このリソースに対して実行できますか？」と直接問い合わせることができる。

この考え方に基づき開発されたのが「hallpass」というサービスだ。hallpassは、小さくて自己ホスト型のサービスで、一つのシンプルなエンドポイント（入り口）を持っている。たとえば、あるユーザーがJiraで特定の課題を削除できるかどうかを知りたい場合、hallpassに対して「ユーザーはdana@example.comで、Jiraというシステムに対し、PAY-123という課題の削除アクションを許可されていますか？」という情報を送信する。するとhallpassは、Jiraシステムにリアルタイムで問い合わせを行い、その結果をJSON形式で「許可する（allow）」か「拒否する（deny）」か、または「不明（unknown）」として返す。

hallpassの重要な点は、自らがアクションを実行するわけではないということだ。hallpassは、Jiraなどのシステムに対し、自身の「読み取り専用」の認証情報を使って問い合わせを行うだけで、実際の削除作業などは行わない。そして、問い合わせ結果が「allow」だった場合にのみ、AIエージェントが自身の認証情報を使って実際の作業を実行する。この仕組みにより、AIエージェントは広範な権限を持ちつつも、ユーザーが許可されていない操作を誤って実行することを防げるのだ。

hallpassの回答が「allow」「deny」「unknown」の3種類であることも重要だ。「deny」はシステムが明確に「許可しない」と答えた場合。「unknown」は、hallpassが質問を評価できなかった場合を指す。たとえば、問い合わせ先のシステムがタイムアウトしたり、API呼び出し回数制限に引っかかったり、hallpass自身の認証情報が拒否されたり、問い合わせたリソースが見えなかったりする場合だ。このような「unknown」のケースでは、hallpassは決して推測せず、呼び出し元は「deny」として扱うべきだと定めている。この「unknown」の扱いがあるからこそ、システムが壊れたり予期せぬ問題が発生したりしても、hallpassは決してサイレントに「許可」することなく、常に信頼できる権限チェックを提供できるのだ。

実際のAIエージェントにhallpassを組み込む場合、そのチェックはAIモデルのプロンプトではなく、ツールが呼び出される直前のコードの中に記述される。Pythonの例を見ると、allowed()という関数が用意されており、この関数がhallpassに問い合わせを行う。そして、allowed()がTrue（許可）を返した場合にのみ、Jiraへの実際のAPI呼び出しが行われる。ここで重要なのは、権限チェックの対象となるユーザー情報（requesting_user）は、AIモデルが生成したテキストから取得するのではなく、SlackのユーザーIDやSSOセッションなど、メッセージを送信した本人の「認証済みID」から取得する点だ。これにより、AIがユーザー名を誤認識したり、意図的に別のユーザーになりすまそうとしたりするリスクを防げる。さらに、StrandsやLangChainといったAIエージェント開発フレームワーク向けには、@guardedというデコレーターが提供されており、シンプルな記述でこの権限チェック機能をツールに組み込めるようになっている。

現在、hallpassはJira、GitHub、AWSなど、21種類ものシステムに対応している。各システムの統合方法や必要な読み取り専用認証情報、そしてhallpassでは見ることができない権限の範囲なども詳細にドキュメント化されている。hallpass自体はGo言語で書かれた単一のバイナリで、一つのYAML設定ファイルだけで動作し、データベースも不要だ。シークレット情報も環境変数やファイルから安全に参照される。また、各統合機能は、そのシステムの公開されているAPI仕様に沿って厳密にテストされており、リソースの解析機能も日々ファジングテスト（意図的に不正なデータを送り込んでバグを見つけるテスト）が行われている。

もちろん、hallpassにもいくつか注意すべき限界がある。第一に、これはあくまで「チェック」であり「トランザクション」ではないということだ。hallpassが「許可する」と判断してから、AIエージェントが実際にアクションを実行するまでの間に、対象システム側の権限設定が変更される可能性はゼロではない。デフォルトでは回答が30秒間キャッシュされるため、リアルタイム性が極めて重要な場合はこのキャッシュ時間を0秒に設定することもできる。第二に、hallpassは「呼び出し元が申告するユーザーが誰であるか」を信頼する。つまり、「このユーザーが本当にダナである」ことを確認するのは、AIエージェント側の役割であり、hallpassはあくまでそのユーザーが持つ権限を教えてくれるだけだ。第三に、hallpassは、各システムが読み取り専用の認証情報で公開している情報しか知ることができない。もし、ある権限が読み取り専用のアクセスでは確認できない場合、hallpassの回答は「unknown」となる。各統合のドキュメントには、hallpassが見ることのできない範囲が明記されているため、利用時には確認が必要だ。

hallpassは、開発プロジェクトを安全かつ効率的に進める上で、AIエージェントと人間が協力する未来をより確実なものにするための重要なツールだと言える。システムエンジニアを目指す皆さんにとって、このようなセキュリティと利便性を両立させるための技術や考え方は、今後のキャリアにおいて非常に役立つはずだ。