```
Google's Gemini may be preparing to broaden the permissions granted to its macOS build considerably, loosening the access relationship between the assistant and the Macs it runs on. Code references found inside a recent internal build for macOS suggest the assistant may soon be able to read files, launch applications, browse the web and perform actions across the operating system without prompting for permission on each step, according to a teardown published by BleepingComputer.
The finding is a code discovery, not an announced feature. Google has not confirmed any such capability, no release date exists, and features that surface in internal builds are routinely shelved or shipped in heavily limited form. Nothing in the reports reviewed suggests the tool would arrive with broad access enabled by default. Readers — and procurement teams — should treat the details as provisional.
That caveat aside, the discovery matters less for the raw capability than for the permission model it implies. Apple's macOS has long pushed app access behind an explicit gatekeeping layer: user consent, scoped permissions, and per-app prompts enforced through the system's privacy controls, with Full Disk Access as the outer boundary. An agent-style assistant that runs continuously across files, apps and the web would effectively be designed to sit on the far side of that boundary — standing access granted once, rather than consent asked for every time. Apple's own automation tooling follows a similar pattern, which gives IT teams a useful reference point: those tools are powerful precisely because they are governed, revocable and auditable.
For enterprises running Mac fleets, the shift from "assistant that answers questions" to "assistant that acts with the user's privileges" is the significant development. It elevates desktop AI tools from productivity software into endpoint-grade governance questions, and it converts prompt injection from an interesting security curiosity into a standing-privilege risk. If an attacker can nudge a user's input, and the assistant can then read project files, open internal tools or submit forms as the user, the blast radius looks a great deal larger than a misfired query.
The practical questions for IT and security teams are concrete, and none of them require speculation about Google's roadmap:
- Can access be centrally revoked? If the assistant is granted device-wide permissions at enrolment, is there an administrative switch to withdraw them — across a group, or across the whole fleet?
- Is every action logged? Agent behaviour that reads documents and navigates the web should produce an audit trail that a data protection officer or incident responder can actually read, not just a local chat history.
- Can permissions be scoped? Can access be restricted to non-sensitive directories, excluded entirely from regulated workloads, or segmented by department?
- Where does the data go? File and web-browsing context raises the question of what leaves the device, and under which data-processing terms.
From this publication's perspective, those questions have particular resonance for organisations subject to Hong Kong's Personal Data (Privacy) Ordinance, which generally requires data users to take practicable steps to safeguard personal data held against unauthorised access. Granting an AI assistant standing rights over a Mac that contains customer records, HR data or client project material would amount to a decision about that safeguard — and it is a decision worth revisiting before such a capability ships, not after. To be clear: the teardown makes no mention of the PDPO or Hong Kong regulation; this framing is our own editorial analysis, offered because the permission-model implications are not geographically confined.
None of this is an argument against desktop AI agents. The same access that creates risk is what makes the tools useful. The argument is that agent-style access needs the same governance treatment already applied to privileged scripts, RPA deployments and third-party automation: minimum necessary permissions, central revocation, per-group scoping, and logs that survive scrutiny.
From the BleepingComputer teardown, the platform appears to be moving in a particular direction. Google's actual implementation may be more conservative — permission prompts intact, sandboxing preserved, nothing enabled without explicit consent. But the code suggests that if the assistant is going to be a colleague rather than a lookup tool, the permission model is the first thing to get right, and the first thing to press Google about.
Source: BleepingComputer
據 BleepingComputer 發布的一篇拆解分析，Google 的 Gemini 可能正準備大幅擴大授予其 macOS 版本的權限，使其與所運行的 Mac 電腦之間的存取關係更為寬鬆。分析指，近期一個適用於 macOS 的內部版本中所發現的代碼顯示，這款助理程式或很快便能讀取檔案、啟動應用程式、瀏覽網頁，並在整個作業系統內執行各項操作，無須每一步都要求用戶確認權限。
此發現屬代碼層面的分析結果，並非官方宣佈的功能。Google 並未證實具備任何此類能力，亦無正式推出日期，而一些在內部版本中出現的功能，往往最終被擱置，或以大幅限制的形式推出。已審閱的報告內容未有顯示，該工具將預設開啟廣泛的存取權限。讀者——以及採購團隊——宜將上述細節視為初步資料。
撇開這點不談，這次發現的重要性，與其說在於其原始能力，不如說在於它所暗示的權限模型。長久以來，Apple 的 macOS 將應用程式的存取權限制於一個明確的管制層面：包括用戶同意、範圍受規限的權限，以及透過系統私隱控制所強制執行的逐個應用程式提示，而「全碟存取權」（Full Disk Access）則是這層管制的最外圍界線。一個能夠跨越檔案、應用程式與網頁持續運行、以 agent 模式運作的助理程式，在設計上實際上將會置身於這條界線的另一邊——即權限一經授予便長期有效，而非每次操作都須重新徵求同意。Apple 自家的自動化工具亦採用類似模式，這為 IT 團隊提供了一個有用的參考點：那些工具之所以功能強大，正是因為它們受到規管、可隨時撤回，而且可作審計。
對於營運 Mac 電腦機隊的企業而言，從「回答問題的助理」轉變為「以用戶權限執行操作的助理」，是這次發展的關鍵所在。它將桌面 AI 工具的地位，由生產力軟件提升至牽涉終端裝置治理的層面，同時亦將 prompt injection（提示注入）由一則有趣的安全研究案例，轉化為一種長期權限所帶來的風險。如果攻擊者能操弄用戶輸入的內容，而助理程式繼而可以讀取專案檔案、開啟內部工具，或以用戶身份提交表格，則其所造成的影響範圍，將遠大於一次錯誤的查詢。
IT 與保安團隊需要面對的實際問題具體明確，而且全都無須對 Google 的發展藍圖作出揣測：
- 相關權限能否集中撤回？如果助理程式在裝置登記時便獲授予全機權限，是否有一個管理層面的開關，可將權限收回——無論是針對某個群組，抑或整個機隊？
- 每一項操作是否都有記錄？一個會讀取文件及瀏覽網頁的 agent，其行為應產生一份數據保護主任或事件應變人員能夠實際閱讀的審計記錄，而不僅僅是本地的聊天紀錄。
- 權限能否被劃分範圍？能否將存取限制於非敏感的目錄內、完全排除於受規管的工作範疇之外，抑或按部門分隔？
- 數據最終流向哪裡？檔案與網頁瀏覽的內容，引申出哪些資料離開裝置、以及在哪些數據處理條款下進行的問題。
從本刊的角度來看，以上種種問題，對受香港《個人資料（私隱）條例》規管的機構尤其值得關注。該條例通常要求資料使用者，須採取切實可行的措施，保障其持有的個人資料免遭未經授權的查閱。賦予一個 AI 助理程式長期存取權，對象卻是一部存有客戶紀錄、人力資源資料或客戶專案材料的 Mac 電腦，實質上等同於就該項保障措施作出一個決定——而這個決定，值得在相關功能正式推出之前重新檢視，而非事後才補救。在此需要說明：該篇拆解分析並未提及《個人資料（私隱）條例》或香港法例；上述框架屬本刊的編輯分析，之所以提出，是因為權限模型所帶來的影響並不受地域所限。
這一切並非反對桌面 AI agent 的論點。造成風險的同一項存取能力，正是令這些工具變得實用的原因。論點在於，agent 模式的存取權，需要獲得與特權腳本、RPA 部署及第三方自動化系統相同的治理待遇：包括最低限度的必要權限、集中撤回機制、按群組劃分範圍的權限設定，以及能夠經得起審視的日誌記錄。
從 BleepingComputer 的拆解分析可見，該平台似乎正朝著某個方向發展。Google 的實際做法可能更為保守——權限提示維持不變、沙盒機制得以保留，未經明確同意便不會啟用任何功能。然而，代碼所暗示的是：若這款助理程式將成為一位同事，而非單純的查閱工具，權限模型便是首要須處理妥當的一環，亦是首要須向 Google 追問的一環。
資料來源：BleepingComputer