冒頭は記事のために生成したイメージ映像です。実機、実在施設、観測データを示すものではありません。
AI Agentへbrowserを渡す。
そう聞くと、Web pageを開き、buttonを押し、formへ入力するための「目と手」を貸す話に見える。
けれど、loginした瞬間から、browserはもっと重いものを持つ。
Password、cookie、session token、privateなaccount画面。そのaccountで投稿し、購入し、設定を変えられる権限。
Agentへbrowserを渡すことは、目を貸すことではない。本人として動ける鍵束を渡すことだ。
そう考えると、Agent用browserの選び方は変わる。
起動が何millisecondか。Playwrightが使えるか。一時間いくらか。それだけでは足りない。
その鍵束を誰が見られるのか。どのprogramが動いていると確認できるのか。鍵を一つ落とした時、どこまで入られるのか。仕事が終わった後、本当に片付くのか。
2026年8月、Reclaim Protocolがopen sourceで公開したAgent向けbrowser基盤「Popcorn」は、この問いをかなり鮮明にした。
「私たちは見ません」から、「動いているものを確かめる」へ
8月9日の発表によれば、Popcornは必要な時だけ隔離されたChromium sessionを立ち上げ、Agentのbrowser操作や人間へのhandoffに使える基盤だ。自分でhostするためのcodeと、同社が運用するhosted fleetの両方が示された。
珍しいのは、便利なbrowser操作より、browserが動く場所を主役にしたことだ。
Reclaimは、login中のbrowserがcredentials、cookies、session tokensを持つ以上、通常のbrowser cloudでは運営者がmachineを管理していること自体がriskになると説明する。そこでbrowserをTrusted Execution Environment、TEEと呼ばれるhardware隔離環境で動かし、attestationで何が実行されたかを確かめる設計にした。
TEEを、絶対に破れない箱だと考えると誤解しやすい。
ここでの役割は、browserがdataを実際に使っている最中、そのmemoryをhost OSやcloudの周辺から隔離すること。そしてattestationによって、「対応したconfidential hardware上で、期待したimageが動いている」という証拠を外から検証できるようにすることだ。
Google Cloudの公式資料も、attestationをAttester、Verifier、結果を信頼判断へ使うRelying Partyの連鎖として説明している。
規約を信じるだけの関係へ、machineが出す証拠を足す。
Popcornが示した変化は、ここにある。
Open sourceになったから、安全──ではない
ただし、「open source」「TEE」「attestation」という言葉を三つ並べても、安全は自動で完成しない。
2026年8月20日、公開repositoryのHEAD commitを取得し、code構成とsecurity documentを静的に確認した。
repositoryには、browser sessionを割り当てるpool manager、複数regionへ振り分けるcontrol plane、接続をrouteするgateway、sessionを期限切れにするcontroller、attestation用sidecar、Helm chartまで含まれている。
一方、同projectのattestation documentは、かなり大事な境界も明記している。
attestationはoptionalで、localのKind quickstartでは無効。
対応するGCP/GKEのconfidential computing基盤と、digestで固定し署名したimageが必要。
proof endpointが200を返しただけでは不十分。nonce、時刻、runtime image、attestor image、GCP token、hardware claimsを検証しなければならない。
そしてPopcorn OSSは、complete policy verifierを同梱していない。
最後の一点は特に重要だ。
attestationは、証明書のようなものを出せば終わりではない。何を正しいimageとして受け入れるか。誰の署名を信頼するか。古いproofの再利用ではないか。接続している相手と、証明されたsessionが本当に同じか。
それを判定する側が必要になる。
Googleのconfidential application解説も、attestation JWTだけではexfiltrationやreplayへ備えきれず、sessionとのbindingや期待するworkloadとの照合が要ると説明している。
証拠を出せることと、その証拠を使って接続を止められることは別である。
2026年8月20日時点のrepository確認に基づく。同じPopcornでも導入経路で安全性が異なる。 図を大きく開く
一番分かりやすい穴は、hardwareよりURLかもしれない
高度なsecurityの話になると、CPUや暗号の話ばかり見たくなる。
しかし実務では、もっと普通のところから鍵が落ちる。
Popcornのsecurity documentは、browser view、CDP、API、VNCへ接続するsession URLをcredentialそのものとして扱うよう警告している。生きたURLを持つ人は、期限が来るかsessionが削除されるまで、そのrouteを使える場合がある。
つまり、confidential hardwareの中へbrowserを置いても、接続URLをapplication log、error tracking、support ticket、screen captureへ残せば、別の入口ができる。
CDP、Chrome DevTools Protocolの権限も強い。Pageを調べ、storageを読み、JavaScriptを実行し、downloadへ触れられる。Project自身、command filterだけをsecurity boundaryにせず、token scope、session ownership、network isolation、短いsession lifetimeを組み合わせるよう求めている。
これはPopcorn固有の欠陥という話ではない。
Agent browserのprivacyは、「cloud operatorがmemoryを読めるか」だけで採点できないという話だ。
URL漏洩対策をattestationだけで代替できるわけではない。保管・接続・環境検証の異なる境界を整理した概念図。 図を大きく開く
Self-hostは、信頼を消すのではなく、仕事を引き取る
Open sourceなら、自社でhostすればvendorを信頼せずに済む。
半分はその通りだ。
Codeを読める。imageを固定できる。networkを自社policyへ合わせられる。logの保存先も決められる。
ただし、残り半分では、vendorが持っていた仕事がこちらへ来る。
Kubernetes clusterをpatchする。RedisとPostgresをprivateに置く。browser workerからcloud metadataや社内networkへ抜けないようegressを制限する。secretをrotateする。imageの来歴とsignatureを確認する。session終了を試験する。incidentが起きた時、どのURLと鍵を失効するか決めておく。
Popcornのsecurity documentが並べるproduction controlsは、まさにこのlistだ。
Self-hostは「安全」というoption名ではない。信頼と運用責任の置き場所を変えるoptionだ。
専任のplatform teamがいない小規模事業者なら、よく管理されたhosted serviceの方が総合riskを下げる場合もある。反対に、機微情報を扱い、cluster運用とverificationを引き受けられる組織なら、openな実装は大きなcontrolになる。
数字もlicenseも、発表文ではなく現在地を見る
Reclaimは8月5日の開発記事で直近30日102,859 browser sessions、ready browser割当470ms p50、889ms p95と説明した。8月9日の公開記事では93,756 sessions、10,000時間超、median 460ms、p95 783msとしている。
これらは同社が報告したrolling windowの運用値で、独立した監査結果ではない。実利用を示すsignalにはなるが、他社比較のbenchmarkや、作業成功率、顧客数へ読み替えてはいけない。
もう一つ、公開時点で確認しておきたい差がある。
8月9日のblogはrepositoryをAGPL-3.0と説明する。一方、8月20日に取得したcurrent repositoryのLICENSEとREADMEはMIT表記だった。
ここで、どちらが意図したlicenseかを推測することはしない。
ただ、事業へ組み込む側のactionは明確だ。
Announcementの説明ではなく、自分が採用するcommitに含まれるLICENSEを確認する。曖昧ならmaintainerへ確認し、その回答を記録する。
Open sourceは「無料で自由」という一語ではなく、どの版を、どの条件で、誰が保守するかまで含む選択である。
Agent browserを選ぶ前に、仕事を三段階へ分ける
すべてのbrowser操作へ、最上級のconfidential infrastructureを使う必要はない。
まず、Agentへ渡す仕事を三段階に分けると判断しやすい。
1. Public・no-login
公開pageの確認、価格調査、screen capture、test siteの操作。Customer dataもaccount sessionも使わない。
Localのephemeral browserや通常のcloud browserで十分な場合が多い。終了後にprofileを捨て、downloadとlogへ秘密が残らないことを確認する。
2. Business・read-only
社内dashboardを読む、注文状況を確認する、support ticketを整理する。
人間の普段使いaccountを丸ごと渡さず、Agent専用の低権限accountを作る。Domain allowlist、短いTTL、session URLのredaction、操作log、human handoffの再認証を入れる。
3. High-impact
送金、購入、公開、削除、admin設定、personal dataのdownload。
Attested environmentまたは管理されたlocal machineを使うだけでなく、最後のtransactionに人間のapprovalを置く。上限額、対象domain、実行可能なactionを絞り、異常時にaccountとsessionを即座にrevokeできるようにする。
TEEは、この三段目を無人化する免許ではない。
Infra運営者からbrowser memoryを守る層と、Agentの誤操作から事業を守る層は別である。
安い「browser」ではなく、止められる「本人性」を選ぶ
Trusted Execution Environmentにも限界はある。Side-channelやfault injectionを整理した研究を含め、hardwareとsoftwareの両方に残る課題の検証は続いている。Self-hostにも、managed serviceにも、消えないriskがある。
それでも、Popcornの公開には価値がある。
Agent browserを、単なるheadless Chromeの貸出から、検証可能なdata-in-use基盤として論じられるところまで進めた。さらに公開docsを読めば、attestationがoptionalであることも、verifierが必要なことも、session URLが鍵であることも分かる。
良いsecurityは、「私たちは安全です」という一枚のbadgeではない。
何を守るのか。誰を信頼するのか。どんな証拠で確かめるのか。失敗した時、どの範囲で止めるのか。
その境界が読めることだ。
AIへbrowserを渡す時、比較すべきなのは一時間の価格だけではない。自分の代わりに動ける鍵束を、想定外の相手から隔離し、必要な時には確実に取り上げられるか。
Agent時代のbrowserは、便利な窓ではない。
委任された本人性を預かる金庫として、選ぶべきものになった。
