AIエージェントがあなたのCRMにログインし、データベースからレコードを取得し、あなたに代わってメールを送信する必要があるとき、そのアイデンティティは誰のものを使っているのだろう？そして誰も答えを知らないとき、どうなるのか？ Corridorの最高製品責任者アレックス・スタモスと、1PasswordのCTOナンシー・ワンが、エージェント的AIの恩恵とともに生じる新しいアイデンティティ・フレームワークの課題を掘り下げるため、VB AI Impact Salon Seriesに参加した。
「大まかな話としては、このエージェントが誰に所属しているか、どの組織に属しているかだけでなく、このエージェントがどの権限のもとで行動しているか、それが認可とアクセスへとつながる」という趣旨だとワンは述べた。AIにも同じダイナミクスが現在起きていると彼女は付け加えた。「エージェントにも秘密、つまり人間と同じようなパスワードがある。」
1Passwordがエージェント・アイデンティティ問題の中心へと至った経緯
ワンは、1Passwordがこの領域へ踏み込む道のりを同社の製品履歴を通じて辿った。同社は消費者向けパスワード管理ツールとして始まり、従業員がすでに信頼しているツールを職場に持ち込むことで、エンタープライズにおける足跡が自然と拡大していった。
「一度その人たちがインターフェイスに慣れ、私たちが顧客に提供するセキュリティとプライバシーの基準を本当に高く評価してくれた後、それを企業に持ち込むようになった」と彼女は述べた。AIにも同じダイナミクスが現在起きていると彼女は付け加えた。「エージェントにも秘密、つまり人間と同じようなパスワードがある。」
社内では、1Passwordは顧客が対処するのと同じ緊張感を管理している：エンジニアがセキュリティの混乱を生まずに迅速に動けるようにする方法。ワンは、エンジニアが Claude Code や Cursor のようなツールを使う際、AI生成コードとインシデントの比率を積極的に追跡していると述べた。これは、私たちが質の高いコードを生成していることを確認するために強く注視している指標だ。
開発者が直面する主要なセキュリティリスク
スタモスは、Corridorが観察する最も一般的な行動の一つは、開発者が認証情報を直接プロンプトに貼り付けてしまうことであり、これは巨大なセキュリティリスクだと述べた。Corridorはそれを検知して開発者を適切な秘密情報管理へ戻す。
「標準的なやり方は、APIキーを取得するか、ユーザー名とパスワードを取り、それをプロンプトに貼り付けるだけだ」と彼は述べた。「私たちはこれをいつも見つける。私たちはプロンプトを拾う形で連携しているからだ。」
ワンは1Passwordのアプローチを、出力側で機能させ、書かれるコードをスキャンしてそのまま保存される前にプレーンテキストの認証情報を秘密情報保管庫に格納することだと説明した。システムアクセスの切り貼り文化の傾向は、摩擦を生むセキュリティツールを避けるという1Passwordの設計選択に直接影響している。
「使いにくい、ブートストラップが難しい、オンボーディングが難しい場合、それはセキュアにはなりません。正直なところ、人々はそれを回避して使わなくなるからです」と彼女は述べた。
コーディング・エージェントを従来のセキュリティスキャナーと同列に扱えない理由
セキュリティエージェントとコーディングモデル間のフィードバックを構築する際の別の課題は、誤検知（false positives）であり、非常に友好的で協調的な大型言語モデルはこの傾向に陥りがちです。残念ながら、セキュリティスキャナーからのこの誤検知は、コード作成の全セッションを脱線させることがあります。
「これを欠陥だと伝えると、はい、それは完全な欠陥です」とスタモスは述べた。しかし彼は付け加えた。「正確性と検知のトレードオフは重要だが、誤検知を起こさせてしまうと、それを伝えあなたが間違っているときには、正しいコードを書く能力を完全に損ねてしまうことになる。」
この精度と再現性のトレードオフは、従来の静的解析ツールが最適化を目指すものとは構造的に異なり、スキャンあたり数百ミリ秒程度の待機時間を満たすよう正確に機能させるには多大なエンジニアリングが必要だった。
認証は簡単だが、認可は難題が多い
「エージェントは通常、環境内の他のどのソフトウェアよりもはるかに多くのアクセス権を持っている」とResolve AIの創業者兼CEOスピロス・ザンサスはイベントの以前のセッションで指摘した。「だからこそセキュリティチームがそれを非常に懸念するのは理解できる。もしその攻撃ベクトルが利用されれば、データ流出を引き起こすだけでなく、攻撃者に代わって何かを実行できる可能性がある。」
自律的エージェントに、範囲を限定し、監査可能で、時間制限のあるアイデンティティをどう付与するのかと、ワンは指摘する。コンテナ環境向けに開発されたワークロード・アイデンティティ標準のSPIFFEとSPIREを候補として挙げ、エージェント的文脈での適用を試していると語った。ただし適合にはまだ難があることを認めた。
「私たちは丸穴に四角い杭を無理やりはめ込んでいるようなものだ」と彼女は述べた。
しかし認証は半分にすぎない。エージェントが資格情報を得たら、それが実際に何を許すのか。ここで最小権限の原則は、役割ではなくタスクに適用されるべきだ。
「建物内のすべての部屋にアクセスできる鍵カードを人間に渡したいとは思いませんよね」と彼女は説明した。「エージェントに、王国の鍵、すべてを永遠に実行できるAPIキーを渡したくもありません。それには時間制限があり、かつそのエージェントにさせたいタスクに結びついている必要があります。」
企業環境では、範囲を制限したアクセスを付与するだけでは不十分で、どのエージェントが、どの権限のもとで、どの資格情報が使われたかを知る必要がある。
スタモスは、OIDC拡張を現在の標準化対話の最有力候補として挙げ、独自ソリューションの群は却下した。
「専有特許を持つソリューションが勝者になると信じているスタートアップは50社ほどある」と彼は言った。「ちなみに、それらは決して勝ちません。おすすめはしません。」
10億人のユーザー時代、エッジケースはもはやエッジケースではない
消費者側では、アイデンティティ問題は信頼できる提供者の少数に集約されると予測される。おそらくすでに消費者認証を支えるプラットフォームが中心になるだろう。FacebookでCISOを務めた経験を踏まえ、日々約70万件のアカウント乗っ取りを処理していたチームの事例を引き合いに出し、スケールがエッジケースの概念に与える影響を再定義した。
「10億のユーザーを持つ企業のCISOであるとき、コーナーケースは実際の人間に害を及ぼす事象を意味する」と彼は説明した。「したがって、通常の人々、エージェントにとって、今後のアイデンティティは途方もない問題になるだろう。」
結局、エージェント側のCTOが直面する課題は、エージェント・アイデンティティの標準が不完全であること、即興的なツールの使用、そして企業がエージェントをフレームワークより速く展開していることで生じる。今後の道は、エージェントが実際に何であるかを前提に、ゼロからアイデンティティ・インフラを構築することであり、人間が作ったものをそれに合わせて後付けするのではない。
