1Password for Agents、AIアシスタント向けにパスワードを保護したサインインを開始
1Passwordは10月22日、AIアシスタントがアカウントのパスワードをモデルに渡すことなくアクセスできる「1Password for Agents」を発表した。同社によれば、ユーザーが認証情報のリクエストを承認し、その後のサインインは1Passwordが直接処理する。これにより、ログイン情報を利用する許可と、秘密そのものの保持が分離される。
今回の発表は、パーソナルアシスタントにとって実務上の障害を対象としている。有用な作業の多くはログイン画面の先にある。その作業を委任するために、再利用可能なパスワードを会話に貼り付ける必要はないはずだ。ただし、パスワードを保護しても、認証済みアカウント内でアシスタントが実行できるすべての操作が自動的に制限されるわけではない。
AnthropicのClaudeおよびBrowserbaseとの以前の統合では、このアプローチの一部がすでに確立されていた。新しいプラットフォームは、その取り組みをパーソナルエージェント全体へと拡大する。認証情報の仲介を共通サービスにする点に意義がある一方、エージェント開発者には同様に重要な問いが残る。サインイン後の操作を誰が制御するのか、という点だ。
1Password for Agentsはサインインとパスワード共有を分離する
この製品は、再利用可能な秘密をアシスタントに委ねるようユーザーに求めるのではなく、エージェントがログイン画面を通過する方法を変える。
同社のエージェント向けサインイン発表によると、アシスタントは固有のデジタルキーを用いて1Passwordに自身を識別する。ユーザーは、どの認証情報が必要で、なぜ必要なのかを確認できる。承認はユーザーのデバイス上で行われ、その後1Passwordが対象フォームに入力する。
このプロセスでは、要求者に秘密そのものを渡さず、秘密へのアクセスを仲介するサービスである認証情報ブローカーが導入される。ここでエージェントはログイン操作を要求する。パスワードマネージャーが機密性の高い処理を実行し、認証後にアシスタントがタスクを継続する。
この区別は重要だ。パスワードは、元の依頼が終わった後も長く有効であり続ける可能性がある。そのパスワードを含む会話は、秘密を保護すべき新たな場所を生み出す。そのコピーを防ぐことは、基盤となるアカウントが通常のパスワード認証を使い続ける場合でも、露出を意味のある形で減らす。
また、これはユーザーが承認する対象も変える。パスワードの共有は、再利用可能な情報を移転する行為だ。仲介されたサインインの承認は、操作を許可する行為である。急いでいる場面では両者は似て見えるかもしれないが、セキュリティ上の結果は異なる。
同社は、自社プラットフォームをMeta、Anthropic、OpenAI、Grok Bot、Townのエージェントに対応させる位置付けを示している。このパートナー範囲は、認証情報を共通の保管庫に維持しながら、人々が用途ごとに異なるアシスタントを選べるようにするという、より広い戦略を表している。ただし、それは各アシスタントで利用可能性や保護策が同一であることを示すものではない。
この分離には、すぐに得られる使い勝手上の利点もある。アシスタントを切り替えるたびに、別のパスワード集を管理する必要はないはずだ。開発者にとっても、顧客にプロンプトへ秘密を貼り付けさせたり、別個の認証情報ストアを設定させたりするワークフローに代わる選択肢となる。
重要な留保は、これが依然として同社が説明するセキュリティアーキテクチャであることだ。この発表だけでは、すべてのパートナーおよびすべてのログイン失敗ケースにおいて独立した検証済みの保護があるとは示されない。読者は、パスワード分離の約束を、統合レベルの証拠を必要とする具体的な技術的主張として扱うべきだ。
プラットフォーム名も、普遍的な互換性を示すものと受け取るべきではない。対応統合では、エージェントのリクエスト、ユーザーの承認、サインイン操作が接続されていなければならない。ユーザーがすでに1Passwordにパスワードを保管しているからといって、任意のアシスタントが自動的にこの保護を得るわけではない。
この点で今回の発表は、単なる自動入力の利便性を超えるものだが、その範囲は理解しやすい。参加するエージェントがアカウントへ入るための制御された経路を作る。対象ウェブサイトの権限を置き換えるものでも、タスクの適切性を判断するものでも、アシスタントが正しく完了することを保証するものでもない。
パーソナルアシスタントではアカウントアクセスが重要な経路となる
エージェント開発者は現在、タスク実行能力と同じくらい明確にアクセスの扱いを説明するよう求められている。
旅行を計画できてもアカウントに入れないパーソナルアシスタントは、決定的な場面で依然として人間に依存する。アカウントのパスワードを要求するアシスタントは、別の問題を生む。ユーザーは利便性と、別のシステムによる機密情報の取り扱いを比較検討しなければならない。
認証情報の仲介は、この選択に別の道筋を与える。アシスタントは、パスワードの管理を専用サービスに残したままアクセスを要求できる。その結果得られる製品体験は、リクエストが理解しやすく、適切なタイミングで、実際にその人が割り当てたタスクと密接に結び付いているかどうかに左右される。
この発表は、パスワードマネージャーにも圧力をかける。その役割は、人々が認証情報を入力するのを支援することから、人のために動くソフトウェアが認証情報の利用をどう要求するかを決めることへと広がる。そこには、従来からの秘密保管という責務に加え、アイデンティティ、承認、統合の挙動が関わる。
ユーザーにとって、摩擦が生じる場所は変わる。アクセス判断は依然として必要だが、その判断のためにパスワードを開示する必要はないはずだ。判断の質は、アカウント、対象、要求するエージェント、目的を含め、提示される情報に左右される。
有用な承認プロンプトは、表面的には似たリクエストを区別できなければならない。保存済み注文を比較するためのショッピングアカウントへのアクセスと、配送情報を変更するためのアクセスは異なる。どちらの操作も同じログインから始まるとしても、ユーザーが意図する権限は異なる。
ここで商業的な期待とプロダクト設計上の制約が交差する。アシスタントは中断を減らすことを目指す一方、セキュリティ管理は意図的な停止を導入することが多い。すべての停止をなくせば、意味のある監督は弱まる。些細な操作ごとに承認を求めれば、委任の有用性は下がり、人々は内容を読まなくなる。
今回の発表は、この緊張を解消するものではない。開発者が認証情報に関する部分を一貫して扱える場所を作るものだ。より広範なワークフローが管理しやすく感じられるかどうかは、各エージェントがタスクの境界、予期しないリクエスト、重要な操作をどう扱うかにかかっている。
企業の購入者にとって、個人アカウントへのアクセスは所有権に関する問題も提起する。認証情報は従業員に属しながら、業務情報へのアクセスを可能にする場合がある。それは、消費者向けの統合が組織のポリシー、監督、記録保持の要件を自動的に満たすことを意味しない。
実務上の含意は、ワークフロー全体を評価することだ。保護されたログインには価値があるが、購入者はその後にどの情報が見えるようになるのかを理解する必要がある。また、操作をレビューできるか、状況の変化に応じてアクセスを停止できるかも知る必要がある。
この区別はナレッジワークにも当てはまる。個人ナレッジベースで情報を整理することは、アシスタントが何を取得し、理解できるかに関わる。アカウント操作を委任することは、行動する権限を追加するため、別個のアクセス判断を必要とする。
この追加の権限は、説得力のあるデモに求められる基準を変える。成功したタスクは、完了画面以上のものを示すべきだ。ユーザーが何を委任したのかを理解できる程度に、承認済みアカウントと操作の境界を可視化する必要がある。
共通のサインイン層は直接的な認証情報の受け渡しに挑む
中心となる争点は、仲介された認証情報の利用と、アシスタントに必要な秘密を直接渡すことの間にある。
これは主に、どのモデルが最も正確にページを操作できるかという競争ではなく、アーキテクチャ上の選択である。優れた推論能力を持つエージェントであっても、適切なアクセス経路を必要とする。推論が改善しても、再利用可能なパスワードの機密性は下がらない。
歴史的な背景は、なぜこの発表が今行われたのかを理解する助けとなる。2025年10月、1PasswordはBrowserbaseとともに、早期アクセス版としてSecure Agentic Autofillを導入した。この取り組みは、人間が承認した認証情報の提供をブラウザベースの自動化に適用し、リクエストするエージェントとパスワード処理を分離する先行例を確立した。
2026年7月のClaude認証情報統合は、この方向性をパーソナルアシスタント体験へと広げた。1Passwordは、セッションごとの承認、限定された保管庫アクセス、モデルの視界外での認証情報注入について説明した。また、失敗した送信後に制御を返す前に、入力済みの値を削除することも説明している。
こうした以前の制御は、「エージェントがあなたのパスワードを見ることはない」といった短い主張の裏にあるエンジニアリング作業を示している。サインインは途中で失敗することがある。ページが予期せず動作することもある。秘密を守るには、ユーザーが承認をクリックする瞬間だけを保護するのではなく、こうした遷移を扱う必要がある。
以前のClaude実装を、すべての新規パートナーを説明する近道にしてはならない。そこで文書化された保護は、その実装に属するものだ。他の統合についても、同一の制御がプラットフォーム全体に適用されると想定する前に、同等の詳細が必要となる。
この発表の背景には、もう一つの関連する動きがある。9月、1Passwordは、異なる認証方式のための共通インターフェースであるuniversal sign-inを導入した。認証とは、アクセスを許可する前にアカウント保有者のアイデンティティを確立することを指す。同社は、その取り組みを、承認されたエージェント主導のサインインに明確に結び付けた。
その関連性は実務的だ。すべてのウェブサイトが同じログイン手順を提示するわけではなく、一貫した仲介層は、各アシスタントが個別に処理しなければならない範囲を減らす。そのため、ユーザーが主にアシスタントの計画や応答に注目している場合でも、サインインのインフラはエージェント製品の一部となる。
BrowserbaseとClaudeは、このインフラにおける異なる文脈を表している。Browserbaseはブラウザ自動化を構築する開発者を支援し、Claudeはユーザー向けのアシスタント体験を提供する。これらの先行統合は、同じ認証情報分離の原則が、製品同士を同一視することなく異なる製品に役立ち得ることを示している。
直接的なパスワード受け渡しと比べた利点は明快だ。エージェントが秘密の新たな管理者になる必要はない。手作業による介入と比べた場合の潜在的な利点は、継続性にある。ユーザーはブラウザのワークフロー全体を引き継ぐことなく、認証情報の利用を承認できる。
それでも、他のアクセスアーキテクチャの余地は残る。サービスが狭く制限されたアプリケーション権限を提供している場合、その権限は完全なアカウントログインと並べて評価する価値がある。仲介されたパスワードは既存アカウントのアクセス問題を解決するが、すべてのタスクがアカウントの完全な権限を継承すべきだということを示すものではない。
より大きな含意は、アシスタントが共通のアクセスインフラに依存しながら、タスク実行で競争できることだ。この分担により、ユーザーは認証情報を管理する場所をより明確に得られる。一方で、仲介者とエージェントが広告どおりに境界を強制するかどうかに責任が集中する。
1Password for Agentsにとって、その境界こそが製品の中心的な価値である。アシスタントがタスクに必要なアクセスだけを正確に要求できるようになるほど、その有用性は高まる。認証情報層が何を制御し、何がエージェントの責任として残るのかを文書が明確にするほど、その信頼性は高まる。
パスワードを隠すだけでは、アカウント内の意思決定までは制限されない
パスワードの機密性と操作の認可は別の問題であり、アシスタントがアカウントを操作できるようになると、どちらも重要になる。
認可とは、識別された主体にどの操作を許可するかを決めることだ。ログインに成功すればアクセスは確立されるが、必ずしもアシスタントの操作をユーザーの意図した範囲に限定できるとは限らない。アカウントには、現在のタスクに必要な範囲を超える機能が用意されている場合がある。
例として、経費処理のワークフローを考えてみよう。ユーザーがアシスタントに対し、アカウントから領収書を収集してレポートを作成するよう依頼する。ログインパスワードをモデルの外部に置くことは、秘密情報を保護する。しかし、それだけでは、認証済みのインターフェースが許可している場合に、無関係なアカウント変更を防ぐことはできない。
この例は、新しいプラットフォームで報告された障害ではない。パスワード分離という主張には、正確な境界が必要であることを示している。ユーザーは、どの保護が1Passwordによるものか、どれがエージェントによるものか、そしてどれが接続先サービスに依存するのかを理解すべきだ。
AIシステムが指示として誤認する悪意あるコンテンツであるプロンプトインジェクションは、この区別を特に重要にする。アシスタントは、ページや文書を読む際にそのようなコンテンツに遭遇する可能性がある。セキュリティ上の問題は、そのコンテンツが、ユーザーが正当に許可したアカウント内の操作を誘導できるかどうかにある。
Zenity Labsによる以前のエージェントブラウザ研究では、このより広範な問題が検討された。研究者のStav Cohen氏は、信頼できないコンテンツを用いて、認証済みブラウザ環境内のPerplexityのCometを誘導する手法を説明した。研究チームは、緩和策についてPerplexityおよび1Passwordと協力したと報告している。
この研究は、以前のブラウザ環境のシナリオに関するものだ。10月のプラットフォームに欠陥があることを示すものではない。その重要性は脅威モデルにある。つまり、有害な活動は、まずパスワードマネージャーの暗号化を破らなくても、セッション内ですでに利用可能な権限を悪用できる。
1Passwordが1月に公開したブラウザセキュリティアドバイザリーも、関連する区別を示していた。同社は、エージェント、信頼できないコンテンツ、ロック解除された拡張機能が関与するエコシステム上のリスクを説明した。これらのリスクは、暗号技術、認証モデル、または保管庫の設計を破るものではないとしている。
アドバイザリーは、モデルによる解釈ではなくソフトウェアによって強制されるルール、すなわち決定論的な制御を重視した。ドメイン制限、確認要件、ロック動作がその例である。この原則が重要なのは、アシスタントが適切に行動するという約束は、越えられない境界より弱いからだ。
承認そのものも慎重に解釈する必要がある。人は、その後に続くすべての操作を予想せずにアクセスを承認することがある。アシスタントが計画を変更した場合、当初の許可が黙って無制限の同意へ変わるべきではない。認証情報の取り扱いが期待どおりに機能していても、明確なタスク境界は必要だ。
連携を切断することと、以前のアクセスによるあらゆる影響を終了させることにも違いがある。既存セッションや進行中のタスクに何が起こるのかについて、ユーザーには文書化された説明が必要だ。目に見える切断コントロールは有用だが、その存在よりも正確な効果のほうが重要である。
利用可能なローンチ資料は、新プラットフォームがプロンプトインジェクションや意図しないアカウント操作を排除したことを立証していない。また、パスワードをモデルの外部に置けば、その後に遭遇するすべての情報がそのモデルからも非公開になると、読者が推測すべきでもない。これらは別個の証拠を必要とする、より広範な主張である。
エンタープライズのセキュリティチームにとって、検証は観察可能な挙動に焦点を当てるべきだ。レビュー担当者は、要求したエージェント、承認済みアカウント、実行済みの操作を特定できるか。予期しない要求を拒否しても、無関係な作業を壊さずに済むか。タスクに問題が起きた場合、組織は何が起きたかを再構築できるか。
こうした問いは、認証情報の分離が持つ価値を維持しつつ、それを過大に解釈することを避ける。秘密情報の露出を減らすことは、それ自体に価値がある。操作の制限、理解しやすい承認、有用な記録と組み合わせることで、委任のためのより強固な基盤となる。
展開はパートナー一覧より限定的だ
プラットフォームの発表は、名前が挙がったすべてのエージェントを、今日すべてのアカウントで利用できることを意味しない。
同社の連携提供状況の詳細では、段階的な展開が説明されている。MuseおよびGrok Botとの連携は、今後数日間にわたって展開される予定だった。Claude Duet、ChatGPT Work and dots、Townとの連携は近日提供予定とされていた。
同じ投稿によると、プラットフォームは現在、1Password.com上のIndividualアカウントとFamilyアカウントをサポートしている。同社の欧州およびカナダのアカウントドメイン上のアカウントは、現時点ではサポートされていない。発表を直ちに評価しようとする人にとって、これらの利用資格の制限は重要である。
これらは職場での解釈にも関わる。業務で利用されるアシスタントを取り上げた発表が、すべてのビジネスアカウント構成での利用可能性を証明するわけではない。購入者は、パートナーロゴが自組織の導入状況を示すと想定するのではなく、利用資格を直接確認すべきだ。
同社はまた、保護機能と制御は連携ごとに異なると述べている。この留保には注意を払うべきである。なぜなら、プラットフォーム全体の約束から読者が導ける結論を限定するからだ。共通の認証情報管理があっても、承認の挙動、セッションの扱い、プラットフォーム対応が同一になるとは限らない。
これはデモンストレーションを比較する際に特に重要だ。特定のデバイスで示されたワークフローは、他の環境では利用できない機能に依存している可能性がある。評価すべき単位は、エージェント、アカウント、プラットフォーム、タスクの具体的な組み合わせである。
段階的な展開は、本質的に製品が弱い証拠ではない。ただし、発表された対応範囲と実際に利用できる対応範囲は区別し続ける必要がある。ロードマップは方向性を示すが、動作する連携は、顧客が実際の条件下でタスクを完了できるかを示す。
同社のイベント計画の例は、この概念を具体的に示している。Museが招待状や備品を手配する際、RSVPifyとOriental Tradingの承認済みログインを要求するという内容だ。これは、日常的な信頼性を独立して証明するものではなく、ベンダーが提示したシナリオである。
この例が有用なのは、認識しやすい目標の中で、複数のアカウント依存活動を伴うからだ。また、権限に関する判断がどこで生じるかも示している。招待状の作成、回答の確認、備品の購入は、同じイベントに属していても異なる結果を伴う。
製品評価はそこで具体的になるべきだ。重要なのは、ユーザーがアシスタントの進行を追跡し、いつ新たな判断が必要になるかを認識できるかどうかである。円滑なログインは、支出、情報共有、メッセージ送信に関する曖昧さを解消しない。
開発者にとって、この展開は実践的な連携上の課題を生む。ユーザーが何を承認したかを誇張せず、タスクの文脈をアクセス要求に結び付けなければならない。認証情報のプロンプトは、アカウントが許可するすべてへの汎用ゲートウェイではなく、アシスタントの実際の必要性を表すべきである。
ユーザーにとって、直近の要点も同様に具体的だ。まず意図した環境で連携が利用できることを確認し、次に承認体験を確認する。ローンチは新たなアクセス経路を提供するが、日常的な価値は顧客の目の前にある対応済み実装に依存する。
委任されたアクセスの進展を示す3つのシグナル
次に必要な証拠は、提供済み連携、独立したセキュリティテスト、完了した作業に対する可視的な制御から得られるべきだ。
最初のシグナルは、発表されたパートナー展開が実際に提供されるかどうかである。今後数か月間、近日提供予定とされた連携が、明確な利用資格とプラットフォームの文書とともに利用可能になるかを確認すべきだ。それは、認証情報の仲介が複数のアシスタントにわたって機能し得るという見方を強めるだろう。
顧客が連携の対応範囲を把握できなければ、提供だけでは不十分だ。有用なリリース情報では、対応する認証方式、必要なコンポーネント、既知の制限を区別する必要がある。こうした詳細をめぐる不確実性が繰り返されれば、エージェントアクセスを簡素化するというプラットフォームの主張は弱まる。
2つ目のシグナルは、障害条件下における認証情報の境界に対する独立テストである。サインインの成功は、基本的なワークフローが機能することを示す。セキュリティ評価では、送信失敗、予期しないリダイレクト、中断された承認、周辺インターフェースを通じた秘密情報露出の試みも調べるべきだ。
こうした移行の間も認証情報がエージェントの視界外に保たれるなら、テストは信頼を強めるだろう。保護が通常の障害状態を回避することに依存している証拠が見つかれば、実用上の主張は限定される。いずれの結果も、ローンチデモだけから推測することはできない。
3つ目のシグナルは、認証後にユーザーが何を制御できるかについて、より明確な証拠が示されることだ。タスクの制限、アクセスの取り消し、セッションの扱い、操作記録を説明する文書と製品挙動に注目すべきである。これらの詳細は、ログイン画面が消えた後も人々が委任を管理できるかを決定する。
この領域での進展は、パスワード保護だけを超える、より広範な信頼の提案を支えるだろう。ユーザーが自ら与える権限を理解し、制約できることを示すからだ。こうした制御が曖昧なままであれば、このプラットフォームは包括的なエージェントガバナンスではなく、主として認証情報の取り扱いに基づいて評価されるべきである。
これらのシグナルは、競合するアプローチを比較するための公平な基準にもなる。重要なのは、アシスタントがどれほど頻繁にユーザーへの中断を避けるかだけではない。アクセスに関する判断を理解可能に保ち、重要な権限を制限しながら、有用な作業を完了できるかどうかである。
そこには、意図的な摩擦の余地がある。アカウントに入る要求は一度の承認で適切かもしれないが、重大な結果を伴う操作には別の判断が必要になる。優れた委任は、あらゆる中断を製品の失敗として扱うのではなく、そうした瞬間を分かりやすくする。
1Password for Agentsは、業界が評価できる具体的なアーキテクチャを提示している。つまり、秘密情報はパスワードマネージャーに保持し、対応するアシスタントが承認済みの利用を要求できるようにするというものだ。ローンチの意義はこの分離にある。より広範な約束が実現するかは、パートナーがこれをどれほど一貫して実装し、その限界を説明するかにかかっている。
実際のアカウントタスクを委任する前に、プラットフォームのパートナー一覧に頼るのではなく、特定の連携を確認しよう。アカウントの利用資格を確認し、承認が何を許可するかを読み、アクセスがどのように終了するかを確認する。結果を確認できるタスクから始め、次にアシスタントが実際に何をしたのかを調べる。パスワード保護と、支出権限、メッセージ送信、アカウント変更に関する想定は分けて考えるべきだ。1Password for Agentsが拡大するにつれ、デモと並行して、提供済みの文書と独立テストを追う必要がある。有用な問いは具体的だ。アカウントを特定し、必要なアクセスを承認し、その後に続く作業を自分で制御し続けられるか。
