您好，我是TIMEWELL的濱本隆太。
一則AI會議記錄服務的脆弱性被公開了。超過18萬筆會議紀錄，處於其他公司的使用者也看得到的狀態。
數字很大，容易被讀成「又是一家草率的公司」。但讀了報告後發現，其實不是這樣的故事。**在同一套系統中，十個容器裡有九個是被正確守住的。**沒守住的只有一個。
而這種「只漏掉一個」的失敗形態，包含我們自己在內，凡是在做多租戶架構服務的公司，都在結構上內建了這個風險。不是能當作別人家的事，所以依序寫下來。
本文不寫成給工程師看的文章。目標是讓導入SaaS的一方，知道該向供應商問什麼。
首先，發生了什麼
依資安研究者 BobDaHacker 於2026年8月4日公開的報告，AI會議記錄服務tl;dv中，保管會議中繼資料的資料庫上的一個容器，未設定租戶之間的存取控制1。
結果是，只要是已登入的使用者，就能讀取平台上其他公司的會議紀錄。範圍為181,874筆會議紀錄、84,312名使用者、35,003個郵件網域。報告指出，其中包含23個國家的政府機關、多所大學，以及大量企業的會議1。
看得到的欄位包括會議建立者的電子郵件位址、錄影狀態、時間戳記，以及會議ID。這個會議ID相當棘手，因為它就是Google Meet或Teams「進入該會議的號碼」。研究者作為實證，實際進入了兩場未受邀請的他人直播會議。一場是馬來西亞教育部157人規模的會議，另一場是美國大學衍生新創21人的會議，當時正在分享畫面1。
報告是在2026年1月28日提出的。公開時已經過了6個月1。另外在公開後，tl;dv方面表示報告後不久即已解除，研究者則反駁6個月後仍可重現。**事實關係上留有這個分歧。**本文並非為裁定此事而寫。想看的是，為什麼這個洞會產生，也就是結構那一側。
用大樓來想「多租戶」
只解釋一個名詞。
多租戶是指一套系統由多家公司共同使用的機制。請想像一棟大樓。建物、電梯、管線都是共用的，各公司只使用自己的單位。相當於這個「單位隔間」的，就是租戶隔離。
SaaS之所以便宜，正是因為透過共用來分攤成本。比起每一家公司都架一台伺服器，效率高得多。所以多租戶本身並非壞事，反而是當代雲端服務的前提。
不過，安全性就會壓在這道隔間上。隔間漏了一處，隔壁的單位就看得見。這次發生的，正是這件事。
九個守住了，只有一個沒守住
這是本案的核心。
依研究者的記述，同一套系統上的使用者、聊天、逐字稿、剪輯、錄音、影片、筆記、團隊、組織這九個容器，全都正確地拒絕了存取1。影片本身守住了，對話的逐字稿也守住了。
沒守住的，只有會議中繼資料這一個。
也就是說，這不是「輕視資安的公司理所當然地全部門戶洞開」的故事。而是具備隔離這個設計思想、九成都正確實作的組織，只漏掉了一個的故事。
我反而在這裡感到害怕。如果做到九成仍會出事，那麼大多數公司都站在同樣的位置。
順帶還有一層教訓。漏掉的不是「影片本體」，而是「中繼資料」這一點。中繼資料不是本體，所以重要性低，這種感覺在許多現場都存在。但這次那份中繼資料裡放著會議ID。擺在那裡的不是內容，而是進入內容的鑰匙。
若以「是本體資料或是附帶資訊」來劃分機密度，必定會踩到這個陷阱。該判斷的不是那裡寫了什麼，而是用那份資料能做到什麼。會議ID、邀請連結、共用權杖、可猜測的檔案路徑。單獨看都沒有內容，但都能當鑰匙用。
洞為什麼會「後來」才開
最初設計時應該隔離得好好的東西，隨著改版累積而開了洞。這不是怠慢，而是幾個力學作用下的結果。收斂成三點來寫。
第一，變成「只有寫過的地方才關起來」的方式。
如果把防護規則依資料容器逐一撰寫，那麼防禦就會處於「只有明示關閉的地方是關著的」狀態。當新的容器增加時，什麼都不寫，它就是開著的。
這個結構對開發速度快的組織反而不利，因為容器增加的速度會超過寫防禦的速度。正確的形態是相反的，先在整體宣告「原則全部拒絕」，只讓明示允許的通過。這樣新的容器在沒有人做任何事的情況下，就是從關閉的狀態開始。這一點設計差異，會決定運作五年十年之後的結果。
而且這類洞，靠認證標章是抓不到的。
這類服務的資安頁面上，通常會排著各種認證與加密的標章。那些並非謊言。但這次的外洩，是從正規已認證的工作階段發出、資料庫以「獲允許的請求」回應的結果。
- 第三方認證證明的是流程的存在，而非每一個容器、每一條路徑、每一項新功能上實作的正確性
- 儲存時的加密守的是沒有解密金鑰的對象，而非授權判斷出錯的對象
「取得了認證所以安全」並不成立。認證保障的是下限，不是上限。
順帶一提，本公司採取不把未取得的認證寫進產品說明的方針。這是能寫的公司越想強調的地方，所以特別註明。
第二，功能改版會不斷製造「跨越邊界的正當理由」。
當服務成熟後，必定會出現這些需求。想跨全公司搜尋。想要給管理者看的全組織使用狀況儀表板。要批次匯出功能。想推薦類似案例。查詢太慢，想做彙總表。
每一項都是正當的商業需求。而每一項都要求跨越租戶邊界的實作。沒有惡意也沒有偷懶，開洞的理由卻不斷堆疊。特別危險的是為了改善速度而做的彙總表與快取。原始資料上就算有標示所屬公司的識別，從中衍生的彙總資料掉了識別的事故非常多。邊界必須維持的不是「最初做的地方」，而是資料被複製、被變形的所有地方。
第三，做得更快之後，面也不斷增加。
這次的報告還附帶了一段。tl;dv的內部用世界盃預測應用程式的API沒有驗證，自家員工19人的姓名與公司電子郵件位址處於可取得的狀態1。內部用、玩票性質、暫時的。以這種定位做出來的東西被放在正式網域底下，成為實際存在的攻擊面。
生成式AI讓製作這類「隨手做出來的面」的成本大幅下降。**做得更快之後，關閉也必須自動化，否則追不上。**所以又回到第一點。
加入AI之後，外洩的形態會改變
從這裡開始，是處理AI的我們真正的主題。
**AI功能本質上就想要橫跨。**檢索索引跨租戶建立，精度與效率都更好。知識圖譜的價值在於把節點連起來。「類似案例」「過去的相似案子」這類功能，在跨越邊界時最有用。嵌入、摘要、快取等中間處理，會把原始資料的結構抽掉，以另一種形式保存。
也就是說，加入AI功能，會以最強的形式把前述「跨越邊界的正當理由」帶進來。而且中間產物越多，標示所屬公司的識別掉落的地方也越多。
外洩時受害的性質也會改變。
過去的租戶隔離事故是「其他公司的資料被檢索得到」。加入AI之後，**其他租戶的資料會混入交給模型的脈絡，由模型主動說出來。**攻擊者甚至不需要探索。一般使用者只是照常提問，其他公司的資訊就混進了回答裡。
偵測也變難。存取紀錄裡只留下「正常的提問」。
因此在具備AI功能的多租戶SaaS上，我認為以下會成為必要條件。把索引本身依租戶切開，或至少在檢索之前就先區隔（事後過濾的方式，在前段候選被其他租戶的資料吃掉的那一刻，就同時造成品質劣化與資訊外洩）。讓嵌入、摘要、快取與所有中間產物都帶著所屬公司的識別，並測試它沒有消失。在交給模型的前一刻，放一層檢查租戶一致性的機制。
把企業內部知識交給AI時的一般注意事項，另在圖工程是什麼中，從知識結構的角度整理過。
交付方能確認的事
最後舉三件，站在導入方的立場該問什麼。都設計成不是工程師也問得出口。
**第一，「新增功能時，那個功能預設是關著還是開著？」**能立刻回答的公司，就是原則拒絕的設計。若回答「每次都寫規則」，那就是前述力學會作用的結構。無關好壞，先掌握這個事實。
**第二，「跨不過租戶這件事，有用自動測試驗證嗎？」**是否有機制能用A公司的權限去取B公司的資料，並機械式地確認被拒絕。人工測試會在新功能增加時，重複「忘了寫測試」這個相同的失敗形態。
第三，「從收到脆弱性通報到修補完成，平均要多久？」這次最沉重的，不是技術上的設定錯誤本身，而是收到通報之後的時間。設定錯誤會發生。再優秀的團隊，運作久了也會漏掉一個。資安的成熟度無法用有沒有脆弱性來衡量。能衡量的是從被告知到關上為止的時間。
我們把ZEROCK放在日本國內的AWS伺服器上運作、並管控誰能接觸哪些知識，也是因為想把這條界線放在產品的內側。會議、企業內部文件、審查流程，今後都會加速地交給AI服務。屆時交付方該問的，不是「持有哪些認證」，而是「邊界是否預設關閉」與「被告知問題時，幾小時內會動」。
想討論自家的知識該怎麼交付，歡迎從個別諮詢與我們聯繫。
Footnotes
-
資安研究者 BobDaHacker 的公開報告（2026年8月4日公開）。tl;dv 使用的 Firestore 中
meetings集合未設定租戶之間的存取控制、已驗證使用者即可存取平台上會議紀錄的狀態，規模為181,874筆會議紀錄、84,312名使用者、35,003個郵件網域，外洩欄位包含建立者電子郵件位址、會議ID（Google Meet 或 Teams 可進入的會議ID）、供應商資訊、錄影狀態與時間戳記，userschatstranscriptsclipsrecordingsvideosnotesteamsorganizations各集合均正確回傳403，作為實證進入馬來西亞教育部157人規模會議及美國大學衍生新創21人規模會議，報告日為2026年1月28日且公開時據稱仍未修補，以及內部用應用程式worldcup.tldv.io的/api/entities/Player在無驗證的情況下回傳含自家員工19人姓名與公司電子郵件位址的資料，均依該報告。https://bobdahacker.com/blog/tldv-hack 公開後，tl;dv 方面表示報告後不久即已解除，研究者則反駁6個月後仍可重現。事實關係上留有此一分歧，本文不進行何者正確的判定。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6
