Computer Use公共预览的安全设计：应用、动作与数据三维门禁
内容提要
GitHub Computer Use 进入公共预览，可自动操作桌面 GUI，风险从错误回答升级为真实操作。文章主张在模型外设三维门禁：按应用、动作类型和数据敏感度决定自动、询问或拒绝；权限应绑定任务与有效期，敏感数据直接拒绝，执行前复核关键字段，日志最小化。
延伸解读
应用级授权为何不够
文章指出，仅允许某个应用并不能表达业务意图。同一个浏览器既能读公开文档，也能打开邮箱、银行后台和密钥管理页；同一个文档应用既能编辑本地草稿，也能点击共享链接外发内容。若权限只细到应用级，就会把影响完全不同的动作压成一个开关，导致“始终允许”带来过度授权风险。
策略器必须独立于模型
安全检查应在决策已结构化、执行尚未发生的窗口进行，由模型之外的策略器根据应用标识、动作类型、目标文本、数据类型和是否对外发送返回自动、询问或拒绝。文章强调，若让同一个模型同时决定动作和判断安全性，恶意页面中的提示注入可能同时污染两次决策，因此门禁必须外置。
权限应绑定任务与有效期
用户批准“本次把数据填入幻灯片”不应自动变成一周内所有写入都允许。更稳妥的权限单元是“任务+应用+动作+目标范围+有效期”。任务结束、窗口内容变化或出现新收件人时，旧批准应自动失效。这能避免一次授权被长期复用，降低界面变化后误操作的风险。
日志最小化与试点路径
文章提醒，审计日志不应存全屏截图、密码框内容或整份客户文档，保留任务ID、应用标识、动作类型、策略结果、批准人和执行回执即可，并设定短保留期。试点应先选只读、可重现、无个人数据的流程，再开放本地草稿写入，最后才考虑对外发送，每扩大一层权限都应有新的验收门槛。
Q&A
GitHub Computer Use 是什么？它有什么风险？
GitHub Computer Use 是 GitHub 在 2026 年 10 月 1 日宣布进入公共预览的功能，覆盖 macOS 与 Windows，可自动操作桌面 GUI，完成点击、输入、按键、滚动、拖拽和跨应用导航。它把 AI 从“告诉你怎么点”变成“它自己点”，风险也从错误回答升级为真实操作。
为什么仅按应用授权（如“始终允许”）不够安全？
因为应用身份不等于业务意图。同一个浏览器既能读公开文档，也能打开邮箱、银行后台和密钥管理页；同一个文档应用既能编辑本地草稿，也能点击共享链接把内容发往外部。权限如果只细到应用级，便会把影响完全不同的动作压成一个开关。
三维动作门禁具体指哪三个维度？如何决策？
三维门禁指应用边界、操作类型和数据敏感度。决策时，策略器根据应用标识、动作类型、目标文本、数据类型和是否对外发送，返回自动、询问或拒绝。例如，浏览器读取可自动，写入需询问；密码管理器读写直接拒绝；包含敏感数据则拒绝。
为什么安全检查必须放在模型之外？
如果让同一个模型同时决定动作和判断“本次是否安全”，恶意页面里的提示注入就可能同时污染两次决策。安全检查应位于模型之外，在“决策已结构化，执行尚未发生”的窗口进行，由独立策略器返回自动、询问或拒绝。
如何防止“界面在确认后变了”的检查时机攻击？
高风险执行前应重新读取关键字段，与批准摘要比较；不一致就立即停止，而不是试图自行推断哪个值更“像是对的”。例如，用户看到的是 A 账户与 100 元，Agent 实际点击时页面可能已切换为 B 账户或 1000 元，此时必须停止。
Computer Use 的日志记录应遵循什么原则？
日志本身也要最小化。保留任务 ID、应用标识、动作类型、策略结果、批准人和执行回执，不代表要存下全屏截图、密码框内容或整份客户文档。敏感观察可用摘要、字段标签或受控存储代替，并设定短保留期，避免新建高价值数据泄漏面。
如何安全地试点 Computer Use？
先选只读、可重现、无个人数据的流程，记录目标识别错误、人工打断和完成率；然后再开放本地草稿写入；最后才考虑对外发送。每扩大一层权限，都应有新的验收门槛，不是沿用上一层的成功率。
