苹果收紧 macOS 上的全盘访问权限，以应对 AI 代理风险

全盘访问权限的存在，是因为备份软件需要绕过 macOS 的沙盒保护机制，以复制用户的整个磁盘 ^[3]。苹果自身的表述将全盘访问权限定义为一种“在很大程度上绕过”正常隐私保护机制的权限——这正是为何将该权限授予一个始终在线的 AI 代理，与授予 Time Machine 或定时备份工具存在本质区别 ^[3]。苹果在2026年10月2日的声明中承认，一些开发者正以可能使用户面临风险的方式使用全盘访问权限，暴露其系统中的所有内容，包括文件、邮件、消息甚至浏览历史，而用户对此并未完全知情或理解 ^[1]。这一角度追溯了为何一项为狭窄、非持续性用途设计的权限，竟成为一类截然不同的软件的默认请求项。

使这一风险具象化的案例涉及 Meta 的“Muse”AI 代理，多家媒体将该事件直接与苹果的公告联系起来，报道称该代理暴露了其本不应访问的私人对话 ^[6][7]。本研究中查阅的视频报道若属实，详细描述了该事件：Meta 虽然质疑 Muse 自身对数据访问方式的解释，但仍坚持底层权限链按设计运行——争议焦点在于根本原因，而非是否暴露了私密内容——据报道，用户的 Messages 数据库曾被同步了约187,462行数据，尽管系统设置中全盘访问权限显示为关闭状态。这一细节表明，真正的故障点可能在于应用内连接器与系统级开关之间的交接，而非单一开关本身。社区讨论（非苹果官方文档）另提出一项结构性批评：iMessage 在磁盘上以未加密形式存储，这意味着即使全盘访问权限受到更严格授权控制，一旦被授予，消息内容仍将直接暴露。这一角度揭示了“开关显示关闭”为何不足以成为防御理由，以及围绕根本原因尚未解决的争议。

苹果的解决方案并非禁用。公司明确表示，真正希望授予应用这种“非凡级别访问权限”的用户仍可实现——门槛是“非常明确的用户操作”，而非彻底取消该权限 ^[1][5]。开发者评论指出，这一选择内含权衡：增加摩擦可减少随意授权，但频繁的高风险安全提示也可能使用户麻木，导致他们不加阅读便直接点击通过；一些人认为更根本的解决方案应是将 AI 代理作为非特权进程运行，并赋予其细粒度、范围受限的文件权限，而非依赖单一的“全有或全无”开关 ^[5]。苹果尚未说明该变更的发布时间或对应 macOS 版本 ^[1]。这一角度聚焦于苹果选择的设计张力（授权摩擦）与社区提出的替代方案（结构性沙盒）之间的取舍。

苹果的公告发布于行业集中爆发同类威胁模型的一周内：《连线》此前已报道 OpenAI 的 Mac 版 ChatGPT 应用存在可能暴露敏感数据的漏洞 ^[2]。本研究中查阅的视频报道若属实，还描述了当周其他事件：同一 ChatGPT 应用的另一漏洞由安全研究员 Patrick Wardle 发现、一个伪装成虚假 Zoom 安装程序的后门，以及谷歌限制 Android 的辅助功能服务——这些细节表明这是一种更广泛的行业模式，而非孤立案例。此外，有报道揭露谷歌未发布的 macOS 版 Gemini Desktop 应用中存在隐藏的“附加沙盒选项”设置，该设置可让助手在 Mac 上任意位置读取、创建、修改或删除文件，并通过 Mail、Safari 和 Messages 操作而无需逐项确认 ^[4]——谷歌尚未确认或发布此测试功能，但它恰好说明了苹果新规旨在限制的权限范围。这一角度表明，这并非苹果与 Meta 之间的孤立事件，而是苹果、谷歌和 OpenAI 在同一周内同步进行的平台级重新校准。

开发者和高级用户的讨论趋于一致诉求：应为代理提供按文件夹或按文件的权限授予，而非全盘访问权限这种“全有或全无”的开关。另一场平行讨论聚焦于隔离技术而非权限界面——一名自称 Docker 员工的人士指出，普通容器不足以隔离 AI 代理，因其仍可通过挂载的 Docker 套接字或特权模式逃逸，而 microVM 或专用的网络隔离虚拟机才是更可靠的隔离边界。并非所有人都认为收紧权限是正确方向：有人指出全盘访问权限也用于 RAID 设备支持等普通功能，另一些人则反对苹果在用户授权之上再增设自身审批门槛，认为这与 macOS 传统上开放、非 App Store 软件模型不一致。少数人还指出，目前欧盟《数字市场法案》将 macOS 排除在其“看门人”义务之外，与 iOS 不同，因此此次收紧不会引发欧盟对平台开放性的压力。这一角度揭示了剥离公关包装后技术意见的真实落点——争论核心在于隔离架构，而不仅是授权界面。