前言

企業可能把正式環境的登入保護得很嚴密，卻讓會議工具、銷售系統或文件搜尋服務取得廣泛資料權限。每一項整合都有業務理由，累積起來，卻可能形成一張沒有人完整掌握的存取網路。

《華盛頓郵報》報導，Cathedral 稱不到 12 小時便經商用軟體存取 Anthropic 系統；Anthropic 稱客戶對話與模型權重未被存取。原始報導

查核日期：2026-10-26，台灣時間。 上段為新聞簡述，相關說法依來源歸屬。本篇以此為引子，說明一般企業的第三方 SaaS 風險；下文的 OAuth、文件同步與服務範例是教學模型，不代表本事件已證實的攻擊技術或產品。封面為自行繪製的權限示意圖。

一、分析事件時，先找出被跨越的資料邊界

對 AI 公司或任何科技公司來說，安全範圍包含多種資產：客戶使用產品的資料、公司日常營運資料，以及研發或正式環境中的核心資產。它們可以由不同團隊、帳號與系統管理。

閱讀資安報導時，我會先問：取得的是哪個系統的哪種權限？是某份資料的讀取能力，還是能修改設定、執行程式或建立新身分？這些問題決定後續要查什麼，也決定應變範圍。

資產類型 一般企業中的例子 調查時需要確認
營運資料 人事紀錄、客戶名單、會議內容、合約 哪些紀錄可讀、是否存在匯出或同步副本
身分與管理能力 服務帳號、API 權杖、應用程式授權 是否能跨系統操作、建立後續存取
正式環境與核心研發資產 原始碼、部署設定、模型檔案、正式資料庫 是否有獨立身分與授權邊界，是否有直接存取證據

這是一份通用調查框架。要對個別事件下結論，仍需要把每一項主張，對應到具體資產、權限與紀錄。

二、SaaS 整合為什麼會擴大存取範圍？

SaaS 是透過網路提供的軟體服務。企業常把多個服務接起來，例如把會議紀錄同步進文件系統，或讓搜尋工具查詢團隊知識庫。服務之間需要代表某個使用者或應用程式，向另一個服務提出請求。

其中一種常見方式是 OAuth 授權：使用者允許應用程式存取特定資源，應用程式取得 access token（存取權杖），之後用它呼叫 API。允許的操作通常由 scope 等權限設定表達。Slack 的官方文件就描述了授權、取得權杖與呼叫 API 的流程。Slack OAuth 文件

可以用以下簡化模型理解：

1
2
3
4
5
6
7
使用者或管理者同意授權
        ↓
整合工具取得存取權杖
        ↓
API 檢查權杖與允許的操作
        ↓
工具讀取資料，可能另存搜尋索引或同步副本

這裡至少有兩個獨立問題：工具要求的權限是否太廣，以及工具本身是否妥善保護權杖與取得的資料。就算 API 正確執行授權，原本允許過大的讀取範圍，也可能造成很大的暴露面。

而一旦工具已把資料複製出去，來源端後來收回授權，也不會自動清除所有既有副本。資料保存、刪除與備份，需要有另外的處理流程。這是資料流設計上的後果，不能只靠登入設定解決。

三、有 SSO 與 MFA，為什麼還要檢查應用程式身分？

SSO（單一登入）集中處理使用者的登入體驗；MFA（多因素驗證）為登入增加驗證條件。但服務執行背景工作時，未必每次都有一個人坐在瀏覽器前重新登入。

以 Microsoft 身分平台為例，官方區分兩種權限：

  • Delegated permissions，委派權限：應用程式代表已登入的使用者操作。
  • Application permissions，應用程式權限：應用程式以自己的身分操作，取得權杖時不需要使用者登入；這類權限需要管理者同意。

這是 Microsoft 平台的具體模型，其他服務的名稱與細節可能不同。Microsoft 應用程式與委派權限文件

因此，檢查登入安全時，應同時檢查背景執行的工具：誰同意授權、工具能讀哪些資源、憑證存在哪裡，以及如何停用。使用者有 MFA，無法代替這幾項設定。

零信任架構也要求把控制落在服務與應用程式身分，除了網路位置，還要驗證實際存取資源的主體。NIST SP 800-207A

四、最容易漏掉的工作：撤銷已經發出去的權限

不少整合都有「要求哪些權限」的設定畫面，但修改應用程式設定，與撤銷已經存在的授權，是兩個操作。

Microsoft 官方文件明確說明，從應用程式註冊設定移除權限，不會自動撤銷已授予的權限。管理者還需要針對既有授權進行處理。更新應用程式要求的權限

Slack 也有具體差異：某些既有權杖的 scope 無法直接縮減，需要撤銷權杖；官方提供 auth.revoke 等機制處理。Slack 權杖撤銷說明

這會影響事件應變的完成條件。把「移除畫面上的整合」記為完成之前，應再確認：

  1. 舊 access token 是否仍被 API 接受？
  2. 能否使用 refresh token、client secret 或其他憑證取得新權杖？
  3. 原本的管理者或使用者，是否能立刻重新授予同樣權限？
  4. 工具取得的檔案、索引與備份副本，如何保存或刪除？

各平台的撤銷時效不同。例如 Microsoft 說明，在其停用惡意 OAuth 應用程式的處理中，新的權杖請求會被拒絕，但既有 access token 可能持續有效直到到期。Microsoft OAuth 應用程式處置說明

所以，撤銷後應加入驗證步驟，並在處理期間監看相關 API 活動。設定已變更與存取已失效，需要分別留下證據。

五、企業可以先建立哪一份清單？

我會先盤點能接觸敏感資料的整合，特別是具備大量讀取、匯出或管理能力的工具。以下是一個可直接拿來使用的最小紀錄格式：

欄位 要記錄的內容
業務用途與負責人 為何需要這項整合，誰能判斷是否可停用
執行身分 代表使用者，或使用獨立服務帳號／應用程式身分
實際授權 已授予的 scope、可讀寫的資源，以及誰核准
資料去向 是否另存全文、附件、搜尋索引、快取或備份
停用方式 如何撤銷授權、作廢權杖、停止背景工作
可查紀錄 授權變更、API 存取、匯出與管理操作的紀錄位置

這張表最好由業務負責人與管理者一起核對。只看採購清單，容易遺漏員工自行授權的工具；只看登入紀錄，也可能漏掉背景執行的應用程式。

Microsoft Entra 提供檢視管理者與使用者同意權限的介面及 API，可以作為有使用該平台的團隊的盤點入口。檢閱企業應用程式權限

權限調整則應從實際工作出發。例如只需處理單一專案的工具，就評估是否能限制在該專案；只需讀取的同步工作，就移除不必要的寫入或管理能力。若產品無法提供足夠細的限制，就把這項限制記入選型與風險評估。

六、AI agent 參與研究時，應該怎麼看成果？

討論 AI agent 的攻防能力，可以先把工作拆開：發現入口、辨認權限、測試可達資源，以及確認實際影響。工具可能協助其中一部分，研究者仍需要留下足以驗證結論的證據。

判斷一份研究的份量時，我會特別看這幾個問題：測試從什麼初始權限開始？哪些步驟由人操作？時間從哪個節點計算？最後展示的是「可能存取」，還是已確認的讀取或修改能力？

這些問題是閱讀研究的方法，也適用於沒有使用 AI 的測試。單一完成時間，無法取代對前提、過程與影響的了解。

研究授權也要另外確認。Anthropic 的公開揭露政策要求提供漏洞位置、技術細節、重現步驟與影響，並規範研究過程中的行為。這份一般政策可以幫助理解通報需要哪些證據；個別測試仍要依實際適用的方案與約定評估。Anthropic Responsible Disclosure Policy

七、使用 Claude 的團隊，現在可以怎麼做？

先核對服務商正式通知中涉及的產品、帳號與資料類型，再對照自己的使用方式。如果公司也把 AI 或自動化工具接進文件、工單與通訊系統，就把這些連接納入前面的盤點。

對自己管理的整合，一旦有具體暴露證據，處置應沿著權限與資料流進行：停用相關連接、撤銷可持續存取的憑證、保全紀錄，並確認已複製資料的範圍。是否輪替某組 API key，要依它有沒有出現在受影響系統、日誌或資料副本中判斷。

我更希望這類事件留下的成果，是團隊能回答三件事：哪個工具能讀哪些資料、出事時誰能把它停下來，以及如何證明它已經失去存取能力。 這些答案會直接影響下一次事件的處理速度。

延伸閱讀：Tailscale Tailworm 與 SSH 權限邊界。