Computer Use公共预览的安全设计：应用、动作与数据三维门禁

Computer Use把AI从“告诉你怎么点”变成“它自己点”。这对没有API的老软件很有价值，也把风险从错误回答升级为真实操作。开发者最该关心的不是“它能识别多少按钮”，而是每个动作能否被应用边界、操作类型和数据敏感度三重约束。

发布与可核验事实

GitHub在2026年10月1日宣布，Computer Use在GitHub Copilot CLI和GitHub Copilot应用中进入公共预览，覆盖macOS与Windows。它可读取辅助功能内容与视觉上下文，完成点击、输入、按键、滚动、拖拽和跨应用导航。官方定位是补足无API、无命令行界面、无模型上下文协议（MCP）集成的GUI工作流。

官方还明确：Copilot控制应用前会请求批准，用户可检查或重置“始终允许”的应用，组织管理设置可禁用该功能。在macOS上，还会引导用户开启辅助功能与屏幕录制权限。但“允许某个应用”只是第一层，并不能表达“允许幻灯片读取，但每次对外发送都要问”。

为什么要特别警惕“始终允许”？因为应用身份不等于业务意图。同一个浏览器既能读公开文档，也能打开邮箱、银行后台和密钥管理页。同一个文档应用既能编辑本地草稿，也能点击共享链接把内容发往外部。权限如果只细到应用级，便会把影响完全不同的动作压成一个开关。

技术原理：把观察、决策、执行拆开

一次桌面任务至少有三段：先从屏幕截图或辅助功能树得到观察，模型再选择目标与动作，最后操作层输入或点击。安全检查应在“决策已结构化，执行尚未发生”的窗口进行：先把应用标识、动作类型、目标文本、数据类型和是否对外发送交给策略器，再返回自动、询问或拒绝。

这个门禁必须位于模型之外。如果让同一个模型同时决定动作和判断“本次是否安全”，恶意页面里的提示注入就可能同时污染两次决策。

最小权限还要考虑时间。用户批准“本次把数据填入幻灯片”，不应自动变成一周内所有写入都允许。更稳妥的权限单元是“任务+应用+动作+目标范围+有效期”。任务结束、窗口内容变化或出现新收件人时，旧批准应自动失效。

最小实践：三维动作门禁

依赖安装：无。保存为desktop_gate.py，运行python3 desktop_gate.py。

POLICY = {
    "browser": {"read": "auto", "write": "ask"},
    "slides": {"read": "auto", "write": "ask"},
    "password_manager": {"read": "deny", "write": "deny"},
}

def decide(app, action, contains_sensitive=False):
    if contains_sensitive:
        return "deny"
    return POLICY.get(app, {}).get(action, "deny")

cases = [
    ("browser", "read", False),
    ("slides", "write", False),
    ("password_manager", "read", False),
    ("browser", "write", True),
]

result = [decide(*case) for case in cases]
print(result)
assert result == ["auto", "ask", "deny", "deny"]

默认策略是“不在白名单就拒绝”；写入需要询问，密码管理器和敏感数据直接拒绝。本文示例已用Python 3.9.6在本次任务中实际运行，四个结果与断言一致。未安装或开启GitHub Copilot Computer Use，没有对真实桌面进行自动操作。