Not in the middle: why a Context AI–style breach against Caiioo would yield nothing useful

この文書は元の英語版を機械翻訳したものです。翻訳版と英語版の間に相違がある場合は、英語版が優先されるものとします。 英語版の原文を読む

中間に介在しない：なぜ Context AI スタイルの侵害が Caiioo に対して起きても有用なものが得られないのか

2026-04-22 · Caiioo Team

2026年4月19日、Vercel は、1 人の従業員が使用していたサードパーティ製 AI ツールが侵害され、その OAuth トークンが悪用されて Vercel の内部環境に侵入されたことを公表しました。一部の顧客の非機密環境変数が流出しましたが、暗号化された機密環境変数は影響を受けませんでした。

問題のツールは Context AI でした。従業員は企業用 Google Workspace への広範な「すべて許可」アクセス権を付与していました。Context AI のサーバーに保持されていたその 1 つの OAuth 権限が、その後に続くすべての攻撃のレバレッジポイントとなりました。

また、BreachForums の脅威アクターが、580 件の Vercel 従業員レコードを 200 万ドルで販売すると個別に掲載しています。Vercel はこの掲載内容を検証していません。

この事件はまだ収束していませんが、アーキテクチャ上の教訓はすでに明確であり、AI ワークスペースを検討しているすべての人にとって有用なものです。

攻撃の形態

SaaS 型 AI モデルでは、ユーザーが提供するすべての OAuth 権限の間にベンダーが介在することになります。

サードパーティの AI 生産性ツールをインストールし、OAuth 同意画面をクリックすると、Google（または Microsoft やその他の ID プロバイダー）から発行されたアクセストークンとリフレッシュトークンは、デバイス内には留まりません。それらはベンダーのサーバーに送信されます。なぜなら、それらを必要とする AI がベンダーのクラウドで動作しているからです。ベンダーのインフラは、ほとんどのユーザーが内容を読まずにクリックした「すべて許可」の権限を持つ、継続的に更新されるトークンセットを全ユーザー分保持しています。

この中央集中型のトークンストアこそが、攻撃者の標的となります。ベンダーを一度侵害するだけで、何千もの顧客の Workspace へのアクセス権が手に入ります。Vercel 自身の速報でも、ダウンストリームの影響が「多くの組織にわたる数百人のユーザー」に及ぶ可能性があると警告しています。

報道によると、元の連鎖は 2026年2月に個人デバイスが侵害された Context AI の従業員にまで遡ります。伝えられるところによれば、Lumma Stealer インフォスティーラーマルウェアを含む Roblox ゲームのチートツールをダウンロードしたことが原因でした。そのマルウェアは従業員の Google Workspace と AWS の認証情報を流出させ、それが OAuth トークン保管庫の解錠につながりました。1 台の感染した個人デバイス、1 つの企業用 SaaS 保管庫、そして数百のダウンストリーム Workspace が被害に遭ったのです。

Context AIスタイルの侵害がCaiiooに対して発生しても、有用な情報が一切得られない3つのアーキテクチャ上の理由

Caiiooは、サイドパネルで動作するエージェント・オーケストレーターとチャットインターフェースを備えた、強力でプライバシーを重視したワークスペースです。「プライバシー重視」とは、単なるマーケティングの文句ではなく、特定のアーキテクチャ上の姿勢を指します。そこには3つの具体的な特性が働いています。

1. ワークスペースの OAuth トークンはサーバーではなく、デバイス上に暗号化されて保存されます

Caiiooで Google または Microsoft のアカウントを接続すると、許可するスコープが表示された Google 標準の OAuth 同意画面が表示されます。ここまでは、Context AIを承認するのと全く同じに見えます。

構造的な違いは、その同意フローから発行されるトークンに何が起こるかという点にあります。Google が発行するアクセストークンとリフレッシュトークンは、お客様のデバイス上に暗号化されて保存されます。macOS および iOS では Keychain、Android では Keystore、拡張機能ではブラウザのセキュアストレージに保存されます。これらは Caiioo の中央データベースには保存されません。私たちはお客様に代わってトークンを保持するトークン・ヴォルト（保管庫）を持ちません。

エージェント・オーケストレーターがカレンダーを読み取ったり、受信トレイを検索したりする必要がある場合、API 呼び出しはお客様のデバイスから Google へ直接行われ、デバイスのセキュアストレージにあるトークンが添付されます。私たちのインフラストラクチャは、お客様のワークスペース・コンテンツのデータパスには介在しません。

これはソースコードでご自身で確認いただけます。src/shared/auth/connections-manager.ts が Google/Microsoft の OAuth 接続が永続化される場所です。accessToken および refreshToken フィールドを含む OAuthConnection レコードは、ローカルストレージアダプターを介して書き込まれ、中央のトークンストアに送信されることはありません。

2. リレーのメッセージバスはエンドツーエンドで暗号化されています

異なるデバイス上の Caiioo コンポーネントが連携する必要がある場合（ブラウザ拡張機能がデスクトップアプリと通信する、スマートフォンがホームサーバーと通信する、サイドパネルのUIが macOS 上でネイティブに動作するツールを呼び出すなど）、それらは私たちが relay.pebbleflow.ai でホストしているリレーを介して行われます。リレーは、ネットワークを越えてお客様のデバイス同士を見つけ出すためのランデブーポイントです。

このリレーはエンドツーエンドで暗号化されています。各ユーザーのデバイスはリレーのエンベロープを通じて鍵交換を行い、それ以降、デバイス間のメッセージはリレーの視点からは暗号文となります。リレーはメッセージをルーティングすることはできますが、読み取ることはできません。

これは理想論ではありません。WebSocket 接続を処理する Durable Object である cloud/relay/src/user-relay.ts には、次のように記載されています。"単一ユーザーの WebSocket 接続を管理します。E2E 暗号化されたメッセージ（リレーには不透明）と鍵交換を処理します。" ENCRYPTED メッセージタイプを処理するコードパスには、明示的に次のようなコメントがあります。"特定のクライアントへの暗号化メッセージ（読み取り不可）。" リレーは、転送するメッセージの内容を検査できないアーキテクチャになっています。

3. リレーは設計上、ユーザーごとのシングルテナントです

Caiioo のリレーは Cloudflare Durable Objects 上に構築されています。各ユーザーは独自の UserRelay インスタンス、つまり実行時に分離された個別のコンピューティングおよびストレージユニットを割り当てられます。全ユーザーのライブセッション状態を保持する共有マルチテナントデータベースは存在しません。なぜなら、その役割を担うマルチテナントデータベース自体が存在しないからです。各ユーザーのリレーは独立したオブジェクトです。

これが重要なのは、「単一の共有ターゲット」という失敗モードを排除できるからです。たとえ攻撃者が一人のユーザーの Durable Object を侵害する方法を見つけたとしても、他のユーザーのデータに横方向にアクセスすることはできません。ピボット（踏み台）にできる共有バッキングストアが存在しないためです。各ユーザーは、構造的に独自のテナントとなっています。

当社の中央データベースにあるもの、ないもの

当社は、中央管理が必要なもののために中央データベース（Cloudflare D1）を運用しています。ここでは正直さが重要です。データベースには以下のものが保存されます：

  • アカウント ID: メールアドレス、メール/パスワードログインを使用している場合はハッシュ化されたパスワード、ソーシャルログインボタンを使用している場合は Google/Apple/Microsoft から返されるプロバイダー ID。
  • 請求ステータス: Stripe の顧客 ID、サブスクリプションティア、ライセンスキー、およびサブスクリプションの状態。
  • AI 推論プロバイダー（具体的には OpenRouter）のユーザーごとの API キー: これらは推論プロバイダーの認証情報であり、Workspace の OAuth トークンとは異なります。これらは、管理クレジットフローを利用するユーザーや、Caiioo の AI 機能全体で自分の OpenRouter キーを使いたいユーザーのために存在します。
  • デバイスアクティベーションリスト: ライセンス適用のためのもの。
  • 監査ログ: SOC 2 の証跡要件のために保持されます。
  • オプトインのインバウンド Webhook（WhatsApp、Telegram など）用のルーティングテーブル: これらのメッセージング連携を設定している場合にのみ使用されます。

データベースには以下のものは保存されません：

  • Workspace の OAuth トークン（Gmail、Calendar、Drive、Microsoft 365）: これらはあなたのデバイス上にのみ存在します。
  • 会話の内容: エージェントのオーケストレーターはサイドパネルで動作し、会話はローカルストレージに保存されます。
  • Workspace のデータ: メール、カレンダーの予定、Drive のファイル。これらは Google/Microsoft からあなたのデバイスへ直接読み取られ、当社のインフラを通過することはありません。
  • WebSocket リレーを流れるメッセージの内容: リレーは暗号文のみを認識します。

当社の中央データベースが侵害された場合、アカウント/請求 ID、監査ログ、および OpenRouter 推論キーの列が公開されることになります。しかし、Workspace トークン、会話内容、Workspace データが流出することはありません。なぜなら、それらはデータベースの中に存在しないからです。

正直な注意事項

これは異なる脅威モデルであり、魔法の盾ではありません。後で気づくよりも、あらかじめ私たちから聞いておいていただきたい制限事項がいくつかあります。

OAuthコード交換は、一時的に当社のリレーを通過します。 Google（およびMicrosoft、GitHub、Slack）は、トークン交換ステップでOAuthのclient_secretを提示することを要求しますが、そのシークレットをクライアントコードに含めて配布することはできません。そのため、当社のステートレスなリレーがclient_secretを付加し、実際のトークンと引き換えに、お客様の認証コードをGoogleに転送します。トークンはリレーを経由して戻り、直ちにお客様のデバイスに返されて保存されます。これらが当社のインフラストラクチャに永続化されることはありません。これは、これまでにお客様が使用したすべてのネイティブなGoogle統合アプリにサーバーコンポーネントが存在するのと同じ理由です。これはGoogleの制約であり、Caiiooの設計上の選択ではありません。

カスタムエンドポイントを使用すると、当社のOAuthクライアントを完全にバイパスできます。 CaiiooはカスタムOAuthエンドポイントの設定をサポートしています。つまり、Google Cloud Console（またはMicrosoft Entraの同等機能）で独自のOAuthクライアントをプロビジョニングできるユーザーは、CaiiooのOAuthスコープや当社のリレーによる交換ステップを完全に回避できます。一度設定すれば、認証フローはお客様のデバイスとGoogleの間で完結し、Caiiooが介在することはありません。ほとんどのユーザーには必要なく、デフォルトのアーキテクチャですでにWorkspaceデータが当社のサーバーに保存されないようになっているため、これを一般消費者向けの設定としては公開していません。しかし、この機能は存在しており、以前にGoogle Cloud ConsoleでOAuthクライアントをセットアップしたことがある方なら、その実装方法は馴染みのあるものでしょう。

デバイスの侵害は依然として重要です。 もしお客様のラップトップが乗っ取られれば、トークンも乗っ取られます。ローカルファーストは、攻撃対象領域を「ベンダーの保管庫」から「お客様のエンドポイント」へと移動させます。これはより小さく、防御しやすい領域ですが、ゼロではありません。

ログイン層の「Googleでサインイン」は、Workspaceへのアクセスとは別物です。 GoogleまたはAppleを使用してCaiioo自体にサインインする場合、そのフローはアイデンティティのみを目的としており、お客様のアカウントにスコープされた基本的な接続を作成します。これは、前述のWorkspaceアクセスフローと同じ経路ではなく、AIに受信トレイやカレンダーへのアクセス権を付与するものでもありません。

Caiioo自体に対するサプライチェーン攻撃は、依然として考えられます。 侵害されたアップデートチャネルは、原理的にはデバイスからトークンを流出させるコードを配信する可能性があります。当社は、提供するすべてのプラットフォームにおいてコード署名と公証（notarization）を行うことでこれを軽減していますが、その対策はベンダー保管庫モデルとは異なり、攻撃者の経済合理性もまた異なります。

ご自身で検証する方法

正直なところ、マーケティングページに記載されたベンダーのプライバシーに関する主張を、懐疑的な方に完全に証明することは不可能です。そこで、私たちが主張している内容をご自身のツールを使って確認する方法を以下に示します。

Caiioo の使用中にネットワークモニターを実行してください。 macOS なら Little Snitch、Windows なら GlassWire、あるいはあらゆるプラットフォームで利用可能な Wireshark を使用してください。Caiioo を通常通り1時間使用します。表示されるトラフィックと、各接続の意味は以下の通りです：

送信先 タイミング 意味
oauth2.googleapis.com, gmail.googleapis.com, calendar.googleapis.com, www.googleapis.com エージェントが Workspace データを読み取る際 デバイス上のトークンを使用して、デバイスが Google と直接通信しています。私たちはこの経路に介在しません。
login.microsoftonline.com, graph.microsoft.com Microsoft 365 を接続している場合 上記と同様、デバイスから Microsoft への通信です。
api.anthropic.com, openrouter.ai, api.openai.com, generativelanguage.googleapis.com, localhost:11434 (Ollama) チャットを送信したり、LLM を使用するツールを実行したりする際 設定した AI プロバイダーとデバイスが通信しています。私たちはこの経路に介在しません。
relay.pebbleflow.ai (HTTPS) 初回の Workspace OAuth 設定時および定期的なトークン更新時の短時間 ステートレスな OAuth コード交換です。トークンは通過しますが、サーバー側に保存されることはありません。
relay.pebbleflow.ai (HTTPS) 定期的 ライセンス認証、リリースノート/ユーザーガイドのコンテンツ取得、モデルインテリジェンスデータ、サブスクリプションステータスの確認。
relay.pebbleflow.ai (HTTPS) ウェブサイトの読み込み時、または接続済みアカウントのステータス表示時 標準的な API トラフィック。
relay.pebbleflow.ai (WebSocket) 複数の Caiioo コンポーネント（拡張機能 + デスクトップアプリ、またはモバイル + デスクトップ）をインストールしている場合、常時 デバイス間通信を可能にする機能ブリッジです。エンドツーエンドで暗号化されています。私たちは暗号文のみを参照します。
relay.pebbleflow.ai/api/messaging/... メッセージング連携（WhatsApp、Telegram、Slack の受信）を設定している場合のみ 受信メッセージの Webhook ルーティング。

以下のような通信は、決して発生しません：

  • Workspace データ（メール、カレンダーの予定、Drive ファイル）が relay.pebbleflow.ai に流れること。これらの呼び出しは、デバイスから直接 *.googleapis.com へ行われます。
  • 会話内容が relay.pebbleflow.ai に流れること。オーケストレーターはサイドパネル内で実行され、チャット履歴はローカルストレージに保存されます。
  • AI プロバイダーの API キーが relay.pebbleflow.ai に流れること。これらはデバイス上に保持されます。（例外：マネージドクレジット・フローを使用している場合、サーバーで割り当てられた OpenRouter サブアカウントを使用しますが、推論の呼び出しは引き続きデバイスから行われます。）

もし、お使いのデバイスから弊社のインフラストラクチャに対して、上記の表に該当しないリクエストが確認された場合は、それは重要な発見です。私たちにお知らせください。説明または修正を行います。

Vercel または Context AI の顧客である場合の対処法

Vercel、Context AI、およびセキュリティ研究コミュニティから公開されたガイダンスは、一貫したチェックリストに集約されています：

  1. すべてのシークレットをローテーションする: 暗号化されていない Vercel 環境変数として保存されているすべての値を変更してください。暗号化された機密変数は影響を受けていないと報告されていますが、ローテーションのコストは低いです。
  2. チームのサードパーティ OAuth 権限を監査する: Google Workspace（および必要に応じて Microsoft 365）を確認してください。認識のないものは取り消し、広範な「すべて許可」スコープを付与したツールは、交換が必要な認証情報として扱ってください。
  3. 今後の同意を厳格化する: 最小権限のスコープを要求するツールを優先し、そもそも長期間有効なトークンを渡す必要のないアーキテクチャを持つワークスペースを選択してください。

3 つ目は構造的な対策であり、今回の事件が静かに推奨し続けている教訓です。

Caiioo を試す

Vercel/Context AI の事件から得られる教訓が「ベンダーが侵害された際の被害範囲は OAuth トークンの場所によって決まる」ということであれば、答えはトークンを保持しないワークスペースを選ぶことです。

Caiioo は、サイドパネルで動作するエージェントオーケストレーターとチャットインターフェースを備えた、強力でプライバシーを重視したワークスペースです。ブラウザ拡張機能、macOS ネイティブアプリ、iOS ネイティブアプリ、Android ネイティブアプリ、および Windows と Linux 用のデスクトップアプリとして利用可能です。無料で始める。

ソース: