その権限はバックアップのためだった
10 月 2 日、Apple は macOS のフルディスクアクセスに新たな制御を加えると発表した。バックアップアプリを動かすために作られた設定だが、「AI エージェントがより有能で自律的になるにつれ、このレベルのアクセスに伴うリスクは大幅に増大する」からだという。きっかけは、ある記者がメッセージのデータベースを 187,462 行目まで同期されたと語る Meta の Muse と、Patrick Wardle が見つけた ChatGPT の Mac アプリの脆弱性だった。コーディングエージェントは、自分を起動したターミナルから同じ範囲のアクセスを受け継ぐことがある。そしてエージェントが読める開発者の秘密情報は、そもそもこの権限の内側にあったことがない。Bromure Agentic Coding では、エージェントは Mac のプロセスではない。共有したフォルダとダミーの認証情報だけを持つ Linux VM の中で動く。
Apple がフルディスクアクセスを作ったのは、バックアップアプリがすべてを読めるようにするためだった。いま AI エージェントが同じ範囲を求めており、開発者の Mac では、何も尋ねずにターミナルからそれを手に入れることが多い。
10 月 2 日、Apple は開発者向けニュースページに Updates to Full Disk Access in macOS という短い告知を掲載した。そこではこの設定が存在する理由がこう説明されている。「フルディスクアクセスは、バックアップアプリが Mac 上で正しく機能できるよう、これらの制御を大部分迂回する」。続いて、一部の開発者がこれを使って何をしてきたかが書かれている。「ファイル、メール、メッセージ、さらには閲覧履歴まで、システム上のあらゆるものを、ユーザーが十分に認識し理解しないまま公開している」。
Apple は、このアクセスを許可したいユーザーが「非常に明示的なユーザー操作によってのみ」それを行えるよう、制御を追加する。いま動く理由も示した。「AI エージェントがより有能で自律的になるにつれ、このレベルのアクセスに伴うリスクは大幅に増大する」。
Apple は時期を示しておらず、すでに許可されている分がどうなるかも明らかにしていない。それでもこの告知から、エージェントがフルディスクアクセスを持つことを Apple がどう見ているかははっきりわかる。
2 週間に 2 つの出来事
TechCrunch をはじめとする報道は、この告知を 2 つの出来事と結びつけた。
Muse とメッセージのデータベース。 9 月 19 日、Inc. のコラムニスト Jason Aten は、自分の Mac 上の Meta の Muse エージェントが、ポッドキャストの共同ホストと交わしたばかりの会話をもとにしたコラムを提案する通知を送ってきたと報じた。彼は Muse にメッセージへのアクセスを許可しなかったと言う。にもかかわらず、Muse がメッセージのデータベースを 187,462 行目まで同期していたことに気づいた。Muse 自身の設定では、フルディスクアクセスはオフと表示されていた。 Meta はこの説明に反論している。Meta Superintelligence Labs の David Singleton は、Muse がメッセージを読めるのは「アプリケーションレベルの権限と、macOS に組み込まれたシステムレベルの保護という 3 つの別々のステップ」を経た後だけであり、それは「たとえ Muse アプリケーションにバグがあっても回避できない」と述べた。Muse 自身は Aten に、彼の「デバイスの通知」を同期していたと答えた。
Objective-See Foundation の Patrick Wardle は、アプリがこの権限を得たときに何を意味するかをこうまとめた。「(root 以外の)あらゆるファイルが読める。閲覧履歴、ブラウザの Cookie、チャットなど」。
ChatGPT の Mac アプリ。 同じ週、Wired は Wardle が OpenAI の macOS 版 ChatGPT アプリに見つけた脆弱性 CVE-2026-100754 を報じた。このアプリは、どのローカルプロセスを信頼するかをコード署名とプロセスの親子関係で判断していた。信頼されたスクリプトインタプリタに信頼できない入力を与えることができ、そのため Mac 上ですでに動いている普通のコードが、許可されたプロセスの連鎖に紛れ込み、アプリの信頼された機能を操作できた。チャット履歴や、ブラウザセッションのような接続済みの連携機能だ。OpenAI はビルド 26.924.20706 で修正し、9 月 25 日から本番に出ている。実際に悪用されたという報告はない。
どちらの話も前提は同じだ。Mac 上のエージェントはあなたとして動き、エージェントが読めるものは、エージェントを乗っ取ったコードもすべて読める。
ターミナルはすでに「はい」と言っていた
Muse は Apple のモデルが想定する通り、システム設定からフルディスクアクセスを求めた。ターミナルで動くコーディングエージェントは何も求めず、ターミナルの許可のもとで動く。
macOS はプライバシー権限を責任を持つアプリに対して確認する。コマンドラインツールの場合、それは起動元のターミナルだ。多くの開発者は何年も前に、find
や rsync、バックアップスクリプトが出す確認を止めるため、ターミナル、iTerm、あるいはエディタにフルディスクアクセスを与えている。そのウィンドウから起動したプロセスはすべて、その許可を受け継ぐ。Claude
Code、Codex、Gemini CLI はもちろん、npm install のあらゆる postinstall スクリプト、それらが起動するあらゆる MCP
サーバー、README に乗せられて実行したあらゆるワンライナーもだ。
この構成では、Apple が挙げたファイルはエージェントにも、エージェントが実行するすべてのものにも手が届く。
~/Library/Messages/chat.db、Muse が同期したとされるメッセージの履歴~/Library/Mail、すべてのメールボックス~/Library/Safariとそのコンテナにある Safari の履歴と Cookie- メモ、写真ライブラリ、ほかのアプリのプライベートなコンテナ
秘密情報は確認ダイアログの内側にはなかった
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 の新しい制御は、大きな権限一つを与えにくくする。ノートパソコン上のコーディングエージェントは、攻撃者があなたのリポジトリに push したり AWS アカウントを開けたりできるファイルに届くのに、その権限を必要としていなかった。コーディングエージェントを狙うインフォスティーラーは、すでにこうしたファイルを収集している。アクセストークンとリフレッシュトークン、MCP の設定、プロンプト履歴だ。
どのアプリがフルディスクアクセスを持っているかを確かめる前に、エージェントのコンピュータに何が入っているかを見てほしい。
Bromure では、エージェントは Mac のプロセスではない
Bromure Agentic Coding は、各マシンのエージェントを Apple の Virtualization.framework 上の Ubuntu VM の中で動かす。Claude Code、Codex、Grok などは、Linux カーネル上の Linux プロセスだ。Mac のファイルシステム上のファイルを開くことがないので、macOS のプライバシー権限は適用されない。受け継ぐ許可もなければ、権限がエージェントに漏れるターミナルもない。Bromure で目にするターミナルは VM につながっていて、Mac のシェルにはつながっていないからだ。
VM から見えるものは短いリストに収まる。
- 専用のシステムディスク。署名済み Ubuntu イメージのコピーオンライトのクローン。
- 専用のホーム
/home/ubuntu。プライベートなディスクイメージ上にある。 - そのマシンと共有したフォルダ。最大 8 つで、それぞれ名前でホームの下にマウントされる。
~/code/paymentsを共有すると、エージェントには~/paymentsが見える。~/codeは見えず、~/Libraryは決して見えない。 - 起動ごとの小さな設定用共有。読み取り専用で、プロキシの設定とダミーの認証情報が入っている。
chat.db はこのリストにない。メールも Safari の履歴もない。Muse のような同期処理も、プロンプトインジェクションを受けて「文脈として最近のメッセージを要約して」と指示されたエージェントも、~/Library/Messages
が存在しないことに気づくだけだ。VM にはそこへ通じるパスがない。
開発者の秘密情報はダミー
これで Apple のリストはカバーできた。Bromure は、Apple の告知が触れていないリスト、つまり dotfiles もカバーする。
本物の認証情報は暗号化されて Mac に残る。VM には正しい形をしたダミーが渡される。GH_TOKEN は ghp_ に GitHub
が拒否する 36 文字を続けたもの、ANTHROPIC_API_KEY は sk-ant-api03-brm-… で、~/.git-credentials、~/.docker/config.json、~/.kube/config
には偽物が入っている。Mac 上のプロキシは、リクエストが VM を出た後で本物の値を差し込む。それも、その認証情報の持ち主であるホストに向かうリクエストの場合に限る。マニュアルの言葉を借りれば、「VM
内のどのファイル、環境変数、プロセスにも、本物の API キー、OAuth トークン、AWS シークレット、SSH 秘密鍵が含まれることはない」。
広範な許可に対する Apple の懸念には、次の 2 つが答えになる。
- AWS のインポートが求めるのは、Mac 上の 1 フォルダだけ。 AWS プロファイルを取り込むとき、Bromure は
~/.awsだけに対する security-scoped な許可を求める。フォルダは Mac 上で読まれ、VM にマウントされることはない。これこそ Apple の告知が求める狭く明示的な許可であり、それを受け取るのはホストアプリで、エージェントではない。 - SSH 鍵は Mac に残る。 VM の
SSH_AUTH_SOCKは Mac 上のエージェントへのブリッジだ。ゲストは署名を依頼できるが、秘密鍵のバイト列が VM に入ることはない。macOS のログインセッションの ssh-agent が VM に公開されることもない。
Claude Code が Bromure 経由でサインインするとき、OAuth フローは Mac のブラウザで実行され、トークンは Mac に保存される。VM
の ~/.claude に本物のトークンはない。コーディングエージェントを狙うインフォスティーラーが探すのは、まさにこのファイルだ。
ブラウザにも専用のディスクがある
Apple は閲覧履歴を挙げ、Wardle は Cookie を挙げた。Bromure のエージェントはブラウザを持っている。組み込みの browser MCP
サーバーを通じてエージェントが操作する、フル機能の Chromium だ。それはエージェントのマシンとも Mac とも別の、使い捨ての 2 台目の VM
で動く。既定ではそのディスクはブラウザを閉じると削除される一時的なクローンなので、Cookie もログインも履歴も一緒に消える。Safari の履歴やデスクトップの
Chrome プロファイルにはアクセスできない。それらは Mac にあるからだ。
外に出るものはすべて Mac を通る
仮にエージェントが、共有したプロジェクトフォルダから盗む価値のあるものを集めたとする。出口は一つしかない。VM の仮想スイッチはすべての Web 接続を Mac 上のプロキシへ迂回させ、ゲストはそれを無効にできない。
- 既定のトレースレベルでは、すべてのリクエストが Mac 上の暗号化されたトレースに書き込まれ、モデルとのやり取りはエージェントが発行したツール呼び出しやシェルコマンドに分解される。Trace Inspector には、見知らぬホストへの POST が起きたその瞬間に表示される。
- Mac 上で適用されるマシンの送信ファイアウォールは、プロジェクトに必要なホストだけを許可し、それ以外をすべて破棄できる。
- ペイロードにダミーの認証情報が含まれていれば、プロキシは、発行先ではないホストへ向かう認証情報を検知する。HTTP 451 で応答して VM を一時停止し、Mac に This environment may have been compromised という警告を開く。
ローカル IPC の手口には Mac のプロセスが要る
CVE-2026-100754 は、「Mac 上ですでに動いている権限のないコード」が ChatGPT アプリのローカルな信頼チャネルに届くことが前提だった。ノートパソコンでは、あなたとして動くコードの最も活発な出どころは、たいていコーディングエージェントだ。インストールする依存関係、実行するスクリプト、ダウンロードするツール。Bromure ではそのコードは Linux ゲストの中で動く。Mac の XPC サービスや Unix ソケット、その背後のデスクトップアプリは、別のカーネルにある。VM 内の悪意ある postinstall スクリプトが、Mac 上のプロセスの連鎖に加わることはできない。
仕事ごとに 1 台のマシン
エージェントにどこまで見せるかは、共有フォルダで決まる。Bromure のマシンはそれぞれ専用のフォルダリスト、専用の認証情報、専用のホームを持つので、習慣にするのは簡単だ。
- プロジェクトごとに専用のマシンを用意し、そのプロジェクトのフォルダだけを共有する。
- マシンには、そのプロジェクトが使う認証情報だけを与える。新しい MCP サーバーやエージェントのプラグインを試す実験用マシンには何も与えない。
- Prompt before write はオンのままにしておく。GitHub、クラウドプロバイダ、レジストリ、Kubernetes、データベースについては、新しいマシンの既定値だ。push や削除は、正確な操作内容を示す macOS のダイアログで止まる。
- ホームフォルダは決して共有しない。エージェントには必要ない。
マシンを起動するたびにホームのコピーオンライトのチェックポイントも作られるので、エージェントがそこで削除したものは Rewind home… で取り戻せる。
受け継ぐ macOS 権限はない
エージェントは VM 内の Linux プロセスだ。ターミナルのフルディスクアクセスのもとで動くことはなく、メッセージ、メール、Safari のデータはそのディスクにない。
選んだフォルダだけ
各マシンに見えるのは、専用のホームと、名前を指定して共有した最大 8 つのフォルダだけ。~/Library を含め、Mac
のそれ以外の部分はそこにない。
dotfiles の中身は偽物
Git、クラウド、レジストリ、モデルの認証情報はダミーだ。SSH 秘密鍵は VM に入らない。Mac 上のプロキシが、通信路の上で本物の値を加える。
すべての出口が記録される
Web トラフィックはホストのプロキシを通る。記録され、送信ファイアウォールで絞り込まれ、ダミーが別のホストへ向かえば VM の一時停止とともに止められる。
エージェントに専用のコンピュータを
Apple の告知は、OS ベンダーが開発者に向けて、バックアップソフトのために設計された権限は自律的なエージェントにはふさわしくない、と伝えるものだ。Apple は正しい。ただしその解決策はより明確な確認ダイアログであり、ユーザーは自分の持ち物すべてが入った Mac の上で、アプリごとに正しい選択をし続けなければならない。
Bromure はエージェントに専用のコンピュータを与える。そこにあるのは共有したプロジェクトと、Mac 上のプロキシが本物と差し替えたときにだけ機能する鍵だ。Apple の新しいダイアログが登場しても、あなたのコーディングエージェントがそれを出すアプリの一つになることはない。