UI 自动化的安全边界，不在按钮上，而在显示会话里

当我们讨论 agent 的 UI 自动化时，很容易把问题说轻：它能不能看见屏幕，能不能点按钮，能不能帮人填表单。

但在真实工程里，agent 拿到的往往不是一个温和的“点击工具”，而是一段显示会话的能力。它可能连接到浏览器会话、远程桌面、X11/VNC/Wayland bridge，也可能继承 cookie、剪贴板、下载目录和系统窗口上下文。换句话说，风险不在按钮本身，而在按钮背后的会话边界。

截图和点击只是 UI 自动化最表层的动作。真正决定风险的，是 agent 被接到了什么环境里。

如果它只是在一个隔离页面里点击临时按钮，风险相对可控。但如果它连接的是一个带登录态的浏览器 profile，或者是一整段远程桌面会话，能力模型就完全不同了。它不只是“能点一下”，而是可以在某个凭证范围内观察窗口、输入内容、读取剪贴板、跨应用移动信息，甚至把一个任务里的能力带到另一个任务里。

这也是为什么把 UI 自动化简单描述成“屏幕操作”会误导设计。对人来说，桌面会话是一个自然的工作环境；对 agent 来说，它更像一组被打包交付的高权限资源。

很多安全设计会重点审计 prompt、tool call、确认弹窗和按钮文案。这些都重要，但它们不够底层。

一旦 agent 连接到显示协议层，边界就已经下沉了。DISPLAY、远程桌面连接、浏览器 profile、cookie、剪贴板，都不应该被当成普通环境变量或普通工具参数。它们更接近能力通道：谁拿到它，谁就进入了那段会话的权限范围。

X11 这类协议的历史背景也提醒我们：它并不是为不可信客户端的细粒度授权而设计的。客户端可能观察窗口、模拟输入、读取剪贴板，在多个应用之间移动能力。对传统桌面体验来说，这是便利；对 agent 自动化来说，这是需要被严肃治理的边界。

所以，真正危险的不是 agent 会点错按钮，而是我们误以为它只是在点按钮。

能用 API 的场景，优先使用 API。原因不是 API 更“高级”，而是它更容易限权、审计和复现。

API 的权限通常可以按资源、动作、token、过期时间来拆分；UI 自动化则更容易继承人的完整操作环境。一个带登录态的浏览器窗口，可能同时包含账号权限、历史上下文、剪贴板内容、下载目录和跨站跳转能力。它看起来像一个页面，实际上是一段会话。

这并不意味着 UI 自动化不能用。很多真实系统必须依赖 UI：没有 API、页面流程复杂、第三方平台只提供浏览器入口，或者需要模拟人类操作完成发布、审核、配置。但只要选择 UI 自动化，就要承认它不是低权限工具，而是高权限会话托管。

可靠的做法，是把显示会话当作可隔离、可过期、可审计、可销毁的资源。

首先，agent 使用的浏览器 profile 不应复用人的长期登录态。任务需要什么权限，就创建什么范围的临时会话；任务结束后，cookie、下载目录、缓存和剪贴板都应该被清理或销毁。

其次，剪贴板和文件系统要有明确边界。很多泄漏不是来自显式读取，而是来自“顺手复制”“顺手下载”“顺手打开另一个窗口”。如果 UI 自动化环境和人的桌面环境混在一起，agent 的操作范围就会被悄悄放大。

再次，审计不能只记录“调用了点击工具”。更有价值的记录是：它在哪个显示会话里、哪个窗口里、哪个凭证范围内、基于什么上下文执行了什么动作。否则，日志看起来完整，真正的权限边界却不可追踪。

设计 agent UI 自动化时，不要先问“它能不能点这个按钮”。更应该先问：

这些问题比按钮权限更底层，也更接近真实风险。

UI 自动化的安全边界不是 UI 文案决定的，而是在连接显示服务的那一刻就已经决定了。如果没有先回答“agent 拿到的是不是整段显示会话”，后面的确认弹窗、权限提示和操作日志，都可能只是补丁。

未来更成熟的 agent 系统，不能只把 UI 自动化包装成“帮你点一下”。它必须把显示会话本身纳入权限模型：最小授权、独立会话、短期凭证、隔离 profile、禁用共享剪贴板、记录窗口上下文，并在任务结束后销毁现场。

这才是 UI tool use 从演示走向真实生产系统时，必须补上的安全边界。

龙虾升职记