こんにちは！バクラク事業部Platform Engineering部IDグループの id:convto です！
この記事は LayerX AI Agent ブログリレー 11日目の記事です。前日は taddy さんによる Amazon Bedrockで社内コミュニケーションの円滑化を目指したエージェントを構築する でした。
社内で定期的にLT大会を開催しており、前日の記事を書いてくださった taddy sanの記事の内容は元々そこ向けに準備していただいたものです。*1
その後この経験がサポートサイトやプロダクト仕様をデータソースとするRAGやエージェント作りに活きたらしいです。いい話〜〜
さてバクラクでは AI Agent を利用した機能をいくつか開発しており、その際 AI Agent に対してどのように認可を与えるかをよく議論します。
今回は AI Agent に認可を与える際にどのような課題があるか紹介し、また B2B SaaS において発生しうる運用上の課題などについても触れようと思います。
目次
この記事で扱う AI Agent の定義
AI Agent とひとくちにいうと文脈によってさまざまな解釈が存在するので、まず本記事で言及する AI Agent について整理します。
本記事では、与えられたタスクについて自律的に情報を集め、判断し、許可されている何らかの操作を行うソフトウェアを以降 AI Agent と呼称します。
AI Agent の認可に関する一般的な課題と対策
ここでは業務領域に関わらない一般的な認可にまつわる課題などを挙げていきます。
適切な最小権限を与える
AI Agent は自律的に思考しさまざまな処理を実行するため、潜在的にユーザーが意図しない操作を実行する可能性があります。
その対策として、AI Agent にはタスク解決に必要な最小限の権限のみを与えるべきです。(最小権限の原則)
1st party で開発する AI Agent の場合は、利用 tool の定義をこちらでコントロールできます。動的な tool 登録をしなければ事前に与えた tool 以上の動作は不可能なので、それを持って予期しない動きはしない(すくなくとも予期しないAPI Callはしない)などとする整理も可能と思います。
さらに HITL(Human-in-the-Loop) によりユーザーの明示的な同意を通して認可を拡張していくような整理も 1st party AI Agent の場合は考えられるかもしれません。
いずれにせよリスクを最小化するため、 AI Agent に渡す権限はユーザーから delegate された、一定の操作のみ実行可能なものが望ましいです。
よりきめ細やかな認可への要求
同様に AI Agent はさまざまな操作を実行する可能性があるため、より限定されたリソース保護のため、現在の scope 単位の認可よりも細やかな認可制御を行いたい要求もあります。
このあたりは Rich Authorization Requests などの仕様も策定されているので、必要に応じて実装していくのがよいと考えています。
認可の delegate チェーン
AI Agent の実行は、別の AI Agent から呼び出されたり、ユーザーインタラクションを伴わない形で呼び出されたり、さまざまな実行シナリオがありえます。
このとき、どのように認可の移譲を受けるかが問題となります。
基本的には、ある AI Agent に必要な権限を確認した上で、その認可要求を上流の Agent ないしはユーザーに対して確認する形となると思います。
こちらも 1st party なら、動的な tool 定義がなければ必要な権限は事前に定義可能なので、その移譲を考えれば良さそうです。
将来的には権限の検出と委任の仕組みなどが OAuth などの標準仕様に含まれると嬉しいよね、というのが Microsoft Entra Blog で言及されています。
混乱した代理人問題(Confused Deputy Problem)
これは、実際には権限を持たないエンティティが、より強い権限を持つ別エンティティなりに依頼することで、本来行えない操作を実行できてしまう一般的な権限不備です。
AWSユーザーガイドでも言及されています。
この問題は AI Agent が絡んだシナリオでもありえます。権限を持たないユーザーが、より強い権限が割り当てられた AI Agent にタスク要求すると、場合によっては本来そのユーザーには行えない操作が実行可能となってしまいます。
これを避けるために、基本的には実際の操作が可能かどうかは「ユーザーの権限」と「AI Agent に許可された scope」の積集合として判定するのがよいと思います。
B2B SaaS での課題
ここからは B2B SaaS の業務領域ならではの認可にまつわる問題に触れていきます。
端的には「誰が認可を許可するべきか」「複雑な認可を担当者が正しく判断できるのか」「それが複数あったとき業務負荷はどうなるのか」あたりが課題です。
妥当な認可を従業員本人が行うのは困難な可能性がある
通常の OAuth 2.0 の認可コードフローにおける consent などでは、付与予定の scope などの内容をユーザーに確認、同意してもらうステップが挟まると思います。
B2B SaaS においては従業員が正しく認可の判断をすることが難しい場合もあります。
ある scope の許可を与えたとき、どのような操作が可能で、それがどの程度のリスクであるか、などを判断するためにはある程度システムへの理解が必要です。
意図した認可を適切に許可することは元々難しく、さらに従業員の中にはシステム利用頻度が少ないメンバーもいるため、数が増えていけば過剰な認可を許可してしまうケースなども一定数発生しえます。
管理者による認可の制御も設定面の課題がある
あるシステムを利用している際、それがあるツールなどにどこまでの認可を与えて良いか？を制御するモチベーションや責任があるのは、多くの場合従業員本人ではなくシステム管理者などの役割を持ったメンバーであるはずです。
実際 MCP の仕様おいても、認可の判断を管理者が中央集権的に設定した IdP に移譲するような仕様提案が出ていたりします。
また、このあたりはさらっと議論をさらうような記事も書いています。ご興味ある方はこちらもご覧ください。
管理者による中央集権的な管理は実際の統制の形と近く、高度な制御が可能です。
ただ、このような認可設定を中央集権的な設定に移譲するような仕様が策定されたとしても、実際に管理者がその設定をする際には設定の困難さがあると考えています。
中央集権的な設定を管理者が行う場合、どのようなユーザーに、どのようなツールで、どのような scope を許可するか、などを管理者が何らかの形で設定することになると思います。
これは管理者の負担が高いです。例えば、利用する AI Agent 機能が数百、数千に及んだ場合、これらの認可設定をすべて管理者が手動で行うのは現実的ではありません。
さいごに
バクラクが現在提供、または開発している AI Agent に関連する機能は幸いにも多くが 1st party のものかつリスクの大きい書き込み処理などを含まないものです。
そのためここであげた課題全てが現時点で問題になっているわけではありません。
しかし、バクラクシリーズは将来的には「業務の完全自動運転」をめざしています。
複数の AI Agent が協働して自動でタスク解決を行うような世界になっていくなら、このあたりの課題に一通りの回答を出すことが求められます。
まだまだ道のりは半ばですが、このあたり興味ある方いらっしゃいましたら、ぜひ一緒に解決していきたいです！！！
コメント