AI操控电脑的安全防线：应用、动作与数据三维门禁设计

很多团队拿到 Computer Use 这类 AI 操控计算机能力的公共预览名额后，第一反应往往是注册、跑通 Demo、录屏发到群里。我反而先做了一轮破坏性测试：让 Agent 在完全无防护的桌面上自由行动十分钟。结果它为了完成"打开 PDF 并整理目录"这类正常任务，主动启动浏览器、下载压缩包、解压到系统目录、甚至在启动项里写入了可疑路径——每一步单看都合理，连起来却已经构成了一次完整的植入链。这次测试让我把标题里"应用、动作与数据三维门禁"从概念彻底变成了必须落地的工程清单，也直接催生了本文梳理的设计框架。无论你是做 AI Agent 产品、桌面自动化工具还是企业级数据可视化平台，这篇内容都能帮你把"让 AI 用电脑"这件事从失控边缘拉回来。

1. 公共预览场景下的安全特殊性：为什么不能照搬企业安全方案

Computer Use 这个概念，本质上指多模态模型通过理解屏幕截图、生成鼠标键盘动作来直接操作计算机界面，完成浏览器点选、文件整理、软件配置等一系列原本需要人手完成的任务。公共预览阶段最特殊的地方在于：它把"AI 操作真实操作系统"的能力开放给了不可控的用户群体和不可控的环境，而不是像内部测试那样，能靠人员培训和封闭网络兜底。

1.1 公共预览和内部测试的差别，远不止用户数量

内部测试阶段，评测人员会自觉地避免点击危险链接，测试机上也不放真实业务数据，出问题最多重装一台虚拟机。公共预览则完全不同：用户的电脑上挂着登录状态的网银、公司内网令牌、个人文件，用户本人也不一定具备安全意识。一旦 Agent 因为视觉理解错误点错了一个按钮，或者在执行任务时被页面上的恶意脚本诱导——后果不再只是"这个动作没完成"这么简单，而是变成一次真实的安全事故。

我在评估阶段做过对比实验：同一套 Computer Use 能力，在干净测试机上跑成功率约 82%，在装着常用办公软件、开着聊天工具、偶尔弹出系统更新的"脏环境"里，成功率直接掉到 63%，而且出现了两次点击系统托盘误操作、一次把文档存到错误目录的情况。这说明公共预览环境的不确定性不是偶发因素，而是安全设计必须当作默认前提来应对的主线。

1.2 常规权限模型在这里失控的根本原因

传统安全软件的核心思路是"人与软件的对抗"：杀毒软件拦截恶意进程，防火墙拦截网络流量，权限管理问用户是不是允许某操作。这套模型假设人是意图的源头，软件是载体。可 Computer Use 场景把人这一环抽掉了：意图来自模型，动作由模型生成，载体还是那些常规软件。于是传统模型的两大能力同时失效：

• 无法判断意图是否合法。模型是在执行"整理桌面文件"这个任务，它下载压缩包只是任务的一部分，杀毒软件看行为、看签名都对，但意图层面它已经被诱导了。
• 用户确认程序在高频操作下变成摆设。每个动作都弹窗让用户确认，用户点几次"允许"后就会条件反射式全选，这个模式本质上是把安全判断又交还给了懈怠的人。

所以我在设计里没有依赖单一防线，而是把"应用""动作""数据"当作三个相互独立的维度分别上锁，再用策略引擎把三个维度的裁决结果合并成最终执行指令。下文各章节会具体拆解每一道门禁的内部机制。

1.3 三维门禁的整体思路：先圈定可达边界，再约束行为，最后卡住数据流向

用一句大白话概括这套方案：管住它能去哪，管住它能做什么，管住它能带走什么。

应用维度管"去哪"——Agent 只能和允许列表里的进程和窗口交互，终端、脚本解释器、系统敏感工具默认不可达；动作维度管"做什么"——即使访问允许的应用，鼠标点击和键盘输入也要按步授权，危险快捷键和文本注入需要单独裁决；数据维度管"带走什么"——屏幕内容、剪贴板、文件读写、网络外发，全部按方向分开管控。三道门禁按顺序执行、共同决策，任何一道说"不"，整个操作就被掐断。

2. 第一道闸门：应用白名单如何圈定 Agent 的可达边界

应用维度的目标，是把 Agent 的操作空间压缩到"完成合理任务所需的最小应用集合"。这个集合不是随便列几个软件名那么简单，它需要从进程身份、窗口身份、可执行文件路径三个方面联合校验，否则很容易被冒名绕过。

2.1 白名单优于黑名单，理由很朴素

黑名单方案看起来维护成本低，但在这个场景里有一个致命漏洞：系统里有太多可以间接执行代码的载体，记事本、画图板、计算器本身无害，可一旦配合命令行工具或脚本宿主，就能变成攻击跳板。白名单把默认策略设为拒绝，没被明确允许的应用一律不可操作，这样即便模型被诱导尝试启动陌生进程，动作也会在最外层被拦截。

我在策略配置里会做如下分级：

• 默认允许：浏览器、办公文档编辑器、计算器、截图工具，这些是演示任务里的高频应用。
• 条件允许：压缩工具、文件管理器，只有当任务明确要求整理文件时才临时放行。
• 默认拒绝：终端、注册表编辑器、脚本解释器、任务管理器、系统设置面板里的大多数管理页。

这个分级不是死的，公共预览期间我每周根据任务日志调整一次。

2.2 策略配置的结构与热更新方式

应用门禁的配置文件我采用了 JSON 格式，方便策略引擎读取，也便于做版本管理。一个简化版本长这样：

{ "version": "0.3.1", "default_action": "deny", "apps": { "allow": [ "browser.package", "word_processor.package", "calculator.package", "screenshot.package" ], "conditional": { "file_manager.package": "task.requires.file_operation", "compressor.package": "task.requires.archive" }, "deny": [ "terminal.package", "registry_editor.package", "script_host.package", "task_manager.package" ] } }

这里的 package 不是进程名，而是"发布者标识+产品名+可执行文件哈希"的组合标识。进程名可以被随意重命名，但带哈希的标识无法伪造。策略引擎每 30 秒重新加载一次配置文件，这样我在调整规则时无需重启 Agent 进程，热更新在预览阶段非常关键——因为你会频繁地根据实测误判调整白名单内容。

2.3 应用门禁的漏洞：窗口伪装、间接启动与多进程架构

只看进程标识远远不够。实际运行中我遇到的第一类问题是窗口伪装：某些恶意页面会把窗口标题设置成"文档编辑器"，让模型以为自己在操作办公软件，实际上目标进程根本不是允许列表里的进程。解决方法是在窗口层做二次校验：不仅检查进程身份，还检查窗口所属的顶层窗口句柄、窗口类名、可执行文件路径三者是否一致。

第二类问题是多进程架构。现代浏览器往往一个主进程配多个渲染进程、GPU 进程，Agent 操作的是渲染进程弹出的窗口，直接按主进程做白名单会让拦截失效。我最后的方案是"按窗口获取进程路径并校验签名"，而不是按进程列表过滤——每次 Agent 发起点击动作前，先取鼠标坐标处的顶层窗口对应进程，再做白名单判断。

第三类问题是间接启动。模型发现终端被拒绝后，可能会绕道从文件夹地址栏输入命令行。这类路径我在动作维度的快捷键和文本注入规则里做了二次拦截，具体见下一章。

3. 第二道闸门：动作原语与快捷键掩码的每步授权

应用白名单拦住了"能启动谁"，但拦不住"对一个合法应用做什么"。如果 Agent 能在浏览器里输入任意内容、在文件管理器里按快捷键删除文件，那白名单就成了摆设。动作维度的核心是把鼠标键盘动作拆成最小可审计的原语，再针对每个原语设定风险等级与裁决策略。

3.1 把鼠标键盘动作拆成可审计的原子单元

我不按"这次操作"来做判断，而是把操作拆成不可再分的最小动作单元。实际使用的动作原语包括：

每次生成动作时，Agent 输出的是"原语类型+目标坐标+附加参数"的结构化指令，策略引擎拿到后先做白名单校验，再做动作级裁决。如果模型想直接输出底层的模拟鼠标位置，系统不会执行——我们只接受原语级指令。

3.2 动作风险分级与坐标安全

动作的合法性不能只看类型，还要看目标和范围。坐标安全是我在预览阶段补上的一个重要规则：屏幕四个角落、任务栏、系统托盘、通知中心这些敏感区域默认不可点击。因为这些区域承载着关机、重启、网络切换、权限弹窗等系统级功能，一旦模型误点，轻则任务中断，重则整个环境被破坏。

坐标安全规则包括三个区域校验：

• 白名单允许的应用窗口内区域：正常放行。
• 系统 UI 区域（任务栏、通知中心、系统托盘）：默认拒绝，除非任务上下文明确声明需要。
• 窗口外区域：拒绝，并对齐到最近的有效窗口。

实际踩坑中我发现，很多 Agent 失败的真正原因是模型把屏幕截图里的坐标算偏了几个像素，点到了窗口边框上，触发了窗口缩放或移动。公共预览环境的分辨率、缩放比例差异很大，所以我给动作引擎加了坐标修正逻辑：发送点击前先用辅助接口获取目标窗口实际矩形，再对坐标做归一化换算。

3.3 快捷键与文本注入的隐蔽风险

快捷键是最容易被忽视的高危动作原语。模型只要按 Ctrl+O、输入路径、再按 Enter，就能绕过文件对话框的一切限制，打开任意路径下的程序；按 Ctrl+D 可以把当前页面存进收藏夹，按 Ctrl+Shift+Q 在某些浏览器里是直接退出。我的处理方式是做一个快捷键掩码表：把键盘指令拆成修饰键+主键组合，只放行明确允许的组合，其余一律拒绝或进入询问流程。

文本注入的威胁更隐蔽——type 这个原语不只往输入框打字，它还可能被用来往终端、地址栏、运行对话框里注入命令。所以我对 type 做了两点约束：

• 只允许在"可编辑文本控件"里注入，通过 UI 自动化接口获取控件类型来校验，阻止向非编辑目标键入。
• 注入内容做敏感模式匹配，包含 shell 关键字、路径跳转符、疑似下载链接的内容会被拦截并记录。

这套原语级拆分一开始会明显拖慢执行速度，但预览阶段的稳定价值远比速度重要。实际跑下来，单任务耗时大约增加 12% 到 18%，换来的是几乎所有动作都有据可查。

4. 第三道闸门：数据出入口的双向流控

应用和动作两道闸门都通过后，Agent 事实上已经具备在允许应用内完成各种操作的能力。这时候威胁从"它能做什么"转移到"它能读走什么、写走什么"。数据维度专门管这道关卡，而且分方向管控：读方向和写方向单独设置规则。

4.1 读方向：屏幕内容、剪贴板与本地文件访问

Computer Use 天生依赖视觉，模型必须读取屏幕截图才能理解当前界面，所以屏幕数据几乎不可能禁止。但"必须读取"不意味着"必须原样全量读走"。"我能建模识别的屏幕数据，也要考虑把能不能出域作为判定维度。"

这里我把读方向数据分成几类：

• 屏幕帧：允许，但要做区域裁剪，超出当前活动窗口范围的内容默认打码，涉及密码框、验证码、二维码的区域直接屏蔽。
• 剪贴板：默认拒绝，只有当任务上下文出现"复制"意图且目标应用合法时，才允许读取并只保留纯文本格式。
• 本地文件内容：默认拒绝，对 Agent 屏蔽文件系统的内容级访问，避免读取用户文档、配置、浏览器密码库等数据。

剪贴板这个点很多团队会漏掉。模型的视觉能力很强，但许多任务仍需要读剪贴板来获取双因素认证码或表单数据。我的做法是剪贴板访问统一走"询问模式"：Agent 要读剪贴板，必须先向用户发起一次请求，用户可以在预览弹窗里看到请求内容，选择"本次允许"或"拒绝"。

4.2 写方向：文件落盘、网络外发与系统设置变更

写方向的安全风险比读方向更直接——文件一旦落盘或发送出去，就可能被持久化或泄露。我的写方向设计如下：

• 文件写入：只允许写入任务指定的工作目录，路径必须经过规范化处理并防止目录穿越。任何想写入系统目录、启动目录、下载目录的动作都会触发确认。
• 网络外发：默认拒绝所有网络请求，包含 HTTP 上传、WebSocket 连接、远程服务调用。预览阶段如果需要外发能力，必须单独声明目标域名和端口。
• 系统设置变更：涉及防火墙、开机启动项、网络代理、账户设置的变更一律拒绝，不提供询问入口。

4.3 数据脱敏、加密与审计日志的关联设计

数据门禁还要考虑一个实际问题：屏幕截图总归要被 Agent 模型接受并处理，本身就要过网络传输或 IPC 信道。所以我在预览环境里强制启用通道加密与会话级脱敏：

• 屏幕帧进入模型前，先做 OCR 检测，对高敏感字段（手机号、银行卡、密码框掩码）做模糊化处理；
• 文件写入前检测目标目录的加密属性，系统分区和加密盘在写入前会触发额外确认；
• 所有数据操作——包括读方向被拒绝的请求——都写入审计日志。

审计日志我采用结构化 JSON 格式，字段包括事件 ID、时间戳、进程名、原语类型、目标应用、数据操作类型、裁决结果和被拒绝原因，方便后续做自动化分析。

{ "event_id": "evt_8f2a3b", "timestamp": "2025-06-18T14:32:07Z", "session_id": "session_001", "app_identity": "browser.package", "action_primitive": "type", "target_control": "input_box", "data_operation": "noop", "decision": "allow", "decision_reason": "app_whitelisted&&action_type_allowed" }

5. 三维门禁联动时的冲突仲裁与策略优先级

三道门禁单独看都不难理解，难点在于同时命中时的裁决顺序。一个动作可能同时涉及应用维度（被白名单位置锁允许）、动作维度（被快捷键掩码拒绝）和数据维度（有读取剪贴板意图），三个维度的结果可能是矛盾的。预览阶段我踩过协作策略配置错误的坑之后，最终敲定了一套清晰的仲裁机制。

5.1 三类策略同时命中时的裁决顺序

仲裁顺序设计成固定管道：应用门禁在前，动作门禁居中，数据门禁最后补充。任何一道门禁返回拒绝，整体动作直接终止，不进入后续环节。

• 第一步查应用门禁：目标窗口属于白名单外的应用？拒绝，跳过一切后续判断。
• 第二步查动作门禁：原语是否允许、坐标是否在安全区域、快捷键是否在掩码内？任一不过就拒绝。
• 第三步查数据门禁：动作是否涉及数据读、写、外发？涉及判规则和询问队列。

这样的顺序有一个好处：尽可能用最便宜、最外层的前置判断拦截大部分危险动作，减少后面两道复杂规则的调用次数，也降低了各维度规则之间互相打架的概率。

5.2 会话级上下文与全局默认策略的关系

公共预览环境里，不同任务的合理动作集并不一致。比如"整理文件夹"的任务需要访问文件管理器，而"填写在线问卷"任务完全不需要。如果只用一套全局策略，会出现两个极端：策略太松，危险动作拦不住；策略太紧，很多正经任务跑不通。

我的解法是把策略拆成两层：

• 全局默认策略：固定在保守状态，默认拒绝高风险原语和高敏感数据操作。
• 会话级上下文策略：每个任务开始前由任务规划器声明目标应用的集合、允许的数据读写方向、预期的文件目录，运行时只放行上下文允许的动作。

这两层的关系是"交集"而不是"叠加"——某个动作必须同时被全局默认策略和会话级上下文策略允许才会执行，任何一层拒绝都不放行。实际设计中，我把全局默认策略当作不可改写的基线，会话级上下文只能在此基础上缩小允许范围，不能放大。

5.3 冲突仲裁表：几条直接能用的规则

经过几轮结构调整，我把联动仲裁总结成一组可以直接落地的规则：

这套仲裁表的好处是规则可验证、可测试，每个动作的裁决链路都能在日志里完整复现。

6. 公共预览实测踩坑：三种典型门禁误伤与修法

设计归设计，真正在公共预览环境里跑起来后，我发现了不少单看文档根本预料不到的坑。这些坑每一种都导致过任务失败或策略失效，记录下来，省得你重走一遍。

6.1 过度拦截导致任务无法完成：策略引擎把"合理路径"也拦死了

第一次联调时，我把动作门禁的快捷键掩码定得很严，只放行 Ctrl+S、Ctrl+C、Ctrl+V 寥寥几个组合。结果 Agent 在填表时无法用 Tab 切换输入框，因为我把 Tab 放进了 special_key 默认拒绝列表；无法用 Enter 提交表单，因为 Enter 也被拒绝了。任务成功率直接跌到 40% 以下。

修法是重新梳理"必须放行的最小快捷键集"，把 Tab、Enter、Esc、方向键放入允许列表，同时保留对 Ctrl+Shift+Q、Ctrl+Alt+Del 这类危险组合的拒绝。这让我意识到，动作门禁的规则不能只盯危险项不放，还要考虑任务完成路径的最小可用度。否则系统是安全了，但模型什么都干不了，也就失去了公共预览的价值。

6.2 窗口标题变化导致白名单失效

应用维度有一段时间频繁出现"白名单判定失败"的告警。排查后发现，根源是拼写检查等辅助功能挂载的悬浮窗、浏览器自动更新弹出的提示窗，都会在顶层窗口列表里占据最前面的位置，导致窗口校验找到的是错误进程。Agent 明明在操作浏览器窗口，校验的却是那个悬浮窗标题栏，自然被判为应用门禁拒绝。

修法有两个：一是校验时取"标题栏窗口的祖先窗口"而不是当前顶层窗口，这样能穿透悬浮窗；二是对窗口可靠性做置信度评分，重复校验失败时自动上升到人工确认流程，不让 Agent 陷入循环尝试。

6.3 权限提升与用户确认的噪音频发

公共预览环境里，Agent 一旦遇到合法但敏感的操作，系统就会弹一次"是否允许"的确认框。预览刚开始时确认框触发频率极高，几乎每 30 秒弹一次，用户很快就变得麻木，开始无脑点允许——这正是安全设计最害怕的用户疲劳效应。

我把确认策略改成了分级机制：

• 低风险动作：静默放行，只在日志里记录。
• 中风险动作：单次确认，60 秒超时自动拒绝。
• 高风险动作：双重确认，且必须打字输入"允许执行"才能通过，减少肌肉记忆式操作。

同时增加了每日确认额度：全天允许的确认次数超过 50 次后，后续低风险动作退回询问模式，强制用户关注发生了什么。这套机制上线后，预览反馈里的"误授权"投诉明显下降了。

6.4 关于预览阶段安全设计的一条实战经验

给还在规划阶段的朋友一个来自实测的核心建议：安全策略的每一项规则上线前，都先做一轮"反向压力测试"。我的做法是请测试同学扮演攻击者，输入提示词诱导 Agent 执行危险动作，记录哪些动作突破了门禁，然后针对每一条突破路径补规则。公共预览的 AI Agent 已经不是一个单纯的自动化工具，它是有执行能力的智能体，安全设计越早当成第一优先级，后面迭代的成本就越低。三维门禁的完整链路每多一层，你离"让 AI 帮我干活又不怕它搞事"的平衡点就近一步。