承認後に1Passwordがログイン情報を入力
1Passwordは、AIエージェントが利用者のパスワードを見たり受け取ったりせず、ウェブサイトへログインできる「1Password for Agents」を発表しました。エージェントがログインを求めると、利用者は必要な認証情報と用途を確認し、自分の端末で許可するかどうかを選びます。
許可された場合、1Passwordがログインフォームへ認証情報を入力します。パスワードやワンタイムコードはエージェントに送られず、ログイン後も保管庫全体へのアクセス権は与えられません。
エージェントは、固有のデジタルキーで1Passwordに自身を識別させてから、ログインを要求します。利用者は要求ごとにログイン情報を選んで承認でき、連携はいつでも切断できます。
MuseとGrok Botから順次対応
提供開始時の対応エージェントは、MetaのMuseとSpaceXSIのGrok Botです。両者の連携は複数のプラットフォームで順次展開されます。
AnthropicのClaude Duet、OpenAIのChatGPT Workとdots、TownのTownieも連携先として挙げられています。これらは発表時点で「近日対応」とされ、Browserbase、Browser Use、Perplexityなどの企業も追加連携に向けて参加しています。
1Password for Agentsは、1Password.comのIndividualおよびFamilyプランで追加料金なしで利用できます。1Password.euと1Password.caのアカウントは現時点で対象外で、利用可能な機能や設定条件は連携先によって異なります。
OAuthの権限委任とは仕組みが異なる
OAuthは、ウェブサービスなどが提供する保護されたリソースへのアクセスを、利用者の同意に基づいて別のアプリへ委任する枠組みです。AIエージェント向けの拡張案では、利用者の同意画面にエージェントと要求する権限の範囲を示し、承認後にエージェントへ委任アクセストークンを発行する流れが提案されています。
この拡張案のトークンには、利用者、エージェント、連携アプリの識別情報を記録し、誰の権限をどのエージェントが使うかを追跡できるようにします。保護対象のサービス側は、その委任トークンを受け入れて検証する必要があります。
別のOAuth拡張案は、認可要求にtarget_idを加え、許可対象となるエージェントやモデルを特定する方法を提案しています。これらの案が想定するのは、対応する認可サーバーやリソースサーバーを介した権限委任です。一方、1Password for Agentsは、ウェブサイトのログインフォームへ保存済みの認証情報を入力する方式です。そのため、OAuthのようにサービス側で権限範囲を制御する設計と、既存のログイン情報を使ってエージェントのサインインを仲介する設計では、仕組みが異なります。
ログイン後の操作には別のリスクも
パスワードを見せない仕組みでも、ログイン後のエージェント操作まで制限するわけではありません。OWASPは、エージェント向けリスク評価で、ツールの誤用やアクセス制御違反、複数エージェントの連携による問題などを主要なリスクとして挙げています。
この評価では、エージェントが外部ツールやリソースを使う際、ツールの仕様を悪用されたり、出力を誤って解釈したりする可能性もリスク要因に含めています。目標や指示の操作も、エージェント固有のリスク分類の一つです。
ブラウザーを操作するエージェントを調べた研究では、ウェブページ上の信頼できない内容がエージェントの挙動を乗っ取り、認証情報の流出につながる攻撃が報告されています。研究者はオープンソースのBrowser Useを分析し、プロンプトインジェクションやドメイン検証の回避、認証情報の窃取を示しました。これはBrowser Useを対象にした研究結果であり、1Password for Agents自体の検証結果ではありません。
