本文件為英文原版的機器翻譯。若翻譯版本與英文原版之間存在任何歧義，概以英文原版為準。 閱讀英文原版
不在中間：為什麼針對 Caiioo 的 Context AI 式洩漏不會產生任何有用信息
2026-04-22 · Caiioo Team
2026 年 4 月 19 日，Vercel 披露一名員工使用的第三方 AI 工具遭到入侵，而被盜取的 OAuth 權杖被用作進入 Vercel 內部環境的跳板。少部分客戶的非敏感環境變數遭到洩露。加密/敏感環境變數未受影響。
該工具是 Context AI。該員工授予了其對公司 Google Workspace 廣泛的「允許所有」存取權限。儲存在 Context AI 伺服器上的單個 OAuth 授權，成為了後續一切行動的槓桿點。
一名威脅行為者在 BreachForums 上另外列出了聲稱是 580 條 Vercel 員工記錄，售價為 200 萬美元。Vercel 尚未核實該清單。
事件尚未結束。但架構上的教訓已經很明確，對於任何評估 AI 工作區的人來說，這都是一個有用的教訓。
攻擊的形式
SaaS-AI 模型將供應商置於您給予的每一次 OAuth 授權的中間。
當您安裝第三方 AI 生產力工具並點擊 OAuth 同意畫面時，Google（或 Microsoft，或任何身份提供者）核發的存取權杖（access token）和重新整理權杖（refresh token）並不會留在您的裝置上。它們會被傳送到供應商的伺服器，因為需要這些權杖的 AI 運行在供應商的雲端。供應商的基礎設施為其每一位用戶持有不斷更新的權杖集，其權限範圍通常是大多數用戶在未閱讀的情況下點擊的「允許所有」。
這種中心化的權杖儲存庫正是攻擊者的目標。只要入侵供應商一次，就能獲得數千名客戶的 Workspace 存取權。Vercel 自己的公告警告說，下游影響可能會波及「許多組織中的數百名用戶」。
報導將原始鏈條追溯到一名 Context AI 員工，其個人裝置在 2026 年 2 月遭到入侵，據報導是透過下載的 Roblox 遊戲外掛程式，該程式攜帶了 Lumma Stealer 資訊竊取惡意軟體。該惡意軟體外洩了該員工的 Google Workspace 和 AWS 憑證，進而解鎖了 OAuth 權杖庫。一個受感染的個人裝置、一個企業 SaaS 儲存庫，導致了數百個下游 Workspace 受害。
三個架構上的原因，說明為何針對 Caiioo 進行 Context AI 式的攻擊將一無所獲
Caiioo 是一個強大且隱私優先的工作空間，具備代理編排器（agentic orchestrator）以及在側邊欄運行的對話介面。「隱私優先」描述的是一種特定的架構姿態，而非行銷口號。這其中包含三個具體的運作特性。
1. 您的 Workspace OAuth 權杖加密儲存在您的裝置上，而非我們的伺服器
當您在 Caiioo 中連結 Google 或 Microsoft 帳戶時，您會看到 Google 標準的 OAuth 同意畫面，顯示您授予的權限範圍。到目前為止，這看起來與授權 Context AI 完全相同。
結構上的差異在於該同意流程產生的權杖（tokens）之去向。Google 核發的存取權杖（access token）與重新整理權杖（refresh token）會加密儲存在您的裝置中 —— 在 macOS 與 iOS 上儲存於 Keychain，在 Android 上儲存於 Keystore，在瀏覽器擴充功能中則儲存於瀏覽器的安全儲存空間。它們不會儲存在 Caiioo 的中央資料庫中。我們沒有代表您持有這些權杖的權杖庫（token vault）。
當代理編排器需要讀取您的行事曆或搜尋您的收件匣時，API 呼叫會直接從您的裝置發送到 Google，並附上來自您裝置安全儲存空間的權杖。我們的基礎設施不在您任何 Workspace 內容的資料路徑上。
您可以親自在原始碼中驗證這一點：src/shared/auth/connections-manager.ts 是 Google/Microsoft OAuth 連線持久化的地方。包含 accessToken 與 refreshToken 欄位的 OAuthConnection 紀錄是透過本地儲存適配器寫入的 —— 而非傳輸到中央權杖儲存庫。
2. 中繼站（relay）的訊息匯流排採用端對端加密
當不同裝置上的 Caiioo 組件需要協調時 —— 例如您的瀏覽器擴充功能與您的桌面應用程式通訊、您的手機與您的家用伺服器通訊、側邊欄 UI 調用在 macOS 上原生運行的工具 —— 它們會透過我們託管於 relay.pebbleflow.ai 的中繼站進行。中繼站是讓您的裝置能夠跨網路找到彼此的會合點。
該中繼站是端對端加密的。每個使用者的裝置都會透過中繼站封裝進行金鑰交換，從那時起，您的裝置之間的訊息對中繼站而言就是加密文字。中繼站可以路由這些訊息，但無法讀取它們。
這並非願景。處理 WebSocket 連線的 Durable Object（cloud/relay/src/user-relay.ts）在文件中被記錄為：「管理單一使用者的 WebSocket 連線。處理端對端加密訊息（對中繼站不透明）與金鑰交換。」 處理 ENCRYPTED 訊息類型的程式碼路徑被明確註釋：「發送至特定客戶端的加密訊息（我們無法讀取）。」 中繼站在架構上無法檢查其轉發訊息的內容。
3. 中繼站在構造上是單一使用者專用的（single-tenant）
Caiioo 的中繼站建立在 Cloudflare Durable Objects 之上。每個使用者都會獲得自己的 UserRelay 實例 —— 一個獨立的、運行時隔離的運算與儲存單元。不存在一個共享的多租戶資料庫來持有每個使用者的即時對話狀態，因為在該角色中根本沒有多租戶資料庫。每個使用者的中繼站都是一個獨立的物件。
這點至關重要，因為它消除了「單一共享目標」的失效模式。即使攻擊者找到了入侵某個使用者 Durable Object 的方法，他們也無法橫向存取任何其他使用者的資料 —— 因為沒有可以作為跳板的共享後端儲存庫。在結構上，每個使用者都是他們自己的租戶。
我們的中央數據庫中有什麼，沒有什麼
我們確實運行一個中央數據庫 (Cloudflare D1) 來處理需要集中的事務。誠實至關重要。該數據庫存儲：
- 帳戶身份： 您的電子郵件、如果您使用電子郵件/密碼登錄時的雜湊密碼、如果您使用社交登錄按鈕時由 Google/Apple/Microsoft 返回的供應商 ID。
- 計費狀態： 您的 Stripe 客戶 ID、訂閱層級、許可金鑰和訂閱狀態。
- AI 推理供應商的每用戶 API 金鑰（特別是 OpenRouter）。這些是推理供應商憑證 — 與您的 Workspace OAuth 權杖不同。它們存在於託管額度流程中，以及希望自備 OpenRouter 金鑰以在 Caiioo 的 AI 功能中使用的用戶。
- 設備激活列表，用於許可執行。
- 審計日誌，保留用於 SOC 2 證據要求。
- 選擇性加入的入站 Webhook 路由表（WhatsApp、Telegram 等）— 僅在您配置了這些消息集成時使用。
該數據庫不存儲：
- 您的 Workspace OAuth 權杖（Gmail、日曆、雲端硬碟、Microsoft 365）。這些僅存在於您的設備上。
- 您的對話內容。代理編排器在您的側邊欄中運行；對話存在於您的本地存儲中。
- 您的 Workspace 數據 — 電子郵件、日曆活動、雲端硬碟檔案。這些直接從 Google/Microsoft 讀取到您的設備，絕不經過我們的基礎設施。
- 任何流經 WebSocket 轉發站的消息內容。轉發站僅看到密文。
我們中央數據庫的洩漏會暴露帳戶/計費身份、審計日誌和 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 客戶端的人都會對其實現方式感到熟悉。
設備受損仍然至關重要。 如果您的筆記型電腦被攻破，您的令牌也會隨之失守。本地優先（Local-first）將攻擊面從「供應商的保險庫」轉移到了「您的終端設備」。這是一個更小且更易防禦的表面，但並非零風險。
登錄層級的「使用 Google 登入」與 Workspace 訪問權限是分開的。 如果您使用 Google 或 Apple 帳號登入 Caiioo 本身，該流程僅用於身份識別，並建立一個範圍僅限於您帳戶的 Basic 連接。這與上述的 Workspace 訪問流程路徑不同，且不會授予 AI 訪問您的收件匣或日曆的權限。
針對 Caiioo 本身的供應鏈攻擊仍是有可能的。 被攻破的更新渠道原則上可能會發送從您的設備中竊取令牌的代碼。我們通過在發布的每個平台上進行代碼簽名和公證來緩解這種風險，但這種緩解措施與供應商保險庫模型不同——攻擊者的經濟效益亦然。
如何自行驗證
誠實的回答是，行銷頁面上的供應商隱私聲明無法向懷疑者證明。因此，以下說明如何使用您自己的工具來確認我們的聲明。
在使用 Caiioo 時執行網路監控工具。 macOS 上的 Little Snitch、Windows 上的 GlassWire，或任何系統上的 Wireshark。正常使用 Caiioo 一小時。您將看到的流量以及每個連線的含義如下：
| 目的地 | 何時 | 含義 |
|---|---|---|
oauth2.googleapis.com, gmail.googleapis.com, calendar.googleapis.com, www.googleapis.com |
每當代理程式讀取您的 Workspace 數據時 | 您的裝置使用裝置上的 token 直接與 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 設置和定期 token 刷新期間 | 無狀態的 OAuth 代碼交換。Token 僅通過，不會在伺服器端持久化。 |
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 和安全研究社群發布的指南已匯集成一份一致的清單：
- 輪換每一個金鑰，特別是作為非加密 Vercel 環境變數儲存的金鑰。雖然加密/敏感變數據報未受影響，但輪換成本很低。
- 稽核您團隊在 Google Workspace（以及 Microsoft 365，如果適用）上的第三方 OAuth 授權。撤銷任何您不認得的授權，並將任何您授予廣泛「允許所有」範圍的工具視為需要更換的憑證。
- 收緊未來的同意授權。優先選擇請求最小權限範圍的工具，並優先選擇其架構根本不需要您交出長期權杖的工作區。
第三點是結構性的舉措，也是這次事件一直在默默推薦的做法。
試用 Caiioo
如果 Vercel/Context AI 事件的教訓是，當供應商被入侵時，OAuth 權杖的位置決定了您的受影響範圍，那麼答案就是選擇一個不持有這些權杖的工作空間。
Caiioo 是一個強大、隱私優先的工作空間，擁有在側邊欄運行的代理編排器和聊天界面。提供瀏覽器擴充功能、原生 macOS 應用程式、原生 iOS 應用程式、原生 Android 應用程式，以及適用於 Windows 和 Linux 的桌面應用程式。免費開始使用。
來源：