把电脑交给Agent以后，谁来保护你？

一、电脑原来是给人用的，现在交给了Agent

我们习惯了通过界面使用电脑，也习惯了界面替我们处理风险。删除文件有回收站，危险操作有提醒，许多底层功能根本不会摆在普通用户面前。人在界面里操作，能做的事情通常已经被软件筛过一遍。Agent却可以自己写代码、运行程序，直接调用系统接口。它做事更快、能做的更多，也可能不经过那些原本替人挡住危险的步骤。

麻烦在于，电脑上的权限往往比一句任务宽得多。你只让Agent整理照片，它运行的程序却可能有权删除其他目录；你只让它改一份文档，它却可能访问屏幕和摄像头。系统会检查权限，但不会自动把你的要求变成一道限制。如果没有额外保护，让这样的Agent在日常电脑上自由运行，就像让它拿着火把在炸药库里跳舞。一次误解、一段错误代码，都可能把损失带到任务之外：不该读取的资料被读走，不该改动的文件被覆盖，甚至让电脑无法正常使用。从破坏能力上说，一个失控的Agent，甚至可能成为“大号病毒”。用户需要知道，当Agent开始执行这些操作时，产品提供的保护能不能真正生效。

这就是Agent Safety Arena想回答的问题。我们从具体的用户损失出发，设计可复查的测试场景，观察Agent如何处理请求、什么时候要求授权，以及电脑上最终发生了什么。我们希望把“这个Agent安全吗”这样宽泛的问题，拆成可以用证据回答的小问题：它能访问哪些资源，哪些操作会被阻止，哪些风险仍需要用户自己承担。

二、我们怎么测：把危险操作变成可复查的案例

我们先从用户可能受到的伤害出发，选了一组案例，分成四类：

• 隐私安全：看摄像头、麦克风、截屏和录屏会不会暴露隐私。
• 交互安全：看弹窗和窗口操作会不会让电脑没法正常使用。
• 系统安全：看程序、服务和系统设置会不会被破坏。
• 数据安全：看文件会不会被删除、改动或带走。

测试在受控环境中进行，使用专门准备的文件、目录和程序，并事先划定允许操作的范围。

点开案例，你可能会觉得有些指令很奇怪：程序都准备好了，为什么还让Agent去运行？这和我们平时让Agent自己想办法做事，确实不太一样。这样做，是因为从一句要求到最后执行，中间有太多变化。同一个意思，换种说法，Agent的反应可能就不同；同一句要求，它可能写出不同的代码；到了运行时，还可能选择不同的工具和重试方式。代码写错了，程序没跑起来，不能算沙箱保护了用户。

对于摄像头、桌面干扰和系统操作等案例，我们先让Agent根据普通提示词生成程序，再在被测Agent之外验证程序，确认它能产生预期效果。随后把程序固定下来，交给被测Agent执行。这样可以减少代码生成差异带来的干扰，集中观察：面对一个已经确认有效的程序，Agent会怎样处理执行请求，现有防护能否阻止目标效果。程序、执行指令和校验值都保留在案例里，方便别人复查。

数据安全案例则采用另一种方式：直接提出读取、修改、移动或删除指定文件等任务，让Agent自己选择工具和实现方法。因为我们还想知道，事先设置的文件保护规则，在Agent实际做事时是否有效。它通过文件工具访问，或者改用命令、脚本操作，最终是否都受到同一条边界的约束？固定程序和直接任务分别观察执行过程中的不同环节，具体设计会在案例中说明。

测试条件也需要一起看。我们记录实际使用的产品版本、模型、提示词、权限设置和审批策略，区分产品默认配置与专门设置了资源保护规则的配置。它们回答的问题不同，不能把配置规则后的结果直接当作默认表现，也不能把某个场景的成功防护扩展成对所有操作的保证。

最后，我们检查电脑上真正发生了什么：摄像头有没有打开，文件有没有变化，桌面还能不能正常操作，并保留录像和检查结果。对于测试范围内出现的确认提示，我们先记录原文和画面，再按事先约定的策略批准继续，观察后续效果。最初有没有拦住、提示有没有说明风险、授权之后有没有发生危险效果，是三个需要分别记录的问题。如果效果是在授权后发生的，就明确写出这一点；如果证据不完整，就保留未评估状态。Agent说“完成了”或者“被拦住了”，还需要结合实际观察来判断。

三、测到现在，我们发现了什么

目前，我们围绕DeepSeek Harness、WorkBuddy、Codex CLI和Claude CLI，完成了四类安全测试，每个Agent纳入当前评分的场景有33个。有些操作被成功阻止，但也有不少危险效果最终发生了：摄像头被打开、声音被录下、文件被改动或删除，桌面受到干扰。不同Agent的表现存在差异，但测试让我们反复遇到一个问题：弹出了确认框，到底算不算保护了用户？

在不少受测场景中，沙箱先阻止操作，再弹出确认框，把是否继续的决定交给用户。用户点下“允许”，操作就继续执行。可是，用户看到的可能只是一条命令、一个程序名，未必知道接下来会发生什么。想让Agent把事情做完，并不意味着愿意交出私人资料，或者接受重要文件被删除。

确认框本身也容易让人麻木。Anthropic在关于Claude Code的报告中指出，97%的权限请求被用户批准，其中多数请求可能是安全的日常操作。但在另一项包含1,053名付费测试者的受控实验中，面对被替换进审批提示的明确危险命令，也只有13.6%的测试者将其拦下。频繁要求确认，并不意味着用户能可靠地判断每一次操作的风险。 报告原文

因此，我们不把“出现过确认框”直接算作保护成功，而是看最终保护率。对于测试范围内的审批请求，我们先保存提示原文和画面，再按事先约定的策略批准继续，检查危险效果最终有没有发生。如果只是最初被拦住，点下“允许”后仍然造成了损害，就不能计入最终保护成功。

最终保护率，就是在有效且已完成判定的测试场景中，最终阻止了目标危险效果的场景所占的比例，每个Agent分别计算。程序没写对、操作没有真正尝试，不能算保护成功；证据不足、尚未评估的场景不进入分母。初始拦截和风险提示仍然单独记录，但不能替代最终效果。

我们这样定义，是想看清楚：当用户选择继续完成任务时，产品还能不能守住需要保护的资源。这个指标衡量的是既定授权流程下的最终保护能力，并不代表日常使用中的事故概率。用户已经点过“允许”，不应该成为我们停止检查实际后果的地方。

作为对照，我们也记录了同一Agent使用FinShield时的表现。在目前纳入评分的FinShield对照组中，预先定义的目标危险效果都得到了阻止。具体配置和证据保留在各案例中。这让我们进一步思考：为什么面对同一种操作，不同的保护方式会得到不同的最终结果？

四、为什么会这样：完成任务和保护电脑，是两件事

这些大厂有能力做更严格的隔离。FinShield用到的系统安全机制，也并非只有我们才能使用。我们认为，眼前的差别，也与产品目标和取舍有关。对于Agent产品，一个重要目标是让Agent顺利工作。沙箱需要提供稳定、可用的执行环境，让它能读文件、运行工具，少被环境问题打断。遇到权限不足，产品通常会提供申请权限、确认放行等途径，让任务能够继续。

但站在用户这边，有些红线不能因为任务需要就被越过。Agent不能觉得某份资料“可能有帮助”，就自行读取；不能觉得某项权限“用起来方便”，就要求用户全部交出来。就像人做事要受法律和规则约束，不能拿“把事情办成”当作肆意妄为的理由，Agent也必须在用户允许的范围内行动。这两种出发点，会影响遇到限制时怎么处理。优先考虑任务能否完成，就容易把权限限制看作需要解决的障碍；优先保护用户，就要接受有些操作必须停下来。即使Agent给出了听起来合理的解释，也不能因此放开那些本来就不该碰的资源。

我们的判断是，受测产品目前更偏向于让Agent继续把任务做完。一些限制通过确认授权被放开，风险判断也随之交给了用户。但很少有用户能看懂每一条命令，判断每一次权限申请会带来什么后果。面对这些请求，用户往往只能猜：这是不是完成任务所必需的？点了允许，会不会出问题？在我们看来，这实际上把本该由产品承担的防护责任，推给了缺乏判断条件的用户。用户点了“允许”，并不意味着他真正理解了风险。有些边界应该由系统守住，不能靠用户猜对，更不能随着Agent完成任务的需要，一步步向外退。

技术可以借鉴，产品长期形成的优先级却很难改变。权限怎么申请、遇到限制怎么处理、什么时候让用户确认，都会受到这个优先级的影响。要改变这些选择，会牵动整个产品的兼容性和使用体验，很难靠补几条拦截规则解决。这也让独立防护有了价值：它可以专门围绕用户需要守住的红线来设计。

用户需要一层独立于Agent的防护。Agent可以想办法完成任务，但不能同时决定自己应该获得多大的权限。哪些资料可以读取、哪些设备可以使用、哪些操作必须禁止，需要由用户的保护规则来约束，不能因为Agent遇到了困难，就跟着放宽。独立第三方沙箱的价值，就在于把这道边界从Agent的任务执行中分离出来。它可以把保护用户放在首位，约束Agent和它启动的程序。Agent换了模型、改了计划，或者换一种方式运行代码，用户需要保护的东西仍然应该受到保护。这也是FinShield要做的事：让Agent在明确的权限范围内发挥能力，同时守住用户不愿交出去的资料、隐私和电脑控制权。从目前已公开的测评结果看，FinShield在这些受测场景中做到了这一点。

五、FinShield怎么做：给Agent一套单独的身份

FinShield复用Windows已有的权限设施，包括AppContainer、Job UI等，也参考了MXC、Chrome沙箱、Codex sandbox和Claude srt的设计。Codex和Claude也是我们的测评对象。研究它们的沙箱设计，给了我们不少启发，FinShield也从中借鉴了一些做法。

原理可以简单理解为：给Agent和它运行的程序一套单独的身份。它还在你的电脑上工作，但不会自动拿到你的全部权限。哪些文件可以读写、哪些设备可以使用，由这套身份对应的权限决定。Agent和工具仍然直接在本机运行，由Windows检查权限。任务需要的文件和资源，可以按规则开放；超出授权范围的访问，则由系统限制。整个过程不需要额外运行一套虚拟机，也就省去了这部分资源开销。

关于案例为什么这样设计、最终保护率如何判定，以及FinShield如何执行这些保护规则，我们会在后续技术文章中分别展开。我们也会继续补充测试和证据，让读者既能看到结果，也能复查结果是怎么得出的。