フルディスクアクセスは許可しにくくなる。でも、ターミナルはすでに持っているかもしれない

Apple は10月2日、開発者向けニュースのページに短い告知を掲載しました。フルディスクアクセス (Full Disk Access) は、アプリが Mac 上のほぼすべてを読めるようにする macOS の権限です。この権限の許可のハードルが上がります。Apple が挙げる理由はエージェントです。エージェントの能力と自律性が高まるにつれて、このアクセスのリスクは「大幅に高まる」としています。

告知が扱っているのは許可する瞬間です。ターミナルでコーディングエージェントを動かしている開発者にとって、その瞬間がそもそもあったとすれば、おそらくエージェントが登場するずっと前のことで、権限はターミナルに与えられています。

Apple は実際に何を発表したのか？

方向性だけで、日付はありません。開発者向けの告知によると、フルディスクアクセスはバックアップアプリが動くために存在し、本来なら個人データを守る制御を迂回します。

Full Disk Access largely sidesteps these controls in order to allow backup apps to function properly on the Mac. Some developers are using Full Disk Access in ways that could put users at risk, exposing everything on their systems—including files, mail, messages, and even browsing history—without users’ full knowledge and understanding.

Apple によれば、許可したいユーザーは「非常に明示的な操作によってのみ許可できる」ようになります。その操作がどんなものか、どの macOS リリースで導入されるのか、すでに権限を持つアプリにも改めて確認が求められるのかは、告知に書かれていません。TechCrunch がこの点を質問しましたが、Apple は回答していません。

バックアップ用の権限の告知に、なぜ AI エージェントが出てくるのか？

エージェントが、この権限を求める新しい理由になったからです。TechCrunch は Meta の Muse を例に挙げています。Muse はオプションでフルディスクアクセスを有効にします。Inc. のコラムニストは、Muse が許可なくコラムニスト本人のプライベートなメッセージを読んだと報じ、Meta はこれを否定しています。同じ記事は、ChatGPT の Mac アプリにユーザーデータを露出させかねない欠陥があったという Wired の報道にも触れています。ディスクをバックアップするためのアプリは、ディスクを読んでコピーします。同じ権限を持つエージェントは、ディスクを読んでから次に何をするかを自分で決めます。

ターミナルから起動したコーディングエージェントは、ターミナルのフルディスクアクセスを得るのか？

Apple の DTS エンジニアが説明するルールに従えば、通常のケースでは得られます。Apple の告知にも TechCrunch にもターミナルの話は出てこないので、この部分は開発者フォーラムが情報源です。こうした権限の背後にあるプライバシー層である TCC は、「responsible code」(責任のあるコード) を探すことで、誰がアクセスを求めているのかを判断します。ユーザーがターミナルからツールを実行した場合、責任のあるコードはターミナルです。別の DTS エンジニアは、そこから何が起きるかをはっきり書いています。

This is actually how granting FDA to Terminal.app allows "cp" to copy things it couldn't otherwise copy. Terminal doesn't copy anything, but all of it's child processes inherit it's access level, so now Terminal.app-> tcsh* -> cp means "cp" has FDA as well.

cp をコーディングエージェントに置き換えても、連鎖は同じです。エージェントはシェルの子プロセスで、エージェントが実行するコマンドはさらにその子プロセスです。TCC がそれらのアクセスをフルディスクアクセスを持つターミナルに帰属させるなら、どれも自分自身の許可を必要としません。これは Apple の例から導いた推論で、Apple が特定のエージェントで検証したものではありません。同じスレッドには、アプリが起動したプロセスはそのアプリに帰属するとも書かれています。つまり、この権限を持つデスクトップのエージェントは、自分が実行するツールに権限を渡せます。

cp との違いは、誰がコマンドを選んだかです。cp はあなたが入力したものをコピーしました。エージェントは読んだ内容をもとに何を実行するかを決めます。そして、読んだものの一部は、あなたが書いていないリポジトリから来ています。

例外もあり、Apple もそれを指摘しています。Xcode のように、ランチャーが責任を引き渡すこともできますし、launchd が起動するヘルパーは別のルールに従います。責任のあるコードについて説明したエンジニアは、正確なアルゴリズムは「文書化されておらず、過去に変わったことがあり、今後も変わる可能性が十分にある」とも書いています。新しい制御がこの帰属の仕組みに影響するのかどうか、Apple は明らかにしていません。

「非常に明示的な操作」は何から守るのか？

告知の範囲で言えば、次の許可からです。すでに与えられた許可について Apple は何も言っておらず、それが明らかになるまでは、許可の段階でハードルを上げても、すでに渡したアクセスには何の効果もありません。Muse のように、エージェント自身がディスク全体を求める一般向けアプリについては、正しいタイミングを押さえていると思います。開発者の Mac は事情が違います。ディスクへのアクセスがそもそも許可されているなら、それはエージェントを動かしているアプリ (ターミナル) に与えられています。そしてターミナルは、どの子プロセスのために読んでいるのかを決して伝えません。

以前、インストールしたツールは、あなたと同じ範囲に手が届くと書きました。プロセスは起動した人の権限をそのまま持ち、それは一度決まったら二度と問い直されません。Mac でこのパターンを崩すのが、アプリごとに許可を求める TCC の層です。アカウント全体を渡す代わりに、アプリごとに確認します。ターミナルにフルディスクアクセスを与えると、TCC が分けていた権限の多くが ambient authority (プロセスに最初から付いてくる権限) に戻ってしまい、ターミナルが起動するものはすべて、ほかの権限が許す範囲でフルディスクアクセスの保護対象データに届きます。確認画面を厳しくしても、一度与えた許可がカバーする範囲は変わりません。変えられるのは、権限を絞ることだけです。

Mac の開発者が今週確認すべきことは？

システム設定を開き、プライバシーとセキュリティ、フルディスクアクセスと進んで、使っているターミナルの横のスイッチがオンになっているか確認してください。リストに載っているだけでは、スイッチがオンとは限りません。ブロックされたアプリもそこに表示されることがあります。オンになっていたら、理由を考えてみてください。ある作業が本当にディスク全体を必要とするなら、DTS のエンジニアが議論していたもっと狭い設計は、その作業専用のツールにアクセスを与え、汎用のインタープリタには決して与えないこと、そして TCC が本当にそのツールにアクセスを帰属させているかをテストすることです。これで許可はターミナルから外れます。ただし、エージェントがサンドボックス化されるわけではありません。フルディスクアクセスがなくてもアカウントが届く範囲はすべて残っていて、それを取り上げるのは封じ込めという別の仕事です。

Apple は次の「はい」を言いにくくしています。ターミナルに出した「はい」はターミナルに与えられたもので、エージェントは後からやって来ました。