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つの結果を招きます：
権限の肥大化（Privilege Creep）：エージェントが機能するために広範なアクセス権を与えると、ユーザーが見るべきでないデータを読み取ったり変更したりできるようになってしまいます。
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 などのツールを使用して実行をスコープし、エージェントではなくユーザーに紐付けられた資格情報を使用してアクションを実行します。
これにより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 の翻訳です。
