AI エージェントの委任 - 制御できないものを委任することはできません

私はエージェントの ID、認証/承認パターン、およびそれが既存のテクノロジーとどのように適合するかを掘り下げてきました (OAuth 2.0、OIDC、SPIFFEなど) そして、新しいソリューションが必要な場合。最近、誰かが私にアイデンティティと委任について、この分野の現実を少し照らしている点を指摘しました。

You can’t delegate what you don’t control.

つまり、AI エージェントは、認証基盤の亀裂や未定義の領域を、私たちがカバーできるよりも早く明らかにしています。

実際に何がうまくいっていないのかを見てみましょう。

アイデンティティはめちゃくちゃです - そしてそれは寛大であることです

Sarah が中堅企業のマーケティングマネージャーであると想像してください。彼女はラップトップにログインします (Active Directory/LDAP の使用).彼女はデータをレビューし、Salesforce と HubSpot でキャンペーンを実施しています。内部分析ダッシュボードから内部レポートにアクセスします。過去のどこかで、誰かが彼女に AWS S3 バケットへのアクセス権を与えて、プロジェクトのデータを移行しました。誰もそれを覚えていません。サラもおそらくそうではないでしょう。

だから誰ですサラ。

理論的には、AI エージェントが「サラに代わって」行動する場合、AI エージェントに彼女の権限を継承してもらいたいと考えています。しかし、それはシステムが理解する「サラ」の統一された概念があることを前提としています。

実際には、「Sarah」は半ダースのシステムに散らばっており、それぞれに独自のログイン、承認ロジック、およびロールがあります。彼女の正体は人ではなく、時間の経過とともに漂流/腐敗するアーティファクトのパッチワークです。委任できるクリーンなインターフェイスはありません。「サラに代わって行動する」とはどういう意味かについての首尾一貫した定義さえありません。

これが最初の構造的な問題です。

We don’t have real user identities

ID フラグメントがあり、エージェントはフラグメント間で明確に委任できません。

実際にアクセス権を所有しているのは誰ですか?誰も、みんな!

アイデンティティを超えて、より難しい質問をするとしましょう。

Who decides what an agent is allowed to do?

顧客データを取得します。営業部門が所有していますか?マーケティング。支える。合法。

各チームと無秩序なアプリケーションの拡大は、地域の決定を反映します。Sarah は 1 つのアプリで 5 ドルの購入を承認できます。別のものでは、50 ドルです。他の場所では、彼女にはまったく制限がありません。世界的な真実はありません。コード、API、スプレッドシート、部族の知識に組み込まれた一連の分断された承認の決定だけです。

では、Sarah に代わって顧客データにアクセスしたり、お金を費やしたり、キャンペーンを開始したりするエージェントを構築する場合、エージェントは何を継承するのでしょうか?誰が制限を設定しますか?

ほとんどの企業は、どのユーザーをリストできます有るリソースへのアクセスはほとんどありませんが、説明できる人はほとんどいません なぜでしょうか 彼らはそれを持っているか、そのポリシーがどこで定義されているか、または誰がそれに責任を負っているか。

これが2番目の大きな問題です。権限が管理されていない.また、誰もアクセス権を所有していない場合、どうすれば安全に委任できるでしょうか?

エージェントは、私たちが準備ができていない規模でIAMを壊します

3番目の問題は、正しさではなく、規模の問題です。

IAMシステムは、人間の世界のために設計されました。人事部は毎月数人の従業員を追加します。もしかしたら請負業者が参加するかもしれません。資格情報は、人間が処理できるサイクルでプロビジョニングおよび取り消されます。

ここで、AI システムが毎時何千ものエフェメラル エージェントを起動する世界を想像してみてください。各エージェントには、API の呼び出し、サービスへの認証、データベースからの読み取り、およびシステムの更新を行うための資格情報が必要です。それらのほとんどは数分しか生きません。開発者、マーケティング担当者、サポート担当者向けの AI コパイロットは、すべてのツールに組み込まれています。これらのエージェントは、ただ読むだけでなく、行動します。そして、彼らはあなたが与えたすべての許可を試します.

既存のIAMシステムでは追いつくことができません。シークレットは十分に速く発行できません。そして、たとえできたとしても、静的で有効期間の長いパスワードを渡してもらいたいですか?資格情報が残ります。失効が遅すぎます。最悪なのは、どのエージェントがべきそもそもできる。

私たちは、人間規模のツールを使用して、機械規模の問題を解決しています。それはうまくいきません。

では、どこから始めればよいのでしょうか?

これらすべてにもかかわらず、組織は缶便利で安全な AI エージェントを今すぐ構築してください。しかし、範囲については戦略的である必要があります。

単一システムの偽装から始める

現時点で最も実用的なアプローチは、単一のシステム内にとどまることです。エージェントがユーザーの資格情報を継承し、使い慣れたガードレール内で作業できるようにします。

たとえば、エンジニアの Kubernetes トークンは、デバッグ エージェントで使用できます。営業エージェントは、ユーザーの Salesforce ログイン情報を使用してリードを更新できます。DBA は、データベースの既知の制約内で動作する最適化エージェントを起動できます。

派手な委任はありません。システム間の ID ステッチはありません。1つの信頼できる境界内の実用的な価値だけです。

マルチシステムエージェントへの段階的な拡張

組織が自信を築くにつれて、これらの境界を広げることができます。

マーケティングエージェントが、SarahのSalesforceトークンを使用してリードを取得し、HubSpot認証情報を使用してキャンペーンを実行し、Google Analyticsアクセスを使用してレポートを生成するとします。

はい、それはまだ資格情報の無秩序な拡大です。しかし、それはうまくいきます。また、既存の認証境界を尊重しながら、すぐに価値を提供します。私が働いている solo.io では、これをよりクリーンにするためのソリューションに取り組んでいます。

準備ができたら、後で委任を目指します

最終的には、企業がIAMプラクティスを成熟させるにつれて、真のクロスシステム委任をサポートできるようになります。つまり、一貫性のある ID、管理された承認、スケーラブルな資格情報管理、コンテキスト認識ポリシーが実現します。

しかし、それはあなたが始めるものではありません。それです あなたが稼ぐもの 基本的な問題を最初に解決することによって。準備ができたら、興味深い委任パターンがいくつかあります (OAuth RFC 8693) 分散されたアイデンティティと委任 (MCP-I) それは役立つかもしれません。