AIエージェントにパスワードを見せずにログインを任せると、何が守られ、何が残る？ 1Password for Agentsで分ける「秘密・ログイン・操作権限」の3つの境界と、用途別の選び方（2026年10月時点）
2026年10月22日に発表された1Password for Agentsを、公式資料・仕様・論文で照合。「パスワードを見せない」が守るのは秘密の閲覧だけで、ログイン後の閲覧・操作、Webセッション、OAuthトークンは別に残ります。3つの境界、方式の比較、Gmailスコープの例、用途別の選択表、依頼文、終了時の片付けまでまとめました。
文・ニコ
2026年10月22日、1Passwordが「1Password for Agents」を発表しました。AIエージェントがログイン画面で止まったとき、パスワードを見せずに1Passwordが代わりに入力してくれる仕組みです。
便利そうですよね。でも、ここでちょっと立ち止まりたい。ログインできたあとは、どこまで任せていいんでしょう？
「パスワードを見せない」と「ログインしたあとの操作を絞る」は、別の話です。
この記事では公式資料と仕様、論文を読み比べて、何が守られて何が残るのかを整理します。用途別の選び方や、そのままコピーできる依頼文、やめるときの片付け手順も用意しました。
対象は自分のアカウントをAIエージェントにつなぎたい人。非エンジニアの人にも読めるように、用語はそのつど説明します。
先に結論です。
- 守られるのは「秘密の閲覧」。 パスワードやワンタイムコードを、モデルに渡さず入力できます。
- 残るのは「ログイン後の権限」。 ログインできたエージェントは、そのアカウントで見られるものを見て、できる操作を行えます。公式FAQも、ログイン後の振る舞いは「エージェントとサイト次第」と書いています。
- 終わったあとも、別々に残るものがある。 連携の切断、サイトのセッション、OAuthトークン、取得したデータは、それぞれ別に片付けます。
なお、この記事は公式資料と原典の整理が中心です。実アカウントでの攻撃や購入、送信、削除の実験はしていません。製品の安全性を保証する記事ではないことは、先にお伝えしておきます。
何が発表されたの？（2026年10月23日時点）
公式発表の要点はこうです。
- AIエージェントがログイン画面に着くと、1Passwordへ資格情報を要求する。
- あなたが自分の端末で、どのログインを使うか見て、承認か拒否を選ぶ。
- 承認すると、1Passwordがパスワードやワンタイムコードをページへ直接入力する。エージェントは「アクセスが許可された」ことだけ分かる。
- 提供は1Password.comのIndividual / Familiesアカウントに追加料金なし。1Password.eu / 1Password.caのアカウントは現在未対応。
出典：Introducing 1Password for Agents、製品ページとFAQ
「追加料金なし」は1Passwordの個人・家族プランに含まれるという意味です。1Password自体の契約や、つなぐエージェント側の利用料までタダという意味ではありません。
どのエージェントで使える？
まだ「全部すぐ使える」わけではありません。発表時点の表現はこうでした。
| 連携先 | 発表時点の表現 |
|---|---|
| Meta Muse | 数日かけて全プラットフォームへ順次展開 |
| SpaceXSI Grok Bot | 数日かけて全プラットフォームへ順次展開 |
| Anthropic Claude Duet | coming soon |
| OpenAI ChatGPT Work / dots | coming soon |
| Town Townie | Web / iOS連携がcoming soon |
| Browserbase、Browser Use、Perplexity、Ramp ほか | 追加の連携先として名前が挙がっている（coming soon） |
つまり、今日から使える可能性があるのは、順次展開と書かれたMuseとGrok Botの2つです。ほかは「予定」。全員に行き渡ったかどうかも、公式資料だけでは確かめられませんでした。
地域についても注意があります。公式が書いているのは「1Password.eu / .caは未対応」という保存先ドメインの条件です。「欧州に住んでいる人は全員ダメ」「日本なら必ず使える」とは書いていません。連携先の製品側にも、国・プラン・端末・サインイン方法の条件があります。たとえばMuse本体はMetaの発表では米国で始まり、Connectの公式記事では米国・カナダ・メキシコで提供と説明されています。日本での提供は日本語の初回発表で未定とされていました（Museの日本語発表）。使う前に、使いたいエージェントの公式ページで今の状況を確認してください。
3つの境界に分けて考える
「AIにログインを任せる」とひとまとめにすると、話がこんがらがります。3つに分けましょう。
境界1：秘密の閲覧
パスワード、ワンタイムコード、APIキーといった値を、だれが読めるか。
見落としやすいのは、読める場所がチャット欄だけではないことです。ツールの戻り値、会話履歴、スクリーンショット、画面のDOM、操作の録画、ログ。どこかに値が出れば、そこが漏れ口になります。
「入力欄が黒丸だった」だけでは、ほかの経路から読めないことの証明にはなりません。たとえば既存のMac向け「1Password for Claude」は、入力して送信するあいだ、エージェントの画面観測そのものを止めると説明しています。黒丸で隠すだけとは、守りの深さが違います（公式の説明）。
境界2：ログインの成立
サイトが「この人は本人だ」と認めて、ブラウザーがログイン済みになった状態です。
ここが盲点です。エージェントがパスワードを知らなくても、ログイン済みのブラウザーを動かせるなら、その本人としての権限を使えます。OWASPは、ログイン後のセッションIDは、有効なあいだはパスワードに近い強さを持つ情報だと説明しています（OWASP Session Management）。
境界3：ログイン後の操作権限
何を読めるか、変えられるか、どこへ送れるか。サイトの役割、OAuthのスコープ（許可範囲）、つないだツールの機能、実行前の承認で決まります。
1Passwordが主に守ろうとしているのは、境界1です。境界2と3を守るには、別の仕組みを考える必要があります。
| 確認したいこと | 聞くべき質問 | それだけでは分からないこと |
|---|---|---|
| 秘密が見えない | パスワードを返すツールはあるか。入力中の観測は止まるか | ログイン後に何を読み、何を変えられるか |
| ログインが承認制 | どのアカウントを、どの要求で許可したか | 購入や送信のたびに人が確認するか |
| 操作が限定される | 読み取り専用などを、サーバーやツールが強制しているか | 許可したデータの読み違い、持ち出し |
| 失効できる | 接続解除やトークン取消で何が止まるか | すでに保存・送信されたデータが消えるか |
1Password for Agentsで、実際に起きること
流れを図にするとこうです。
公式FAQで、押さえておきたい点が3つあります。
1. 保管庫が丸ごと渡るわけではない。 接続しただけでは、全項目は見えません。エージェントはタスクのためにログインを1件要求し、あなたが承認するかを決めます。
2. 承認の頻度は連携ごとに違う。 公式FAQは「承認を求める頻度は連携によって変わる」と書いています。「サイトを移るたび」「購入のたび」に承認が出る、とは読めません。
3. ログイン後はエージェントとサイト次第。 FAQには「ログインしたエージェントは、アカウント内の情報を見たり、操作したりできる場合がある」とあります。承認する前に、タスクとアカウントを見直してね、という注意書きまで添えられています。
もうひとつ、発表文の「unique digital key」にも触れておきます。これは、エージェントが自分の身元を1Passwordに示すための鍵です。この鍵があっても、そのエージェントがあなたの意図どおりに動いている証明にはならないんです。
承認できるのは「ログイン」まで？
Museについては、1Password側のFAQがログインの許可とは別に、購入やメール送信のような機微な操作でMuseが確認すると説明しています（Muse向けFAQ）。既存のClaude連携の公式デモ動画でも、ログイン時のTouch IDと、Audibleのクレジットを使う前の確認は別の段階として出てきます（デモ、18〜28秒と48〜56秒付近）。
ただし、これは「その連携の提供者がそう説明している」ことです。すべてのエージェントがすべての送信・購入・削除を止めてくれる証拠にはなりません。
「新方式」と「既存方式」を混ぜない
ここ、情報が混ざりやすいので整理しておきます。
「専用」と名のつくものは、分けるものが違う
| 言葉 | 分けるもの | 分けないもの |
|---|---|---|
| 専用保管庫 | 参照できる秘密の集合 | 入っているログインの、サイト内での権限 |
| 1Passwordサービスアカウント | 保管庫へのプログラムからのアクセス | ログイン先サービスでの役割 |
| ログイン先の専用アカウント | 読めるデータ、残高、所属、役割 | そのアカウントで許した操作の誤用 |
| 専用エージェント・Bot | 役割や指示 | ブラウザー状態を共有していれば、ログイン状態は分かれない |
実例があります。Grok Botの公式ドキュメントによると、利用者のBotはクラウドコンピューターを共有し、Cookie、ログイン済みセッション、ファイル、CLIの資格情報まで共有します。1つのBotでログインすると、ほかのBotも同じセッションを使えます（Use the computer and apps）。Botを分けただけでは、認証状態は分かれません。
「サービスアカウント方式」も一括りにできない
1Passwordのサービスアカウントは、アクセスできる保管庫を選んで、項目を取得する仕組みです。取得した値をそのままエージェントへ返す作りなら、モデルにも見えます。
一方、Browserlessは1Passwordの参照をサーバー側で解決して入力し、値を自動化コードへ返さない実装を説明しています（Browserless）。仲介先やトークンの保管先は増えますが、「保管庫＋トークン」＝「平文がモデルへ渡る」とは限りません。
比べるべきは名前ではなくだれが秘密を復号して、どこへ渡し、どの経路を閉じているかです。
既存の1Password for Claudeとは別物
2026年8〜9月に説明が公開された既存の「1Password for Claude」は、Mac、1Passwordのブラウザー拡張、有料Claudeプラン、Claude in Chromeなどが必要な、Mac向けの連携です。Loginの項目を扱い、パスキーなど他の項目は未対応と説明されています（利用手順）。
この条件や、次の技術詳細（9時間の上限など）を、10月22日発表のクラウド型の新連携にそのまま当てはめてはいけません。
公開されている仕組みと、残る「信頼する相手」
既存のClaude連携については、仕組みがかなり詳しく公開されています。
| 境界 | 公式に説明されている内容 |
|---|---|
| アプリの識別 | OSのコード署名と信頼するアプリの一覧で確認。初回ペアリングは人が承認 |
| セッションの識別 | セッションごとの暗号鍵で要求を認証。ほかのセッションの許可は流用しない |
| 許可 | 人が選んだ項目だけを、そのセッションへ許可。要求の理由は信頼済みの事実として扱わない |
| 入力 | 保存済みサイトに一致するページへ入力。入力・送信中はエージェントの観測を停止。失敗時は値を消してから制御を返す |
| 時間と記録 | 作業完了、ブラウザー終了、最長9時間で資格情報のキャッシュを破棄。許可は項目の使用履歴に記録 |
出典：About the security of 1Password for Claude。この「9時間」は資格情報キャッシュの上限で、ログイン先のCookieの寿命ではありません。
ここまで丁寧に作られていても、信頼する相手はゼロになりません。ログイン先のサイト、そのページで動くスクリプト、あなたの端末、ブラウザー、仲介アプリは、信頼の前提として残ります。1Passwordの公式文書にも「Accepted risks」として、端末や提携アプリの侵害までは防げないとはっきり書かれています。
また、「秘密」はパスワードだけではありません。ログイン後の氏名、住所、購入履歴、メール本文が画面に出れば、エージェントはそれを読めます。
ログイン仲介とOAuthは、守るものが違う
方式を6つの軸で比べてみます。特定製品の実測ではなく、設計としての比較です。
| 方式 | 秘密の露出 | 対象・操作の限定 | 人の承認 |
|---|---|---|---|
| パスワードをチャットへ直接渡す | モデル・履歴・ログへ入る道を自分で作る | ログイン先アカウントの権限そのまま。「〜しないで」という文面は強制にならない | 渡した時点だけ |
| 人が引き継いでログイン | 観測停止などが働けば露出は減る | 再開後は、ログイン済みの権限そのまま | ログインは人。送信や購入の制御は別 |
| 専用保管庫から値を読むツール | 値を保管庫の外へ出す。モデルへ返す実装なら見える | 参照できる秘密は絞れる。サイト内の権限は縮まらない | 取得時・操作時の承認は別 |
| 認証仲介（Agentic Autofill） | 値をモデルへ返さない設計。仲介・端末・宛先は信頼する | 使うログインを選べる。ログイン後の役割はサイト次第 | 資格情報の利用の許可。頻度は実装次第 |
| OAuthの公式API連携 | パスワードの代わりにトークン。トークンも秘密 | スコープなどを提供側が強制できる範囲で限定 | 接続時の同意が基本。API実行ごとではない |
| ログイン先の専用アカウント | 認証方法による | データ・役割・残高を実際に小さくできる | 接続・操作の承認は別に設計 |
| 既存のログイン済みブラウザーを使う | 新しい入力が要らず、認証済みの状態をそのまま使う | そのプロファイルに残る、ほかのサイトにも注意 | 新たな承認なしで進むことがある |
専用アカウントはほかの方式と組み合わせて使う対策です。どちらか片方だけを選ぶ、という話ではありません。
OAuthなら何を絞れる？ Gmailの例
OAuthは対応サービスのAPIへのアクセス権を委任する仕組みです。ブラウザーのログインフォームへパスワードを入力するのとは、そもそも仕組みが違います。Gmailのスコープで具体例を見ましょう（Google公式のスコープ一覧）。
| スコープ | 公式の説明 | 間違えやすい点 |
|---|---|---|
gmail.readonly | メールと設定の閲覧 | 送信はしないが、本文の秘密性は残る。「指定した1通だけ」という制限でもない |
gmail.send | 代理での送信 | 宛先や件名の条件は、スコープ名だけでは縛れない |
gmail.compose | 下書きの管理と送信 | 「composeだから下書きだけ」とは限らない |
gmail.modify | 読取・作成・送信など。ゴミ箱を経ない即時の永久削除は含まない | 「永久削除できない」≠「変更しない」 |
https://mail.google.com/ | 読取・作成・送信・永久削除 | 作業に対して広すぎないか確認 |
OAuthでも残るものはあります。
- トークンがモデルから見えなくても、連携サーバーはその権限を使える。
- Bearerトークンは「持っている人が使える」性質がある（RFC 6750）。
- 読み取り専用トークンがあっても、書き込めるブラウザーを同時に渡せば、別の道から操作できる。制限はその作業で使える経路全体で評価する。
- 接続を解除しても、すでに取得されたデータが消えるとは限らない（Googleの説明）。
ログインの承認と、操作の承認は別
「ログインを許可した」は「そのあとの操作もぜんぶ許可した」ではありません。では、何を承認したことになるのでしょう？ 具体的に言葉にしてみます。以下は説明用の架空の例です。
| 承認 | 内容の例 | この承認だけでは許可しないこと |
|---|---|---|
| 連携の接続 | このエージェントが1Passwordへ要求できる | 保管庫全体の閲覧 |
| ログイン | shop.exampleのテスト用アカウントでログイン | 注文、支払い、住所変更、退会 |
| 閲覧 | 指定した注文1件の配送状況を見る | 注文履歴の全件保存、別サイトへの送信 |
| 送信 | この宛先に、この件名・本文・添付で1通 | 宛先追加、添付の差し替え、後日の一括送信 |
| 購入 | この商品・数量・送料込み総額・配送先で注文 | 別商品、定期購入、予算超過 |
| 削除 | このテストデータ1件を削除 | フォルダー全体、アカウント削除 |
ぼくなら、承認画面には次の情報が欲しいです。これは筆者としての提案です。
- だれが要求したか（エージェント、実行）
- 何をするか（対象、送信先、数量、合計、添付）
- いつまでか（今回1回か、期限つきか）
- 何が変わったら再承認か（宛先・金額・対象・添付）
OpenAIのComputer Useの説明には、実装する側への指針もあります。モデルの実行要求は人の許可ではないこと、承認中に画面が変わりうることが説明されています（Computer use integration recipes）。
「聞いてね」と「できない」は違う
チャットに「買う前に聞いて」と書くのは役に立ちます。でも、購入ツールを無効にすることとは別物です。Grok Botの公式説明はAsk first / Allow automaticallyなどの設定を案内する一方で、Auto Reviewはモデルによる判断なので最小権限の代わりにしないでね、と書いています（Grok Botの承認設定）。
確認の回数を増やすより、権限でできない操作を減らして、残る重要な操作で「何をするか」が分かる確認を出す。このほうが、承認の意味を判断しやすいはずです。これも運用上の提案で、疲れにくさを測ったわけではありません。
研究は何を示している？ 製品の評価には使えない
エージェントへの攻撃を扱った研究は、いくつもあります。ただし、1Password for Agentsを検証した報告ではありません。 攻撃者の権限、モデル、評価環境、成功の定義が違うので、数字を足したり平均したり、製品の危険率に置き換えたりしてはいけません。
読んだのは7本です。
- AgentDojo（NeurIPS 2024）：メールや銀行などの模擬環境で、取得データ中の命令による誘導を評価する枠組み。
- WASP（2025、arXiv:2504.18575）：Web環境へ命令を混ぜる84条件。Table 2の最大値は中間の乗っ取り85.7%、最終達成16.7%（o1のTool Calling・system条件）。
- WebInject（EMNLP 2025）：ページの画素への摂動で、スクリーンショットを読むエージェントを誘導。文字の命令以外にも攻撃面があることを示す。
- MUZZLE（2026、USENIX Security 2026採択版）：4つのWebアプリで44の攻撃、アプリ横断の攻撃や偽の認証画面への誘導を報告。
- LoginTrap（2026、プレプリント）：80の複製ページ、1,175タスク。「続けるにはログイン」を装う。Browser-Useの4モデルで、平均のログイン誘導率93%、情報入力までの成功率86%。保管庫や認証仲介から秘密を盗んだ実験ではありません。
- CaMeL（2025）：信頼する依頼からデータの流れを追跡して、ツール呼び出しを制約。AgentDojoでタスク達成77%（無防御84%）。「安全率77%」ではありません。
- ceLLMate（2025/2026、プレプリント）：ブラウザー層で許可を強制。GitLabでの12攻撃を阻止した事例。許可された範囲の内容の悪用は防げません。
ここから持ち帰れるのは「数字」ではなく「どの層が何を助けて、何が残るか」です。
| 脅威・失敗 | 秘密を渡さない仕組みが助ける部分 | 残るもの |
|---|---|---|
| プロンプト・ログへの流出 | 値を会話の経路から外す | 仲介・端末・宛先サイトの侵害 |
| 偽ログインページへの誘導 | 保存URLとの照合、人の確認が防御になる | 偽の理由に人が同意すること。正規サイトの侵害 |
| ログイン後の情報持ち出し | パスワードの窃取経路は減る | 読んだ情報を別サイトへ送る道 |
| 正規アカウントでの誤送信・誤購入・削除 | 秘密を知らなくても起きる | サイトの権限、ツール、操作直前の承認 |
| 承認した操作の対象のすり替え | 仲介だけでは扱わない | 引数の固定と再照合、期限、再承認 |
| 別Bot・後日の実行での再利用 | 資格情報の許可は分離できる場合も | 共有ブラウザー、保存プロファイル |
Googleの公式ブラウザーの設計も、同じ方向です。ChromeのSecurity記事（2025年12月）は、ページ内容から隔離した監視役、アクセスしてよいoriginの制限、重要な操作での確認を重ねる設計を説明しています。ログイン時のパスワードマネージャーの確認と、購入・送信時の確認も別々です（Chromeの設計説明）。認証仲介、権限、データの行き先、実行前の承認は、同時に使う別々の制御です。どれか1つあれば済む、というわけではありません。
用途別の選び方
作業をこなせる最小のアクセスから選びます。以下は製品の安全性ランキングではなく、筆者なりの整理です。
| やりたいこと | 最初に検討する接続 | 人が引き受ける部分 | 終了後 |
|---|---|---|---|
| 公開商品の価格・仕様を比べる | 接続なしの公開Web | 会員価格や購入が必要になったら再判断 | ダウンロードの整理 |
| カレンダーを読んで候補日を作る | 対応する読み取り専用OAuth | 招待の送信は別承認 | 不要な継続アクセスを取り消す |
| メールの要点を整理する | 公式連携、または必要な箇所だけ渡す | 外部への送信・転送・共有 | 取得済みコピーと連携を確認 |
| メールの下書きを作る | チャット内で文案づくり。送信ツールは使わせない | 宛先・本文・添付を見て本人が送る | 下書きと取得データを整理 |
| APIがないサイトで配送状況を確認 | 認証仲介、または観測停止つきの引き継ぎ | 取消・返品・住所変更は別判断 | ログイン状態の寿命を確認 |
| 買い物の候補選び | 公開Web。必要なら専用アカウント＋認証仲介 | 注文確定前に総額・数量・配送先を確認 | 注文結果と不要なセッションを確認 |
| SNS投稿を準備 | 接続なしで原稿づくり | 公開・予約投稿は別承認 | 予約の有無を公式画面で確認 |
| 重要データの整理・削除 | 読み取りで候補一覧まで | 対象と復元方法を決めて本人が実行 | 件数・復元可能性を照合 |
| 銀行・医療・パスワードマネージャーの管理 | 公開情報や匿名化した資料で相談 | 本人確認、送金、重要設定の変更 | 各サービスの手順に従う |
| 長期・無人での定期確認 | 対象限定で取消できる公式連携が条件 | 権限追加と重要操作で停止 | 定期実行と認可を別々に解除 |
専用アカウントを作るときは、サービスの規約で認められているか確認してください。本人確認が必要なサービスに架空の人物を登録するのはやめましょう。
終わったあとに、何が残る？
作業が終わっても、「セッション」と名のつくものは1つではありません。
公式資料を読んだ範囲では、1Passwordの連携を解除すると、ログイン先サイトの既存セッションがすぐ全部切れる、という共通仕様は確認できませんでした。 「切れない」と断言するのではなく、「別に確認が必要」と扱うのが安全です。
やめるときは、次の順に片付けます。画面の名前はサービスごとに違うので、存在しない設定を推測で触らないでください。
- 実行中のタスクと、不要な定期実行・予約を止める。
- 使わないエージェント連携を切断して、将来の資格情報の要求を止める。
- ログイン先の公式アカウント管理画面で、エージェントが使ったセッション・デバイスを確認して、不要なものを終了する。
- OAuthなら、認可元のアプリ管理でも権限を取り消す（Googleでの接続管理）。
- 不要な保存プロファイル、ダウンロード、生成物を整理する。提供者側のデータ削除が別に必要なこともある。
- 必要な記録だけ、秘密を含めずに残す。パスワードや生のCookie、トークンを貼らない。
OAuthの取消仕様（RFC 7009）も、更新トークンやアクセストークンの扱い、反映の遅れを規定しています。「ボタンを押した瞬間に全アクセスがゼロ」とは限りません。
接続する前の確認票
分からない項目は「不明」のままで大丈夫です。不明が多いなら、個人情報の多いアカウントをつなぐ前に、作業を公開情報や文案づくりに狭めましょう。
| 項目 | 記入欄 |
|---|---|
| エージェント製品・プラン・端末 | |
| 今回の作業と、ログインが必要な理由 | |
| 接続方式と、公式説明のURL | |
| 1Passwordの保存先ドメイン／連携先の対応地域 | |
| 対象のアカウント・役割・データ | |
| パスワード・コード・トークンをモデルへ返す経路の有無 | |
| 接続以外に使えるブラウザー・ツールの経路 | |
| 実行前に止める操作と、承認する具体的な対象 | |
| 別Bot・別タスクと共有するブラウザー状態 | |
| タスク・認証・サイトセッションの期限 | |
| 接続解除・トークン取消・セッション終了の場所 | |
| 取得データ・記録の保存先と削除方法 |
本物のアカウントなしで試せる4つの確認
実アカウントを危険にさらす必要はありません。以下はぼくが考えた手順案で、自分で実行して安全性を確かめたものではありません。
確認1：接続せずに方式を見分ける。 連携の公式説明と設定画面の説明だけを読み、「サービスアカウントのトークンを登録」「1Passwordアプリで要求を承認」「同意画面でスコープを選ぶ」のどれかを記録します。方式が分からなければ「不明」で止めます。読むだけでは、実装が説明どおり動くことまでは確かめられません。
確認2：OAuthの同意画面を読むだけで終える。 最終同意は押さず、要求されている範囲を「閲覧」と「送信・変更・削除」に分けて書き出します。文案づくりだけなのに送信権限を求められたら、接続を完了しません。
確認3：承認を紙の上で練習する。 外部サービスを使わず、架空の操作（閲覧、送信、購入1,200円、削除）をエージェントに表へ分類させます。依頼例です。
これは紙上演習です。ブラウザー、API、外部送信ツールは使わず、実行もしないでください。ログインだけ承認された状態だと仮定して、次の4つの操作に必要な追加確認を表にしてください。購入額が後から1,800円になった場合も説明してください。
- 架空の注文fixture-order-001の配送状況を読む
- reviewer@example.invalid へ、架空の下書きを送る
- 架空商品Aを1個、1,200円で購入する
- 架空のメモfixture-note-001を削除する
「購入額が変わったら、前の承認は流用しない」と答えられれば合格です。ただし、正しく答えられても、実際のツールが止まる証拠にはなりません。
確認4：片付けの場所を探す。 5つの時計（作業・連携・Webセッション・OAuth・データ）それぞれの管理画面が、公式ヘルプで見つかるかを確認します。見つからないものは「不明」。サイトの全セッション終了はほかの端末にも影響するので、確認のためだけに押す必要はありません。
すぐ使える依頼文
製品の権限設定の代わりにはなりません。あくまで、依頼の仕方の提案です。
閲覧を任せるとき
目的は［対象1件］の［必要な情報］を確認することです。対象サービスは［ドメイン］、使うアカウントは［用途名］です。パスワードやコードを会話に貼るよう求めず、対応する認証仲介か、本人への引き継ぎを使ってください。送信、購入、削除、設定変更、別サービスへの転記はまだ許可していません。必要になったら、対象と内容を示して止まってください。終了時は、実行結果と、残っている接続・ログイン状態を確認できた範囲で報告してください。
文案だけを任せるとき
［目的］のメール文案を、この会話内に作ってください。外部の送信ツール、投稿ツール、ブラウザーでの送信操作は使わないでください。宛先、件名、本文、添付候補を分けて、未確認の宛先や事実を明示してください。送信は私が行います。
購入の準備を任せるとき
［商品条件］を比べて、候補と送料込みの総額を示してください。注文確定、支払い、定期購入の登録はまだ許可していません。候補が固まったら、販売者、商品、数量、総額、配送先、支払い方法、取消条件を示して止まってください。条件が変わった場合は、以前の承認を流用しないでください。
まとめ
- 1Password for Agentsが守るのは、秘密を見せないこと。ここは大きな前進です。
- でも、ログインしたあとの閲覧・操作、サイトのセッション、OAuthのトークン、取得したデータは、別の確認が必要です。
- 選ぶときは「いちばん安全な方式」を探すより、作業に必要な最小のアクセスから考える。ログインが要らない作業なら、つながない。
- 重要な操作は権限で絞ったうえで、「何をするか」が分かる承認を別に置く。
- 終わったら、連携だけでなく、セッションとトークンとデータも片付ける。
配布状況も条件もこの数日で動いています。使う前に、使いたいエージェントの公式ページと、手元の提供状況を確認してください。
調べたこと・調べていないこと
この記事は2026年10月23日時点の公式資料、RFC、OWASP、Googleの公式説明、論文7本の本文・書誌を照合して書きました。1Passwordの公式発表、FAQ、既存Claude連携のセキュリティ説明は、本文を取得し直して確認しています。
やっていないことも書いておきます。
- 実アカウントの接続、パスワード・Cookie・トークンの取得、攻撃の追試、送信・購入・削除はしていません。
- 新連携全体の独立監査や、各連携先の配布版の実機確認はしていません。
- 「1Passwordの解除で既存セッションが切れるか」「承認が購入や削除を確実に止めるか」「監査ログの項目と保持期間」は、公開資料で確認できませんでした。
- 論文の数字はそれぞれの実験条件での結果です。1Passwordの新連携が破られる確率ではありません。
- 動画は公式の2本の字幕で確認した範囲だけ使っています。スポンサー動画や字幕を取れなかった動画は、根拠にしていません。