AI エージェントはただのアプリです：ID 管理を複雑にしすぎていませんか？
本記事はCDataが提供する「CData Software Blog」に掲載された「AI エージェントはただのアプリです：ID 管理を複雑にしすぎていませんか？」を再編集したものです。
AIエージェントを安全にデプロイする上で最大の課題は、ハルシネーション（AIが事実でない情報をもっともらしく生成してしまう現象）ではありません。ID（アイデンティティ）管理です。もっと正確に言えば、業界がそれを一から作り直そうとする衝動が問題なのです。
2023年に企業がエージェントの実験を始めると、この課題を表す新しい用語が登場しました。「非人間アイデンティティ（NHI: Non-Human Identity）」です。アイデアはシンプルでした。エージェントがデータを読み取り、メッセージを送信し、アクションを実行できるなら、エージェント自身のIDが必要なのではないか、というものです。しかし、このシンプルなアイデアが複雑な問題を生み出しました。
・IDの主体はユーザーなのか、エージェントなのか？
・エージェントは IAMシステム（Identity and Access Management：ID・アクセス管理システム）に独自のアカウントを持つべきなのか?
・エージェントがファイルを削除したり、Slackに投稿したりした場合、誰が責任を負うのか？
エージェントを保護するための取り組みとして始まったものが、いつの間にか間違った問題を解決するためのインフラのカテゴリになってしまいました。この記事では、エージェントが人間の代わりに行動するシナリオ、または人間がループに介在するシナリオに焦点を当てます。
エージェントのIDが本当の問題ではない理由
ユーザーの代わりに動作するアプリケーションのパターンはすでに存在しています。OAuth、SSO（Single Sign-On）、委任認可は成熟しており、広く採用されています。アプリがアクセスを要求し、ユーザーが許可を与え、IDは明確なままです。
問題は、エージェントに新しいIDモデルが必要だということではありません。エージェントとは何か、を誤解していることが問題なのです。
エージェントがユーザーよりもアプリケーションに近い理由
エージェントはデータを所有しません。直接認証することもありません。アクセスポリシーも持っていません。
代わりに、エージェントは入力を受け取り、判断を下し、アクションを要求します。この意味で、エージェントは私たちが何十年もデプロイしてきたアプリとそれほど変わりません。唯一の本当の変化は推論レイヤーです。アプリは決定論的（同じ入力には必ず同じ出力）ですが、エージェントはそうではありません。
各エージェントに独自のIDを割り当てるというアイデアは安全に聞こえるかもしれませんが、解決するよりも多くの問題を生み出します。エージェント固有の資格情報を管理し、非人間のためのIDポリシーを適用し、IAMの階層を見直す必要があります。複雑さはあっという間に膨れ上がります。
エージェントに独自のIDを割り当てると何が起こるか
エージェントをID主体として扱うと、多くの場合、2つの結果を招きます：
1. 権限の肥大化（Privilege Creep）：エージェントが機能するために広範なアクセス権を与えると、ユーザーが見るべきでないデータを読み取ったり変更したりできるようになってしまいます。
2. IAMの無秩序な拡大（IAM Sprawl）：すべてのエージェントやエージェントインスタンスにIDを作成すると、管理、監査、廃止が困難な数十（または数百）のアカウントが生まれます。
どちらの場合も結果は同じです。エージェントは必要以上の権限を持ち、セキュリティチームは可視性とコントロールを失います。
さらに悪いことに、エージェントはLLM駆動であるため、本質的に従来のアプリよりも予測が困難です。過剰な権限を与えることは、リスクを増大させるだけです。
過剰なアクセス権限の簡単な例
社内サポートエージェントがJiraに接続し、従業員がチケットの状態を確認したり新たな課題を作成したりするのを助ける場合を想像してください。あなたはJiraにアクセスするためのサービスアカウントを付与します。すべてが問題なく動作します。 誰かが「すべてのオープンチケットを見つけてクローズして」とプロンプトを入力するまでは。エージェントはその命令に従います。数秒で数百のチケットがクローズされ、ユーザーの帰属も承認ステップもありません。
問題はプロンプトではありませんでした。エージェントに過剰なアクセス権があり、境界がなかったことが問題だったのです。IDベースモデルは、制御された実行経路だけで十分だったにもかかわらず、テーブルに座る席を与えてしまったのです。
エージェントのアクセスを実行時に制御すべき理由
本当の問いは「このエージェントは誰か？」ではありません。こうです：
「このユーザーの代わりに動作するこのアプリは、このリソースに対してこのアクションを実行できるか？」
そして、その答えはIDプロバイダーからではなく、実行レイヤーから得られるべきです。
これが、ほとんどの最新アプリケーションの動作方法です。Gmailアドオンは認証情報を取得しません。Slack連携はあなたになりすましません。委任されたアクセスを要求し、特定のアクションを実行し、標準的な認可フローに依存します。
エージェントも同じように動作すべきです。
既存のアプリケーションパターンがIDを正しく管理する方法
エンタープライズアプリはすでにこの問題を解決しています：
・Salesforce連携はOAuthスコープを使用して、アプリが必要なものだけにアクセスすることを保証します。
・Slackボットは、特定のチャネルやメッセージタイプにスコープされたトークンを使用して動作します。
・Google Workspaceアドオンは、ユーザーが付与した権限で動作しますが、ユーザーのパスワードを受け取ることはありません。
すべてのケースで、アプリはユーザーの代わりに動作し、アクセスは権限によって仲介されます。アプリに新しいIDを割り当てることによってではありません。
では、なぜ私たちはエージェントを別の扱いにするのでしょうか？
それは、エージェントが自律的に感じられるからであり、実際に自律的であることもあるからです。言語を生成し、主体的に行動します。しかし舞台裏では、ワークフローをオーケストレーションしているだけです。つまり、エージェントはユーザーではなく、アプリなのです。
このモデルは理論上のものではありません。エージェントはアプリケーションのように動作すべきであり、別のIDを持つべきではないという考えは、エコシステム全体で検討されてきました。Connect AIはこの基盤の上に構築されており、エージェントが安全に、大規模に、ユーザーレベルの制御で運用されなければならないエンタープライズ環境で実用的なものにしています。
Connect AIがアプリケーションモデルを適用する方法
Connect AIはエージェントをあるがままに扱います。つまり、アプリケーションとして扱います。IDを割り当てません。QueryDataやExecuteProcedureなどのツールを使用して実行をスコープし、エージェントではなくユーザーに紐付けられた資格情報を使用してアクションを実行します。
・エージェントはSalesforceの資格情報を管理しません
・モデルはJiraのアクセストークンを見ることがありません
・実行は安全で監査可能なAPIを通じて行われます
・権限は接続レベルで定義されます
これによりIDは明確に保たれ、権限昇格の攻撃対象領域が縮小され、IAMスタックを再定義する必要がなくなります。
ユーザーがSalesforceへの読み取りアクセスのみを持っている場合、そのエージェントはレコードのクエリのみが可能で、更新や削除はできません。ユーザーのJira接続に課題のトランジション権限が含まれていない場合、エージェントはその境界を超えて行動することはできません。これらのポリシーはエージェントではなく接続に存在し、実行時に適用されます。
Connect AIが本番環境でこのモデルを適用する方法
Connect AIはすでに、各ユーザーに紐付けられたOAuthベースおよびPAT（Personal Access Token）ベースのアクセスをサポートしています。データソース固有の権限を一度設定すれば、すべてのエージェントがツール実行を通じてそのルールを継承します。
さらに、データソースレベルでのユーザーベースの権限に加えて、Connect AIはエージェントが見たり実行したりできることをさらに細かく制御することをサポートしています。ユーザーのJira権限が削除を許可していても、Connect AIアカウントは読み取り専用に制限できます。近日中に、ACLの適用やデータ仮想化などの機能により、IDモデルを変更することなく、行、列、アクションレベルでエージェントが見たり実行したりできることを制御できるようになります。
これにより、以下のような関心の明確な分離が実現します：
・IDはユーザーに帰属
・推論はモデルに帰属
・実行はConnect AIに帰属
開発者、セキュリティチーム、プラットフォームオーナーが知っておくべきこと
開発者向け：IDの問題を解決する必要はありません。ツールを呼び出すだけです。ユーザーがサインインし、Connect AIが権限を処理し、エージェントがワークフローを安全に実行します。保存されたシークレットはありません。スコープダウンされたAPI トークンもありません。エージェントのロジックにIDロジックをハードコードする必要もありません。
セキュリティチーム向け：新しいIDを作成する必要はありません。エージェントに資格情報を割り当てる必要もありません。接続レベルでアクセスを管理し、Connect AIに境界を適用させればよいのです。
プラットフォームオーナー向け：IAMの無秩序な拡大を回避し、リスクを削減し、より速く出荷できます。Connect AIは、ポリシー適用を一から作り直すことなく、可視性とコントロールを提供します。
Connect AIでエージェントをアプリケーションとして扱う
IDの問題をもう一度解決する必要はありません。適切な境界で適用するだけでよいのです。
Connect AIは、IDをユーザードメインに保ち、実行をアプリケーションドメインに保つことで、これを実現します。この分離こそが、エージェントのデプロイメントをスケーラブルで、監査可能で、安全なものにするのです。
非人間アイデンティティを乗り超える準備はできましたか？Connect AIでエージェントの構築を始めましょう。新しい IAMの仕組みは不要です。14日間の無償トライアルでCData Connect AIをぜひご体感ください。
※本記事はCData US ブログ Agents are Just Apps: Stop Overengineering Identity の翻訳です。