這個權限原本是給備份用的

10 月 2 日，Apple 在開發者新聞頁面上發布了一則簡短公告，標題是 Updates to Full Disk Access in macOS。公告解釋了這個設定存在的原因：「完整磁碟取用權在很大程度上繞過了這些控管，好讓備份 App 能在 Mac 上正常運作。」接著描述了部分開發者拿它做了什麼：「在使用者未充分知情與理解的情況下，暴露了他們系統上的一切，包括檔案、郵件、訊息，甚至瀏覽紀錄。」

Apple 將加入控管，讓想授予這種存取權的使用者「只能透過非常明確的使用者操作」來授予。Apple 也說明了現在採取行動的理由：「隨著 AI 代理變得越來越有能力、越來越自主，這種層級的存取所帶來的風險將大幅增加。」

Apple 沒有給出日期，也沒有說明既有的授權會如何處理。但這則公告清楚表明了 Apple 怎麼看待落在代理手中的完整磁碟取用權。

兩週內的兩則新聞

對這則公告的報導， 從 TechCrunch 開始，都把它和兩起事件連在一起。

Muse 與訊息資料庫。 9 月 19 日，Inc. 專欄作家 Jason Aten 報導，他 Mac 上的 Meta Muse 代理傳來一則通知，建議他以剛剛和 Podcast 共同主持人的對話為題寫一篇專欄。他說自己拒絕了 Muse 存取訊息的要求，卻發現 Muse 已經把他的訊息資料庫同步到了第 187,462 列，而 Muse 自己的設定顯示完整磁碟取用權是關閉的。 Meta 對這個說法提出異議。Meta Superintelligence Labs 的 David Singleton 表示，Muse 必須經過「三個獨立步驟，包括應用程式層級的權限和 macOS 內建的系統層級保護」才能讀取訊息，而這些保護「即使 Muse 應用程式有 bug 也無法繞過」。Muse 自己則告訴 Aten，它一直在同步他的「裝置通知」。

Objective-See Foundation 的 Patrick Wardle 總結了 App 一旦拿到這個權限意味著什麼：「任何（非 root 的）檔案都可讀取，瀏覽紀錄、瀏覽器 Cookie、聊天內容等等。」

ChatGPT 的 Mac App。 同一週，Wired 報導了 Wardle 在 OpenAI macOS 版 ChatGPT App 中發現的漏洞 CVE-2026-100754。這個 App 依據程式碼簽章和程序的繼承關係來決定信任哪些本機程序。一個受信任的腳本直譯器可以被餵入不受信任的輸入，讓已經在 Mac 上執行的普通程式碼混進一條被接受的程序鏈，進而操控 App 的受信任功能：聊天紀錄，以及瀏覽器工作階段等已連結的整合。OpenAI 在建置版本 26.924.20706 中修正了這個漏洞，該版本自 9 月 25 日起上線。目前沒有任何實際遭到利用的報告。

兩則新聞的前提相同。Mac 上的代理以你的身分執行，凡是它能讀到的，任何接管這個代理的程式碼也都能讀到。

終端機早就答應了

Muse 是透過系統設定申請完整磁碟取用權的，正如 Apple 的模型所預期。終端機裡的程式碼代理什麼都不申請，直接沿用終端機的授權執行。

macOS 會針對負責的 App 檢查隱私權限，對命令列工具而言，就是啟動它的那個終端機。許多開發者多年前就給了終端機、iTerm 或編輯器完整磁碟取用權，好讓 find、rsync 或備份腳本不再跳出詢問。從那個視窗啟動的每個程序都會繼承這份授權。這包括 Claude Code、Codex 和 Gemini CLI，以及 npm install 的每個 postinstall 腳本、它們啟動的每個 MCP 伺服器，還有每一條被 README 說服而執行的單行指令。

在這種設定下，Apple 列出的檔案，代理和代理執行的一切都碰得到：

• ~/Library/Messages/chat.db，也就是 Muse 被指控同步的訊息紀錄
• ~/Library/Mail，每一個信箱
• Safari 的瀏覽紀錄和 Cookie，位於 ~/Library/Safari 及其容器中
• 備忘錄、照片圖庫，以及其他 App 的私有容器

機密從來不在詢問視窗後面

Apple 的改變是對的，它保護了大家認為是隱私的檔案。但開發者工作用的憑證放在別處。下面這些路徑，既不受完整磁碟取用權保護，也不受 macOS 任何其他隱私權限保護：

• ~/.ssh/id_ed25519
• ~/.aws/credentials 和 ~/.aws/sso/cache/
• ~/.config/gh/hosts.yml、~/.git-credentials、~/.npmrc、~/.docker/config.json、~/.kube/config
• 你複製過的每個專案裡的 .env 檔案
• 代理本身的 OAuth 權杖和工作階段紀錄

任何以你的使用者身分執行的程序都能讀取它們，不論有沒有完整磁碟取用權。Apple 的新控管會讓一個大權限更難授予。但筆電上的程式碼代理，本來就不需要這個權限，就能碰到讓攻擊者推送到你的儲存庫、或打開你 AWS 帳號的檔案。鎖定程式碼代理的資訊竊取程式已經在蒐集這些檔案：存取權杖與更新權杖、MCP 設定、提示歷史。

在檢查哪些 App 擁有完整磁碟取用權之前，先看看代理的電腦裡有什麼。

在 Bromure 裡，代理不是 Mac 上的程序

Bromure Agentic Coding 在 Apple Virtualization.framework 之下的 Ubuntu VM 中執行每台機器的代理。Claude Code、Codex、Grok 等都是 Linux 核心上的 Linux 程序。它們從不開啟 Mac 檔案系統上的檔案，所以 macOS 的隱私權限對它們不適用。沒有可以繼承的授權，也沒有會把權限洩漏給代理的終端機，因為你在 Bromure 裡看到的終端機連接的是 VM，不是你 Mac 的 shell。

VM 看得到的東西，只有短短一張清單：

• 它自己的系統磁碟，是一份已簽署 Ubuntu 映像檔的寫入時複製（copy-on-write）副本。
• 它自己的家目錄 /home/ubuntu，放在一個私有的磁碟映像檔上。
• 你和這台機器分享的資料夾，最多八個，各自以名稱掛載在家目錄下。如果你分享 ~/code/payments，代理看到的是 ~/payments。它看不到 ~/code，也永遠看不到 ~/Library。
• 每次開機的一個小型設定分享，唯讀，存放代理伺服器設定和替身憑證。

chat.db 不在這張清單上，郵件和 Safari 的瀏覽紀錄也不在。一個像 Muse 那樣的同步工作，或是一個遭到提示注入、被要求「把我最近的訊息整理成摘要當作背景」的代理，只會發現 ~/Library/Messages 根本不存在。VM 裡沒有任何路徑通往那裡。

開發者機密都是替身

這樣就涵蓋了 Apple 的清單。Bromure 也涵蓋了 Apple 公告略過的那張清單：dotfiles。

真正的憑證加密後留在 Mac 上。VM 拿到的是格式正確的替身：GH_TOKEN 是 ghp_ 加上 36 個 GitHub 會拒絕的字元，ANTHROPIC_API_KEY 是 sk-ant-api03-brm-…，而 ~/.git-credentials、~/.docker/config.json 和 ~/.kube/config 裡放的都是假的。Mac 上的代理伺服器會在請求離開 VM 之後才填入真正的值，而且只在請求要送往該憑證所屬的主機時才這麼做。用手冊的話來說：「VM 內的任何檔案、環境變數或程序，都不會包含真正的 API 金鑰、OAuth 權杖、AWS 密鑰或 SSH 私鑰。」

有兩個細節回應了 Apple 對大範圍授權的擔憂：

• AWS 匯入只要求 Mac 上的一個資料夾。 匯入你的 AWS 設定檔時，Bromure 只針對 ~/.aws 要求一份 security-scoped 授權。這個資料夾在 Mac 上讀取，從不掛載進 VM。這正是 Apple 公告所要求的那種範圍窄、意圖明確的授權，而且它給的是主機 App，從來不是代理。
• SSH 金鑰留在 Mac 上。 VM 的 SSH_AUTH_SOCK 是一座通往 Mac 上 SSH agent 的橋。客體系統可以請求簽章，但私鑰的位元組從不進入 VM。你 macOS 登入工作階段的 ssh-agent 也從不暴露給它。

當 Claude Code 透過 Bromure 登入時，OAuth 流程在你 Mac 的瀏覽器裡進行，權杖存放在 Mac 上。VM 的 ~/.claude 裡沒有任何真正的權杖。而那正是鎖定程式碼代理的資訊竊取程式要找的檔案。

瀏覽器也有自己的磁碟

Apple 提到了瀏覽紀錄，Wardle 提到了 Cookie。Bromure 裡的代理有一個瀏覽器，是代理透過內建 browser MCP 伺服器操控的完整 Chromium。它在第二台用完即丟的 VM 裡執行，和代理的機器、和你的 Mac 都是分開的。預設情況下，它的磁碟是一份臨時副本，瀏覽器關閉時就會刪除，所以 Cookie、登入狀態和瀏覽紀錄都會跟著消失。它無法存取 Safari 的瀏覽紀錄或你桌面版 Chrome 的設定檔，因為那些都在 Mac 上。

所有外流都得經過 Mac

假設代理真的從你分享的專案資料夾裡蒐集到值得偷的東西。它只有一條出路。VM 的虛擬交換器會把每個網路連線導向 Mac 上的代理伺服器，而客體系統無法關掉這個機制。

• 在預設的追蹤層級下，每個請求都會寫進 Mac 上的加密追蹤紀錄，模型往來的內容會被拆解成代理發出的工具呼叫和 shell 指令。Trace Inspector 會在 POST 送往陌生主機的當下就把它顯示出來。
• 機器的對外防火牆在 Mac 上執行，可以只允許專案需要的主機，其餘一律丟棄。
• 如果酬載裡帶著某個替身憑證，代理伺服器會發現一個憑證正被送往不屬於它的主機。它會回應 HTTP 451、暫停 VM，並在 Mac 上跳出警示：This environment may have been compromised。

本機 IPC 手法需要 Mac 上的程序

CVE-2026-100754 的前提是「已經在 Mac 上執行的非特權程式碼」能觸及 ChatGPT App 的本機信任通道。在筆電上，以你的身分執行的程式碼，最活躍的來源往往就是程式碼代理：它安裝的相依套件、它執行的腳本、它下載的工具。在 Bromure 裡，這些程式碼都在 Linux 客體系統中執行。Mac 的 XPC 服務、Unix socket，以及背後的桌面 App，都在另一個核心裡。VM 中的惡意 postinstall 腳本無法加入 Mac 上的程序鏈。

一份工作一台機器

分享資料夾決定了代理能看到多少。每台 Bromure 機器都有自己的資料夾清單、自己的憑證和自己的家目錄，所以好習慣很容易養成：

1. 每個專案都用一台專屬的機器，只分享那個專案的資料夾。
2. 只給機器它的專案用得到的憑證。用來試新 MCP 伺服器和代理外掛的實驗機器，一個都不給。
3. 保持 Prompt before write 開啟，這是新機器針對 GitHub、雲端供應商、套件登錄、Kubernetes 和資料庫的預設值。推送和刪除會停下來，等待一個顯示確切操作內容的 macOS 對話框。
4. 永遠不要分享你的家目錄。代理不需要它。

每次機器開機也會為家目錄建立一個寫入時複製的檢查點，所以 Rewind home… 可以找回代理在那裡刪掉的東西。

給代理一台自己的電腦

Apple 的公告，是一家作業系統廠商告訴開發者：為備份軟體設計的權限，不該交給自主代理。Apple 說得對。它的解法是更清楚的詢問視窗，而使用者仍然得在一台存放著自己一切的 Mac 上，為每個 App 做出正確的選擇。

Bromure 給代理一台自己的電腦。上面有你分享的專案，以及只有在你 Mac 上的代理伺服器換上真品時才有效的金鑰。等 Apple 的新對話框推出時，你的程式碼代理不會是跳出它的 App 之一。