1. 项目全貌与安全设计的破题思路
1.1 什么是Computer Use，它在解决什么问题
先说清楚这个项目的背景，不然底下聊安全设计容易悬空。Computer Use是Anthropic Claude家族推出的一项Agent能力，它在2024年底进入公共预览阶段，核心功能是让大模型直接操纵计算机界面——像人一样看屏幕截图、移动光标、点击按钮、输入文字、滚动页面，完成端到端的操作任务。
用大白话讲，以前的大模型是"你说一句、它回一段"，顶多帮你生成代码、写段文案，然后把结果交给你，至于怎么用，那是你自己的事。Computer Use不一样，它直接把"手"伸到了你的桌面上：你说"帮我把这周的报表整理成PPT，发给经理"，它会自己打开Excel、整理数据、切到PowerPoint、排版、调格式、打开邮件客户端、写好正文、点发送。整个过程里，它不依赖任何API接口，不看任何文档，纯粹靠"看屏幕+操作鼠标键盘"来完成。这就是它恐怖的地方，也是它引发安全担忧的根源。
我在这个方向跟进了很长一段时间，也做过不少本地复现实验。说实话，第一次看到模型自己移动光标去点击某个按钮时，那种感觉既兴奋又后背发凉：它真的能操作我的电脑了。兴奋的是，这可能是通往通用数字助理的一条现实路径；后背发凉的是，如果这个"数字员工"理解错了意图、点错了按钮、读了不该读的文件，谁来负责？所以Computer Use公共预览版发布时，安全设计不是附加功能，而是核心功能。
公共预览这个定位也很关键，它意味着产品还在收集反馈、打磨边界的阶段，安全机制既要覆盖得住已知风险，又要留出足够的弹性去应对未知场景。这个前提下，安全设计不能只靠某一道防线，必须立体化、分层化。官方给出的思路是三维门禁：应用、动作、数据。这篇文章就围绕这三个维度，逐层拆解它的设计逻辑、实现细节和我在实际操作中踩过的坑。
1.2 三维门禁的整体框架：为什么不是"一道锁"而是"三道门"
你可以把Computer Use的安全体系想象成一栋办公楼的门禁系统。传统的安全设计可能只在大门口设一道保安，查证件、登记、放行，进楼之后你就自由活动了。但Computer Use面对的威胁模型完全不同：模型不是来开会的访客，而是来替你办事的临时员工。它既要能碰到你的文件、你的邮件、你的浏览器，又不能在过程中越界。只设一道门，要么放行太松出事，要么管得太死没用。
所以设计者把安全拆成了三道独立的门：应用维度的"这栋楼里哪些房间你能进"、动作维度的"进了房间之后你能碰哪些东西"、数据维度的"你带走的信息怎么受控"。三道门各管一段，任何一道拦住，操作就被阻断。这个和电气安全回路设计里的"多重保护"思路很像，发生过载、漏电、短路时，不是靠单一断路器兜底，而是热继电器、漏电保护器、熔断器各司其职，一层切掉一层。单一保护装置失效还有下一道兜底，这是工业安全设计沉淀下来的方法论，Computer Use的三维门禁本质上是同一套逻辑在AI Agent领域的迁移。
从实际效果看，这种设计还有一个隐蔽的好处：它让安全决策从"全有或全无"变成了"分阶段授权"。模型刚进入环境时，系统不知道它要干什么，所有权限默认关闭；随着任务推进，系统基于用户预设的策略逐步放行具体能力。这个动态过程的每一步都可审计、可回滚，比一把大锁灵活得多，也更符合真实操作场景。
2. 应用维度门禁：划定Agent的"活动地图"
2.1 应用预授权清单是怎么运作的
应用维度是整个门禁体系的第一道门，解决的第一个问题是：Agent能看到哪些应用程序、能启动哪些应用程序。设计上采用的是"显式清单"模式，有点像手机App的权限管理：默认不给任何权限，用户必须在配置中心里明确勾选允许调用的应用。没有被列入清单的应用程序，Agent不仅不能操作，连在屏幕截图里"看到"都会被遮蔽处理。
具体落地时，这个清单不是简单列个应用名就完了。以Claude Computer Use的实际实现来看，清单条目包含应用的可执行文件路径、窗口标题匹配规则、允许的操作级别（只读、常规操作、完全控制），以及有效期。举个例子，你可以配置允许Agent使用/Applications/Google Chrome.app做网页操作，但限定它只能用浏览器的常规功能，不能进入开发者工具模式；可以允许它打开Terminal执行命令行，但要求在每次执行高危命令前征得确认。
这种设计的出发点是对"最小权限原则"的严谨执行。Agent操作电脑和人类操作电脑有一个本质区别：人类有自己的判断力、经验和风险意识，看到某个对话框弹出来能本能地犹豫一下；Agent是逐帧看截图的，它对"这个弹窗会不会有问题"没有直觉，只会按照"完成任务"的目标行动。因此，应用清单就是在替Agent补上这个"犹豫一下"的环节——不在清单里的应用，连犹豫的机会都不需要。
实操层面我有个体会：清单初期宁可严格，也不要松。很多人配置的时候觉得"这几个办公软件都是常用的，全勾上算了"，结果Agent在"整理文档"的任务里自己打开了浏览器去搜索资料，虽然没出事，但行为边界已经超出预期了。正确的做法是先只勾选任务绝对必要的最小集合，跑通之后再逐步增加，每加一个都想想"万一它拿这个应用做了我没预期的事，能不能接受"。
2.2 权限边界：窗口焦点控制的细节艺术
应用清单管住了"能启动什么"，但电脑上还有一个窗口焦点问题：用户自己也在用电脑，Agent操作的窗口和用户正在使用的窗口冲突了怎么办？这里的安全设计和交互设计是重叠的，处理不好会出乱子。
Computer Use在公共预览阶段采用的是"会话隔离+窗口接管"模式：Agent在一个独立的运行环境里操作，这个环境在云端或本地虚拟化沙箱中，Agent看到的屏幕不是用户真实的物理屏幕，而是虚拟显示器上的画面。这样一来，Agent的窗口焦点和用户的窗口焦点天然分离，两边互不干扰。用户可以在自己电脑上正常浏览网页、写文档，同时看到Agent在虚拟环境里独自忙活。
这种设计在安全上有个很关键的收益：隔离了"观察面"。Agent只能看到虚拟环境内的画面，无法通过截屏等手段观察到用户主屏幕上的敏感信息。你想一下，如果Agent运行在真实桌面上，用户恰好打开了网银页面，Agent的截屏就会把银行卡号、余额、转账记录全部带进上下文——这画面想想都头皮发麻。虚拟环境隔离从物理层面切断了这条泄露路径，属于非常聪明的设计。
不过要注意，这种强隔离也带来了体验上的限制：Agent操作的是虚拟环境，和你本地的真实文件系统、浏览器登录态是脱钩的。要让它处理真实数据，还是得通过受控的接口把文件映射进沙箱。做本地复现实验时，这个映射关系一定要设置成"只读"或"单向传输"，我在第三节会详细说数据映射的配置方法。
3. 动作维度门禁：把"能做什么"拆到原子级别
3.1 动作指令集的设计与分类
完成了应用维度的"进楼许可"，接下来是动作维度的"房间内行为规范"，这也是三维门禁里技术含量最高、细节最多的一层。思路是：不把"操作电脑"当成一个整体能力授权给Agent，而是把操作拆成一个个原子动作，逐个控制。
Computer Use定义的动作类型大致包括屏幕坐标点击、键盘输入、组合键操作、滚轮滚动、拖拽、菜单选择、文本输入、等待/观察等。每个动作都有自己的参数和权限配置。之所以要拆这么细，是因为不同动作的风险等级完全不在一档：滚动页面看看内容，和输入一段文字，和按下Cmd+W关闭窗口，背后对应的破坏力差距巨大。
我做了一个动作风险分级表，可以比较直观地看这个设计思路：
| 动作类型 | 风险等级 | 典型场景 | 默认策略 |
|---|---|---|---|
| 观察/截屏/获取光标位置 | 低 | 读取页面内容、判断按钮位置 | 允许 |
| 鼠标移动/单击/双击 | 中低 | 点击链接、选中文件、打开菜单 | 允许/记录 |
| 滚轮滚动/页面浏览 | 低 | 翻阅长文档、查看列表 | 允许 |
| 键盘输入（常规字符） | 中 | 填写表单、搜索关键词 | 允许/敏感场景拦截 |
| 键盘输入（控制键/组合键） | 高 | Cmd+N、Alt+F4、Ctrl+W等 | 默认拦截/需授权 |
| 拖拽操作 | 中 | 移动文件、调整窗口位置 | 按目标对象策略 |
| 剪贴板写入 | 高危 | 复制/粘贴内容 | 强管控+内容审计 |
| 文件删除/覆盖/移动 | 高危 | 整理文件、清理缓存 | 默认拦截/二次确认 |
| 执行命令行 | 高危 | 安装依赖、运行脚本 | 默认拦截/白名单命令放开 |
这里有个关键设计细节：低风险动作默认放行，但必须记录日志；高风险动作默认拦截，除非用户在策略中心显式授权。这跟电气安全里"常闭触点优先"的思路异曲同工——安全回路的默认状态是断开，而不是闭合。动作门禁的默认状态也应该是"拦"，而不是"放"。人做决定时容易有"应该没问题吧"的侥幸心理，系统设计必须把这种心理的发挥空间压缩到零。
3.2 屏幕坐标点击的信任边界问题
动作维度里最容易被忽略、但实际事故率最高的，是屏幕坐标点击。很多人以为动作权限都控制了，点击应该没什么风险，但仔细想想：Agent通过截图感知页面，通过坐标定位元素，它的"感知-决策-执行"链条里，任何一个环节错位都可能酿成意外。
举个例子。页面上有两个按钮，"删除整个数据库"和"导出备份数据"，它们在截图里可能只差50像素。模型视觉理解错位、页面延迟渲染导致坐标偏移、或者按钮位置在动态页面中发生了移动，Agent就可能带着"导出备份"的意图点到了"删除数据库"上。这不是危言耸听，我在本地测试中就遇到过类似情况——模型本想点击Chrome地址栏，结果点到旁边的书签文件夹上，直接打开了一堆标签页。虽然没出大事，但足以说明问题。
针对这个问题，设计上要做双重校验。第一重是坐标校验：点击动作发出前，系统会检查目标坐标附近是否有可交互元素，如果落在空白区域或元素边界外，会触发重试或报错。第二重是结果校验：点击之后，系统会对比点击前后的截图差异，判断是否产生了预期中的界面变化。如果点击后没有任何变化，或者出现了预期外的弹窗，系统会暂停动作链，等待人工介入。这两个校验在实现上都不复杂，但效果显著，能把坐标误点的命中率大幅压低。
还有个容易被忽视的细节是键盘输入法的干扰。Agent在虚拟环境里输入文本时，如果系统输入法恰好处于中文模式，模型想打"hello"会变成"哈楼"，想打文件名"report"会变成"如破特"，轻则任务失败，重则生成错误的文件路径。建议在配置虚拟环境时把输入法强制锁定为英文模式，并关闭所有快捷键切换输入法的通道，这个坑我踩过一次之后永久写进了检查清单。
3.3 操作频率与并发控制：防止"手速失控"
人类操作电脑时，手速再快也有物理上限，每秒三五次点击已经是极限了。但Agent操作电脑是靠程序发指令的，没有任何物理限制。如果Agent陷入某种循环——比如页面加载失败后反复重试点击同一个按钮——它的操作频率可以轻松达到每秒钟几十次，眨眼间就能把系统搞崩溃或触发大量错误操作。这就要靠速率限制器和循环检测器来兜底。
速率限制的逻辑比较简单：对单位时间内的动作数量设阈值，比如"每10秒最多20个动作"，超了就直接熔断——暂停Agent，保存当前状态，请求人工介入。这个阈值不是拍脑袋定的，我是通过实际跑任务统计出来的：常规的网页操作任务，平均每秒动作数在1~3之间；密集型任务如填表、整理文件，峰值也就每秒5个左右。设置每秒10个作为上限，既能覆盖正常场景，又能高效拦截异常循环。
循环检测器稍微复杂一点，它监测的是动作序列模式：如果系统连续检测到重复的"点击同一个位置→无变化→再次点击同一个位置"超过5次，就会判定为死循环，强制中断。这个机制在浏览器自动化测试领域已经很成熟了，但Computer Use场景还是有一点特殊性：模型的决策有随机性，偶尔重复一两次是正常的，不能误伤，所以阈值需要设置得比传统自动化测试更宽松，同时要区分"重复点击但页面有变化"（正常）和"重复点击但页面无变化"（死循环）。
我在实际测试中还发现一个有意思的问题：速率限制器和循环检测器的判定周期要尽可能短。有次我配置的速率限制窗口是60秒，结果Agent在15秒内连续执行了40次无意义的鼠标移动，虽然触发了速率熔断，但已经开始产生大量无意义的操作日志了。缩短判定窗口之后，这个时间差被大大压缩，系统的响应速度明显改善。
4. 数据维度门禁：信息流的"进出口管理"
4.1 读写权限隔离与文件映射机制
数据维度可能是三维里最容易被低估的一维，它的核心问题不是"Agent能不能操作文件"，而是"Agent能读取什么、能写入什么、能带走什么"。这三个问题对应的设计分别是：读取白名单、写入隔离区、传输审计通道。
读取白名单解决"Agent能看到哪些数据"的问题。在Computer Use的实现中，Agent运行在虚拟化沙箱环境里，它访问文件系统不是直接访问宿主机的磁盘，而是通过文件映射机制把宿主机指定目录挂载进沙箱。配置这个映射关系时，安全原则是：只挂载任务需要的最小目录集，其他一切不挂。举个例子，如果任务是"整理桌面上的图片"，那就只把~/Desktop挂载进去，~/Documents、~/Downloads、~/.ssh这些一概不挂。别怕麻烦，我在本地调试时图省事把整个home目录挂载进去过，结果模型在浏览文件时居然读到了~/.aws/credentials——虽然没造成实际泄露，但这一步把它和敏感凭据放在同一个上下文里本身就是风险，当场惊出一身冷汗。
写入隔离区解决"Agent写坏东西怎么办"的问题。隔离区本质上是一个独立的目录，Agent想要保存文件时，系统会把写入引向这个区域，而不是直接写入目标位置。等Agent完成任务后，系统生成一份文件清单，用户逐项审核通过后，才把文件"提交"到真实的目标目录。这好比快递驿站：快递员不能直接把包裹塞进你家里，只能放在驿站，你下班后自己取、自己拆、自己决定要不要留下。这个机制多花一点时间，但能把"Agent写入了错误文件"的破坏性从"覆盖原文件"降级为"多了一个待审核的新文件"。
传输审计通道解决"数据怎么流向外界"的问题。Agent的每个数据读取行为、每次网络请求、每个API调用，都要经过审计日志记录。并且审计日志本身要独立于Agent运行的环境存储，避免Agent为了掩盖操作而篡改日志。这个日志不只是事后追溯用的，它还是实时监控的基础：当检测到Agent访问了不在白名单内的文件或域名时，系统会直接在运行中阻断，而不是事后报告。
4.2 敏感信息识别与数据脱敏策略
除了文件级别的读写控制，数据维度还有一个更细粒度的问题：Agent在处理正常文件时，可能遇到文件内部包含的敏感信息片段。比如让Agent总结一份产品周报，周报里附带了几行客户端IP地址；让Agent整理一个联系人表格，里面有手机号码。这些内容虽然不涉及"越权读取"，但属于"不必要的隐私数据流入模型上下文"。
针对这个问题，数据维度门禁里设置了一层内容级过滤器。系统在Agent读取文件内容时，会先经过一个规则引擎，对文本内容进行模式匹配——手机号、身份证号、银行卡号、API密钥、私钥块、邮箱地址等敏感格式都可以被识别，然后执行脱敏替换。替换规则不是简单地打码成***，而是保留格式和语义的可读性，比如手机号138****5678，邮件a***@example.com，这样Agent仍然能理解内容的类型和结构，但拿不到完整明文。
有人可能会问：脱敏之后，Agent的任务还能正常执行吗？比如任务是"提取表格里所有人的手机号"，脱敏之后不就没法提取了吗？这个场景属于"任务本身需要敏感数据"，正确的做法不是绕过脱敏，而是触发权限升级流程：Agent在任务描述里显式声明需要完整手机号，系统向用户请求临时授权，用户可以选择只对本次任务、本次任务所在目录、或本会话内放开该字段的脱敏。给用户"按需松开"的能力，而不是让用户去应付频繁的拦截提示，这是内容过滤器设计里非常重要的一点。拦截如果过于频繁，用户会产生"狼来了"效应，最终变成看到警告就随手点通过，这个防线就废了。
内容过滤的实现上，我建议用两个规则源叠加：一组内置的基础正则规则（覆盖常见敏感格式），一组用户自定义的上下文规则（覆盖业务特有的敏感字段，比如项目代号、内部系统名称、特定的团队缩写）。基础规则保证通用安全底线，自定义规则才能让过滤器贴合实际业务场景。光靠内置规则，你会发现真正该拦的拦不住，不该拦的乱拦，实用性大打折扣。
4.3 操作留痕：审计日志与行为回放
数据维度门禁最后一块拼图是审计日志系统，它负责把Agent的所有关键行为记录下来，形成不可抵赖的操作证据链。日志记录的核心字段包括：时间戳、动作类型、目标坐标/元素描述、涉及的应用、文件路径、数据流向、决策依据摘要、中间截图哈希值。这里的"决策依据摘要"值得一提——它记录的是模型在采取某个操作时的简短推理说明，这让我们能在事后回放时理解"模型为什么要这么做"。
审计日志不是简单写进本地文件就完了，有几个设计细节要特别注意。首先是日志的完整性保护，采用哈希链的方式：每条新日志包含前一条日志的哈希值，任何一条被篡改，后续所有哈希都会校验失败。这样做成本很低，但防篡改能力很强。其次是日志的双副本存储——一份存在宿主机，一份实时传输到远程日志服务，防止Agent运行环境被搞崩后日志跟着丢失。最后是行为回放功能：把日志记录的操作序列和当时的截图快照组合起来，可以还原成一段类似录屏的可视化回放，用于事后审查。这在排查"Agent为什么执行了这个操作"时极其有用，比看干巴巴的文字日志直观得多。
我在一次真实的调试中体会过这个回放功能的价值。当时Agent在执行"整理下载文件夹"的任务时，突然把一个PDF文件移动到了另一个目录，行为路径完全偏离了任务目标。单看日志，我只能确定它"做了这件事"，却不知道它为什么这么做。回放录像显示，模型在扫描文件列表时，看到PDF文件名为"2024-Q4-Report-FINAL.pdf"，将其理解为了"已经处理完成的历史报表"，于是顺手归档了。虽然模型的推理逻辑有合理性，但行为确实越界了。有了这个案例，我在策略里增加了一条规则：所有文件移动操作，无论目标对象是什么，都必须先经过用户确认。
5. 调试与安全测试的实操指南
5.1 本地环境的搭建与演练方案
聊完了三维门禁的设计逻辑，下面这部分是纯实操向的，我把自己在本地环境复现这套安全机制的完整过程整理出来。实验环境建议用macOS或Linux，因为这两个系统的权限模型相对清晰，Windows的权限管理细节差异较大，后面踩的坑会不太一样。
第一步是准备隔离环境。我用的是Docker容器加虚拟显示器的组合方案：容器内跑一套轻量桌面环境（X11/Xvfb或者 Wayland），Computer Use API连接这个虚拟显示器，就像连接一台远程电脑一样。Docker的--read-only和--tmpfs参数非常有用，前者可以把宿主机文件系统设为只读挂载，后者把容器内临时目录放进内存，写操作重启即焚，杜绝持久化污染。命令大致长这样：
docker run -d \ --name computer-use-sandbox \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size=512m \ -v ~/sandbox-data:/workspace:rw \ -e DISPLAY=:99 \ -p 5900:5900 \ computer-use-base-image这里的关键是~/sandbox-data目录，它就是前面说的"写入隔离区"，会以可写方式挂载给Agent使用。宿主机上其他目录一概不挂。如果你确实需要让Agent访问某个真实目录里的文件，正确做法是先复制到这个沙盒数据目录，或者用只读方式挂载一个子目录，挂载粒度务必控制在文件级别或子目录级别。
第二步是配置策略中心。Claude的Computer Use公共预览阶段支持通过API参数传递权限配置，大致需要明确几类信息。应用白名单方面，按需列出允许的应用名称；动作策略方面，定义"低风险动作放行、中风险动作记录、高风险动作拦截"的分级；数据策略方面，指定可读目录、可写目录、敏感正则规则集和脱敏开关。配置完策略之后，我强烈建议先跑一遍官方提供的"最小权限验证用例"，用一组简单的任务验证基本流程通不通，不要一上来就跑复杂任务。
第三步是压力测试与对抗性测试。这一阶段的目标不是"验证功能正常"，而是"验证安全机制在异常情况下仍然有效"。可以故意设计一些场景去触发安全边界，比如给Agent一个模糊不清的目标让它自由发挥，或者在Agent运行途中手动修改它的工作目录文件。我跑了将近一周的这类测试，总结下来有价值的用例集中在三类：目标歧义测试、权限边界测试、异常恢复测试。目标歧义测试看的是当任务描述含糊时，模型会不会擅自扩大行动范围；权限边界测试直接给出"读取一个敏感文件"的指令，看拦截是否生效；异常恢复测试则是中断Agent的操作进程，重新唤醒后检查它是否具备恢复到安全状态的能力。
5.2 安全测试中的高频问题与排查速查表
在本地反复折腾这套机制的过程中，我积累了一些高频问题和对应的排查方法。这里整理成一个速查表，遇到问题可以对号入座。
| 现象 | 可能的根因 | 排查与解决 |
|---|---|---|
| Agent无法启动任何应用 | 应用白名单未配置或配置格式错误 | 检查策略中心的应用列表，确认应用名称和路径精确匹配，注意macOS应用名带.app后缀 |
| Agent频繁触发动作熔断 | 速率限制阈值配置过严 | 结合任务类型调整阈值，观察正常任务的动作频率基线，把阈值设为基线峰值的2~3倍 |
| 模型反复点击无变化区域 | 虚拟显示器分辨率或渲染问题 | 检查Xvfb分辨率设置，建议调整为1280x720以上；确认页面是否有延迟加载动画 |
| 文件写入不生效 | 写入隔离区路径映射错误 | 确认容器内/workspace路径与宿主机~/sandbox-data的绑定关系，检查挂载权限 |
| 敏感内容未被脱敏 | 自定义规则未加载 | 检查规则引擎日志，确认自定义规则文件的语法和编码格式，UTF-8 BOM会导致首条规则失效 |
| 审计日志出现间隙 | 网络传输日志通道不稳定 | 检查远程日志服务的网络连接，增加本地缓存重传机制，确保日志不丢不重 |
| 模型误触系统级快捷键 | 虚拟环境的窗口焦点管理不足 | 在虚拟桌面内禁用全局快捷键，或使用独立键盘映射方案，确保快捷键只在虚拟环境内生效 |
5.3 我自己踩过的几个坑，以及对应的安全补丁
最后分享几个我在实际测试中踩过、并且觉得其他开发者大概率也会踩到的坑。
第一个坑是"展示层安全"和"数据层安全"的混淆。一开始我以为把敏感文件放在宿主机、只把任务目录挂载进沙箱就万事大吉了，却忽略了Agent可通过截屏"看到"的内容范围。有一次Agent在操作浏览器时打开了文件上传对话框，对话框里默认显示的最近访问文件列表居然包含了我宿主机的目录结构。虽然不是直接读取文件内容，但这已经构成了信息泄露。这个问题的教训是：数据维度门禁不仅要管"它能读什么文件"，还要管"它能在界面上看到什么"。补丁方式很粗暴——在沙箱环境中把上传对话框的默认目录设为空目录，并禁用文件管理器里的"最近使用"列表。
第二个坑是"动作权限的上下文相关性"。早期配置中，我给键盘输入动作设置了比较宽松的权限，因为觉得输入字符本身没什么破坏力。结果在一次测试中，Agent在某个网页的输入框里自动填入了一段包含Shell命令的文本，虽然它本意是填写表单，但该网页恰好把输入内容当成了命令执行。这个场景虽然属于极端情况，但暴露了一个问题：动作权限脱离上下文判断就是空转。后续我在动作策略里增加了"输入内容匹配规则"——当AI生成的文本中包含命令关键字、路径分隔符、脚本语法特征时，自动升级为高危动作，要求人工确认。
第三个坑是"权限配置的单项覆盖"。规则引擎的匹配顺序是"先精确后模糊"，但早期配置时我没注意两个规则之间的优先级，某条模糊的"允许浏览器操作"规则覆盖了精确的"禁止访问特定域名"规则，导致后者的拦截效果失效。排查了很久才发现是规则顺序导致的逻辑短路。现在我的配置惯例是：所有禁止类规则统一排在允许类规则之前，并把每条规则的匹配条件写细，宁可多配几条精确规则，也不要依赖一条大而化之的通配规则。
第四个坑是配置项本身成了安全短板，尤其是API密钥和策略配置文件的管理。在我较早的实验中，为了调试方便，把API密钥直接写进了环境变量文件，结果在一次日志导出时，环境变量的内容被带进了审计日志的上下文。虽然只是测试环境，但也让我意识到：管理Agent的管理员自身的工作流也需要安全约束。现在的做法是把密钥放进独立的密钥管理服务，策略配置文件单独存放在加密目录，与沙箱环境严格隔离。
6. 一个具体的端到端实验：让Agent帮我整理会议纪要
为了把上面说的这些机制串起来，这里用一个我实际跑过的完整任务做一个端到端的演示。任务目标设定得很日常：让Agent读取指定的会议录音转写文本，提取行动项清单，生成一份带优先级的任务表格，保存为Markdown文件。这个任务跨度涉及文件读取、文本处理、数据提取、文件生成，算是能比较全面覆盖三维门禁各层机制的了。
任务开始前，我在策略中心做了如下配置。应用白名单方面，本轮任务只需要一个纯文本编辑器和文件管理器，浏览器、终端一律不放行。动作策略上，读取和滚动放行，键盘输入限流，文件写入必须进隔离区。数据策略上，可读目录只挂载转写文本所在目录，可写目录指向隔离区。任务运行中，我对每个环节做了观察，记录如下。
读取环节，Agent打开转写文本文件浏览内容时，文件读取日志正常记录，路径为/workspace/input/meeting_transcript.txt，与预先挂载目录一致，没有发现越权读取。处理环节，Agent在提取行动项时，有几次犹豫行为——它在浏览器搜索框附近移动了光标，但应用白名单拦截了浏览器启动，它很快放弃了该路径，回到文本处理逻辑上。这里有记录，是动作维度拦截的典型实战案例。生成环节，Agent将生成的Markdown文件写入隔离区~/sandbox-data/output/，没有直接写入真实目录，这验证了写入隔离区的可靠性。
整个过程跑完后，我审查了审计日志，重点是检查是否有意外动作、是否出现未预期的文件访问、是否在截图中暴露了不该看到的内容。这次任务中，三维门禁各司其职，没有触发任何高危拦截，整体体验算得上流畅。这个实验结果也验证了我一直以来的判断：安全机制设计得好不好，不看它拦住了多少操作，而看它在拦住操作的同时，是不是把对正常任务的干扰降到了最低。好的安防是"静默的，但关键时刻可靠"。
7. 关于安全边界的思考与后续扩展方向
Computer Use的安全设计是个典型的三位一体工程：应用维度管环境边界，解决"能去哪"；动作维度管行为边界，解决"能做什么"；数据维度管信息边界，解决"能碰什么、带走什么"。三维叠加，才构成了一个相对完整的信任边界。这套设计里值得所有做AI Agent、甚至做机器人流程自动化的团队借鉴的核心思想，就是"默认拒绝、分步授权、全程审计"这十二个字。
我把这套机制在本地跑了一个多月，最大的体会是：安全设计不能影响正常路径的使用体验，否则它一定会被使用者绕过。很多安全系统失败，不是因为攻击者攻破了它，而是因为正常用户嫌它烦，主动把它关掉了。Computer Use的三维门禁在这一点上做得还算克制——它把拦截动作尽量前置到策略配置阶段，运行中需要用户介入的场景被压缩到最小，这让系统"安全但不碍事"。
后续如果要把这套方案往更实用的方向推进，我觉得有几个值得探索的延伸点。一是基于异常的实时行为检测模型，目前的三维门禁主要是规则驱动，如果能结合机器学习模型对操作序列做异常评分，应该能覆盖更多规则写不出来的边缘场景。二是多Agent协作场景下的数据隔离，多个Agent共享环境时，如何防止Agent A通过文件系统把数据"递"给Agent B，这将是一个全新的信任边界问题。三是离线运行时的安全策略缓存与降级方案，如果Agent运行在无网络环境，审计日志的传输策略、策略更新的分发机制都需要重新设计。
这些方向目前没有一个已经有成熟答案，都在探索期。但这恰恰说明Computer Use这个方向还处于早期，大家站在差不多的起跑线上，谁的工程经验多、谁的安全细节打磨得扎实，谁就更容易在Agent落地应用这个赛道上站稳脚跟。对于正在考虑把Agent能力引入到自己业务里的团队，我的建议是：先在隔离环境里把三维门禁配起来，用真实的业务任务跑一段时间，让安全边界的问题暴露出来，再迭代策略——安全的打磨，从来都是跑出来的，不是想出来的。
