エージェント AI の認証: マシン ID のファンハウス ミラー

マシンのアイデンティティからキーのスプロールまで: ラブストーリー

むかしむかし、マイクロサービスの台頭と 5 回目の CI/CD の書き換えの間のどこかで、私たちは人間以外のすべてのプロセスに独自の秘密が必要であると判断しました。それで私たちは義務を負いました。CI パイプライン、サーバーレス関数、ステージング環境、インターン生のテストスクリプトはすべて、トークン、API キー、OAuth フロー、YAML のねじれを取得しました。ハードコードされることもあります。時々注射されます。いつも少し大ざっぱです。

当然、エントロピーが引き継がれました。鍵が広がっていた。秘密が流出した。トークンの有効期限は静かに切れました。ブレイクグラスのアカウントが新しい常態になりました。Vault や AWS Secrets Manager などのシークレットマネージャーは良いスタートであり、動的シークレットや IAM 統合アクセス制御などの機能で大幅に成熟しました。しかし、多くの組織では、秘密をローテーションし、ローテーターをローテーションし、最終的にはローテーションスケジュールを管理する人を雇うという、認証情報の墓場のままです。それでも、先週、誰かが .env ファイルを GitHub にコミットしました。

クラウドベンダーは、ワークロードIDフェデレーション

エージェントの登場: ID サーフェスが 10 倍に増えました

これだけでは混沌としていないかのように、エージェント AI が登場します: LLM を活用したソフトウェア エンティティは、タスクを計画、推論、連鎖させ、API、SaaS ツール、クラウド、内部システム全体でますます即興で行うものです。すべては、テニスボール工場のゴールデンレトリバーの戦略的な衝動制御によるものです。

これらのエージェントは自律的に動作します。SharePoint から契約書を取得し、Box をスキャンし、Salesforce を更新し、Zoom 通話をスケジュールします。1つのチェーンで。5つのシステムにまたがる。日曜日に。このビジョンはほとんどの組織にとって依然として野心的なものですが、AutoGPT、Adept、CrewAI などのプロジェクトからの初期実装はその方向に向かっています。

各インタラクションにはアイデンティティが必要です。では、これらのエージェントに何を与えているのでしょうか?長寿命トークン?広範囲の API キー?誰かが2019年のOktaログイン?

エージェントはアイデンティティの表面を拡張するだけではありません。彼らはそれを形作り変えます。彼らはなりすまし、ドメインを横断し、何かを行うためにジャストインタイムアクセスを必要とします。 そうすれば、彼らが存在したことを忘れてください.IAMではなくなりました。OAuthを小道具クローゼットとした即興演劇です。

IAM ベンダーが静かにパニックに陥っている理由

従来のIAMおよびPAMソリューション

シークレットマネージャーは、ストレージには優れており、ポリシーの適用は向上しますが、AI エージェントが Salesforce の高権限 API を呼び出す必要があるかどうかについての動的な実行時の決定には設計されていません (削除を考える_ユーザ、リセット_請求_設定) 午前2時

また、Terraform、YAML、ACL、OAuthフローですべてを接続したとしても、エージェントがラインの外側に色を付けた瞬間に壊れる脆い仕掛けになってしまいます。

実際に何が難しいのかを話しましょう

これは、マシン認証の単なる再起動ではありません。難しい問題は非常に実践的です。

• エフェメラル認証フロー: エージェントはタスクスコープです。彼らの資格もそうであるべきです。しかし、短命で範囲が狭いクレデンスは、オーケストレーションの複雑さを増します。トークンを失い、文脈を失います。そのライフサイクルを確実に管理することは、エンジニアリングと研究の継続的な課題です (たとえば、SPIFFE/SPIREを参照してください。).
• クロスクラウドトラスト: エージェントは Azure で起動し、GCP にホップしてから AWS に到達する場合があります。ほとんどの組織は、3 つすべてでライブ フェデレーション ID に設定されていません。OIDCは役立つはずですが、実装のギャップ、トークンオーディエンスの不一致、標準化されたメタデータの欠如により、これは決してスムーズではありません。フェデレーションのサポートはさまざまです: AWS STS と GCP の ID フェデレーションは、常にうまく機能するとは限りません。
• なりすましのリスク: エージェントはMFAを行いません。ログインパターンが変わってもIT部門にメールは送信しません。誰かがトークンを盗んだり、IDを偽装したりしても、人間が気付くことはありません。継続的認証や動作異常検出などの新しいソリューション (例: スタック ID、パンサー) 有望ですが、まだ普及していません。
• ゼロトラストの適用: 私たちは「決して信頼せず、常に検証する」と言いますが、多くの場合、「一度検証すれば、それが起こったことを忘れる」という意味です。ほとんどのポリシーは、ドメイン間でエージェントを追跡しません。そして、ログが存在する間 (AWS CloudTrail、GCP 監査ログ)、OpenTelemetry や eBPF ベースのトレースなどのツールは、マルチクラウドの物語をリアルタイムで観察できるようにし始めたばかりです。
• プロトコルスパゲッティ: OAuth 2.1 (2025年半ば現在も草案中) 一部のフローは単純化されますが、代理委任やトークン交換などの高度なパターンは標準化が不十分です。開発者は、Google、Microsoft、カスタム SaaS API などのプロバイダー間で脆弱なグルー ロジックを作成することになります。

では、実際に何が機能するのでしょうか?

Venture Guides では、YAML ファイルに MFA をボルトで固定しても安全ではないため、秘密の保管庫や脆弱なサービス アカウントを超えるプリミティブを模索してきました。エージェントが自律的に動作する場合、エージェントのIDモデルも同様に動的である必要があります:一時的で、コンテキストに応じ、リアルタイムで管理されます。

有望なアプローチの 1 つは、ID をエージェントに渡される静的な BLOB としてではなく、その場でネゴシエートされるランタイム コントラクトとして再考することです。システムは、環境変数、シークレットストア、またはCIパイプラインの8番目のステップに事前に認証情報を挿入する代わりに、エージェントが何をしているか、どこで実行されているか、何に触れようとしているかに基づいて、スコープ付きの短命のアクセストークンを鋳造します。これは、CSV エクスポートではなく、ストリーミング API としての IAM のようなものだと考えてください。

このモデルでは、エージェントは長命の秘密を保持することはありません。実行時にアクセスを要求し、クラウド、オーケストレーターなどのインフラストラクチャが信頼できる情報源として機能します。エージェントがキーを知っているため、ID は付与されません。システムがエージェントを知っているために付与されます。

また、プロキシがエージェントとターゲット サービスの間に配置され、リアルタイム ブローカーとして機能するモデルも見られました。これらの付き添いは、その場でポリシーを適用し、インテントをログに記録し、アクセスを取り消すことができます。従来のAPIゲートウェイやサービスメッシュとは異なり、これらはTCPやJWTヘッダーだけでなく、IDと権限のレイヤーでスタックの上位で動作します。リクエストを転送することではありません。誰が尋ねることができるかをフィルタリングすることです。

そして、はい、サービスメッシュの世界は有用なインスピレーションを与えてくれます。SPIFFE/SPIRE、OPAを使用したEnvoy、ゼロトラストネットワーキングはすべて、何が可能かを示唆しています。しかし、多くの場合、均質な環境での東西の交通に焦点を当てます。エージェントシステムは、即興的で、境界を越え、時には野性的であるというその仮定を打ち破ります。

野生では、生命の初期の兆候がいくつか見られます。

• OAuthフローとトークンのジャグリングを抽象化するミドルウェアで、エージェントが認証について推論する必要がまったくありません。
• リアルタイムコンテキストに関連付けられたスコープ付きの一時的な認証情報を発行する ID ブローカー — 静的構成や認証情報の残留はありません。
• インフラストラクチャをIDのルートとして扱うワークロードを意識した信頼システム - デプロイの開始時ではなく、実行のエッジでアクセスを鋳造します。

ここでのパターンは秘密のローテーションではありません。それは資格情報の回避です。構成ではなく計算としての ID。

ガムテープではなくポリシー。取り消しではなく推論。

これはセキュリティだけではありません。それは建築です。

エージェントのアイデンティティを解決することは、単なる防御手段ではありません。これは規模の前提条件です。正しく行えば、エージェントは次のようになります。

• 最小限の特権で操作する
• クリーンな監査証跡を残す
• 脆弱なスクリプトなしでシステム間で認証
• アクセスが拒否されたときに正常に失敗する

そして、あなたは得ます:

• アラートの削減
• 接着剤コードの削減
• より一貫性のあるポリシー
• 起動をブロックするセキュリティレビューの減少

それは建築衛生です。アイデンティティは、AIとインフラの間の契約になります。

未来との争い

エージェントAIが登場 (少なくとも、差し迫った).それが引きずり出すアイデンティティの混乱も同様です。しかし、私たちは以前にも、クラウド、コンテナ、マイクロサービスでここにいたことがあります。教訓は同じです:パラダイムシフトをガムテープで乗り越えることはできません。

インフラの次の波は、より多くの秘密を保存することではありません。それは、必要な数を減らすことです。理解するシステムについて 誰が と尋ねていますが、 なぜでしょうかで、 どれぐらいの時間ですか.

Rego/OPA、Cedar などのコードとしてのポリシーフレームワーク (AWSから)、およびザンジバルのようなモデル (Googleから) ID が静的なアクセス許可 BLOB ではなく、動的でクエリ可能な構造として扱われる場合に何が可能かをヒントにします。Cedar はきめ細かなポリシーの施行に焦点を当て、Zanzibar はリレーショナル アクセスをモデル化していますが、どちらもリアルタイム計算としての ID への移行を表しています。

そう、未来を築いてください。エージェントが誤って削除しないように注意してください。