AI Agent 的权限弹窗常让用户困惑：为何每步都要确认？其实这是沙盒边界在起作用。本文深入解析文件、网络、进程三类沙盒如何约束 Agent，并给出设计权限表、规避常见误区的实操建议，帮你从底层理解 Agent 的安全机制。

刚开始使用一个能执行任务的AI Agent，很多人遇到的第一个困惑不是它能做什么，而是它为什么总在问我。

我让它修改一个文件，它问我是否允许写入；它准备运行测试，又问我是否允许执行命令；它要安装依赖、读取网页或调用外部服务时，还会弹出网络访问确认。任务明明是我发起的，为什么每走一步都要重新批准？

这些弹窗看起来像是在打断工作，其实是在提醒你：Agent准备执行一个可能影响本地环境或外部系统的动作。它需要确认的，通常不是「我是不是想让它继续」，而是「我是否允许它跨过这一道权限边界」。

也就是说，系统不是在每一步重新问你「还要不要继续」，而是在判断Agent这一步是否仍然处于被授权的范围内。这个范围，就是沙盒。

所谓沙盒，可以先把它理解成一套门禁系统。Agent能进入哪些目录、能修改哪些文件、能运行哪些命令、能连接哪些网络地址，都由系统提前划定。它只能在这个范围内工作，超出范围就会被拒绝，或者停下来询问你。

因此，审批弹窗是沙盒边界在产品界面上的表现。沙盒本身由系统强制执行，它不是模型自己在心里记住的一句「不要越权」。它也不一定意味着一定要启动一个虚拟机或容器，容器、虚拟机、操作系统权限、网络代理，都可以成为实现沙盒的技术手段。

一、每一次确认，实际上是在确认哪道边界

Agent走到不同步骤时，系统看到的风险并不一样：

并不是每一个动作都必须弹窗。通常，处在当前工作区和默认权限范围内的低风险操作可以直接执行；超出范围的操作，才会被系统拦截、请求确认或直接拒绝。这样做的目的，是让Agent能够连续完成日常任务，同时把真正需要你判断的动作单独提出来。

这里还有一个容易混淆的例子。你在A文件夹中启动一个项目，终端的当前工作目录可能是：

/Users/you/A/

这只代表命令默认从A文件夹开始执行，并不自动意味着Agent只能访问A。只要底层进程仍然拥有整个用户目录的权限，Agent理论上仍然可能通过命令访问：

/Users/you/B/

/Users/you/Documents/

/Users/you/.ssh/

真正的沙盒需要进一步规定：

允许读取：A/

允许写入：A/

允许运行：项目所需的命令

禁止访问：A/之外的目录

因此，「从哪里启动」是工作目录问题，「能访问哪里」是权限边界问题。两者经常同时出现，但不是一回事。

你在界面里看到的是一个确认弹窗，系统背后处理的却是文件、网络、进程和外部系统之间的边界。理解了这一层，沙盒就不再是一个抽象的工程术语。

图下注释：Agent从A目录启动，不代表它拿到了整台电脑的钥匙

二、沙盒到底是什么

可以把电脑想象成一栋大楼，里面有项目文件、个人文档、浏览器、数据库和系统配置。

Agent像一名执行任务的工作人员。它需要进入某些房间，使用一些工具，但不应该拿着一把能打开整栋楼的万能钥匙。

沙盒就是这套门禁系统：

• 哪些目录可以进入；
• 哪些文件可以读取、修改或删除；
• 哪些网络地址可以连接；
• 哪些程序可以启动或控制；
• 哪些资源和设备可以使用；
• 哪些动作必须先经过用户确认。

这里有一个重要的区分：沙盒本身主要负责「技术上能不能做」，审批机制负责「什么时候要先问你」。

比如，Agent要修改当前项目里的代码，可能属于已授权范围，可以直接执行；它要修改工作区之外的文件、访问网络或调用有副作用的外部工具时，系统可能会拒绝，或者弹出审批请求。

三、Agent是怎么被约束住的

Agent并不是一个单独的模型。一个能执行真实操作的Agent，至少还需要工具和执行环境。

大模型负责判断「下一步想做什么」，比如读取一个文件、运行测试或调用搜索工具。真正执行之前，Harness或工具执行层会检查这次调用是否符合权限规则。最后，操作系统、容器或其他运行时机制再把边界落实到实际执行过程中。

所以，产品里通常有几层东西一起工作：

拿「运行测试」这个动作举例。模型通常不会直接接触操作系统，而是先提出一个工具调用请求，类似这样：

{

“tool”: “shell”,

“command”: “npm test”,

“cwd”: “/Users/you/A”,

“network”: “off”

}

实际字段会随产品不同而变化，但执行链路大致相同：

1. LLM根据任务判断需要运行测试；
2. Harness把这个意图转换成结构化的工具调用；
3. 权限层检查命令、工作目录、文件范围和网络状态；
4. 操作系统或运行时在受限环境中启动命令；
5. 命令输出、错误信息和生成的文件再返回给LLM，供它决定下一步。

这里有一个产品上很重要的细节：npm test看起来只是测试命令，但它可能继续调用项目脚本、创建子进程、读取配置、访问依赖或启动服务。因此，系统不能只看命令名字，还要结合工作目录、环境变量、网络权限和子进程规则一起判断。

如果只在Prompt里写「你只能操作当前项目」，这仍然只是行为约定。真正的安全边界，必须由运行时、操作系统或权限系统强制执行。

四、最重要的三类沙盒边界

1. 文件沙盒：Agent能进入哪些房间

文件沙盒限制Agent能够看到和修改哪些内容。最直观的规则是：

A文件夹：允许读取、创建和编辑

B文件夹：禁止访问

系统目录和密钥目录：禁止访问或额外保护

这里还要进一步区分读权限和写权限。一个Agent可能可以读取整个项目，但只能修改某些子目录；也可能可以创建新文件，却不能删除已有文件。

文件沙盒要防的不只是「误删」。项目里的配置文件可能包含数据库地址、API Key和内部服务信息。如果Agent能够读取任意目录，它接触到的敏感信息就会明显增加。

再往下看一层，文件沙盒也不是简单地在界面上隐藏几个文件夹。执行层通常还要处理路径解析、相对路径、软链接和子进程继承权限等问题。比如，Agent请求访问A/../B，系统不能只检查字符串里有没有「A」，而要解析出它最终指向的真实路径；如果A里面有一个指向B的软链接，也不能因为链接位于A内，就默认允许它读取B。

这也是为什么「只在Prompt里提醒Agent不要访问其他目录」不够。真正的文件边界需要在操作系统或运行时层面生效，最好还要有日志记录：Agent访问了哪个路径，读取还是写入，是否被拒绝。

2. 网络沙盒：Agent能和谁通信

网络权限不只是「能不能上网」，还包括它能连接哪些目标：

• 公共网站和文档服务；
• 包管理器和依赖下载源；
• 本机启动的服务；
• 公司内网和云平台接口；
• 生产环境API和远程数据库。

如果网络完全开放，风险会从本地文件扩展到外部世界。Agent可能误把代码、配置或用户数据上传出去，也可能安装不可信依赖，访问本机或内网服务，调用产生费用或真实副作用的API。

因此，很多Agent产品会默认关闭命令的网络访问，或者采用按域名放行的方式。比如只允许访问依赖源和指定文档站点，不允许访问任意地址；涉及发布、删除、支付或修改生产数据的操作，还需要额外审批。

网络沙盒还有一个容易被忽略的边界：本机服务。即使Agent不能访问公网，如果它可以连接localhost上的数据库、后台管理服务或其他项目，也可能越过原本的任务范围。

网络控制通常会分成两步：先决定命令有没有网络能力，再决定它能连接哪些目标。常见做法包括默认关闭网络、按域名设置允许列表、限制本机和内网地址，以及通过代理记录出站请求。这样做的原因是，网络权限一旦打开，脚本和它创建的子进程通常也会继承这项能力。

所以，用户看到的「允许访问网络」弹窗，背后可能包含几个不同判断：它要访问哪个域名？是下载依赖、读取文档，还是上传文件？目标是公网、localhost还是公司内网？这也是为什么一个笼统的「允许联网」在产品上通常不够精细。

3. 进程沙盒：Agent能启动和控制哪些程序

进程就是一个正在运行的程序，例如Node.js服务、Python脚本、数据库、浏览器或测试命令。

进程沙盒通常限制Agent：

• 能启动哪些程序；
• 能查看哪些进程；
• 能结束哪些进程；
• 能创建多少个进程；
• 能占用多少CPU和内存。

如果没有这类限制，Agent执行一个清理、重启或调试命令时，可能误关闭其他项目的服务，读取其他程序的运行信息，或者因为不断创建后台任务而拖垮机器。

对产品经理来说，不必一开始就深入操作系统的进程模型。先记住一个判断就够了：Agent可以运行完成当前任务所需要的程序，但不应该因此获得控制整台电脑上所有程序的能力。

进程边界还会影响一个常见体验：为什么Agent启动的开发服务，有时会在任务结束后继续占用端口？因为Agent启动的不是一个孤立命令，而是一棵进程树。一个Shell可能继续启动Node.js服务，Node.js又可能创建子进程。如果系统没有统一管理进程组、运行时长和资源配额，就很难保证任务结束后所有后台进程都被清理。

因此，进程沙盒除了「能不能控制别的程序」，还涉及「自己启动的程序能活多久、消耗多少资源、任务结束后是否会被回收」。

五、沙盒不等于容器，也不等于虚拟机

这几个概念经常被放在一起，但它们解决的问题不同。

可以把它们放进一个关系里：

• Harness负责管理整体执行过程
• 沙盒负责划定技术边界
• 容器或虚拟机可以用来实现隔离
• 审批机制负责管理边界之外的请求

以Codex为例，官方文档把沙盒模式和审批策略分开描述：本地运行时通常通过操作系统级机制限制命令访问的文件和网络；审批策略则决定什么时候需要用户确认。常见的权限模式包括只读、工作区可写，以及几乎取消沙盒限制的高权限模式。具体行为会随运行界面和配置变化，使用时应以对应产品的官方文档为准。

Codex本地运行的官方说明：Sandbox、Agent approvals &amp； security。

六、如果从0到1做Agent，却没有沙盒，会发生什么

假设你做了一个「代码修改Agent」。用户让它修复A项目中的一个登录页面Bug。

如果你的系统把当前用户的Shell直接交给Agent，同时开放整个文件系统和网络，那么它实际上可能拥有这样的能力：

• 读取整个用户目录
• 修改任意可写文件
• 执行任意Shell命令
• 访问网络和本机服务
• 读取环境变量中的密钥
• 调用任意外部API

这时，风险不只来自模型本身。项目中的安装脚本、第三方依赖、网页内容和外部工具返回结果，也可能影响Agent的下一步行为。

图下注释：依赖脚本、环境变量和网络，会把一次普通操作变成扩散风险

可能出现的结果包括：

• Agent把B项目的文件当成当前项目的一部分进行修改；
• 清理命令的路径写错，删除无关文件；
• 测试脚本读取到数据库配置或云服务密钥；
• 安装了不可信依赖，执行了远程代码；
• 调用远程API，创建资源、修改数据或产生费用；
• 把代码、配置或用户资料上传到一个未经确认的服务。

这里的关键词是「可能」。只要Agent没有相关工具，它就不能凭空访问文件或网络；但一旦你把高权限工具暴露给它，风险就不再是模型回答得好不好，而是它能把什么动作真正执行出去。

一个完整的风险链路：从安装依赖到数据外传

假设用户对Agent说：「帮我安装项目依赖，然后运行测试。」这看起来是一个非常普通的开发任务，但它可能经过这样一条链路：

这里不需要假设模型故意作恶。风险可能来自被篡改的第三方依赖、项目中原本就存在的安装脚本，或者某个工具返回的恶意指令。

一套边界完整的系统，可以在多个位置切断这条链路：不把生产密钥放进Agent环境；限制它只能读取当前项目；默认关闭网络；安装依赖或执行脚本前展示具体命令；任务结束后清理临时凭证。即使某一层判断失误，其他层仍然有机会把影响控制住。

这就是沙盒的实际价值：它不是保证Agent永远不会判断错误，而是让一次错误判断不至于直接扩散到整台电脑和所有外部系统。

七、看到确认弹窗时，应该看什么

当确认弹窗出现时，不要只看「允许」还是「拒绝」。你可以先确认4件事：

比如，Agent请求运行npm install时，真正需要判断的就不只是“要不要安装依赖”，还包括：它在哪个目录执行？依赖安装脚本会不会被运行？是否需要访问网络？网络目标是包管理器，还是一个不熟悉的域名？

再比如，弹窗写着「允许访问网络」，这个信息仍然不够完整。你至少要知道它准备访问哪个目标。访问官方文档和访问localhost上的数据库，风险不是一个量级；下载依赖和上传项目文件，也不是同一种操作。

如果弹窗提供「仅本次允许」「允许本次任务」「始终允许」等选项，优先选择范围更小、有效期更短的选项。重复出现确认很烦，但永久放开权限，往往会让后续每一次操作都失去这道提醒。

一个好的确认弹窗，应该让用户在点击前看到动作、目标、影响和权限期限。用户不需要理解容器、系统调用这些工程术语，但应该能判断：这次操作是不是我期待的，影响是不是我能接受的。

八、如果你正在设计Agent，先把这张权限表填出来

从0到1做产品，不需要第一天就实现最复杂的虚拟机集群。但至少要把下面这些问题写清楚：

这张表背后对应的是一个很实用的设计原则：最小权限。

Agent不是需要什么权限就一次性给满。更稳妥的做法是先问：完成这个任务最少需要什么？只给这些权限；当它确实需要跨出边界时，再通过审批或受控接口临时放行。

图下注释：权限不是越多越省事，而是只给当前任务真正需要的那一部分

但权限也不能一味收紧。沙盒过严，Agent可能连安装依赖、运行测试这样的日常任务都无法完成；权限过松，用户虽然少看到几个弹窗，风险却转移到了数据和外部系统上。产品设计要做的是在「自主完成」和「用户控制」之间划出不同等级：

审批弹窗本身也需要设计。一个只写着「是否允许执行」的弹窗，把判断成本全部推给用户；更好的确认信息至少应该说明：准备执行什么动作、目标路径或域名是什么、为什么需要这项权限、权限只对当前动作有效还是对后续一段时间有效。

例如，下面两种提示的差别很大：

是否允许？

Agent请求执行：npm install

工作目录：/Users/you/A

可能影响：执行项目依赖中的安装脚本

网络访问：registry.npmjs.org

权限范围：仅当前任务

前者只能让用户凭感觉点击，后者才让用户有机会做出判断。对于删除文件、上传内容、发布信息、修改远程数据等不可逆操作，还应该把确认做得更明确，必要时要求二次确认或拆成预览和执行两个步骤。

九、几个常见误区

误区一：把规则写进Prompt就安全了

「只能操作当前项目」可以帮助模型理解任务范围，但它不是权限系统。模型可能理解错，工具也可能被绕过。越权限制必须落在执行层。

误区二：从A文件夹启动，Agent就只能访问A

启动目录只是当前路径。是否能访问B，取决于操作系统和沙盒给了它什么权限。

误区三：用了容器，就一定安全

容器是隔离手段，不是安全结论。如果把整个用户目录挂载进去，或者把宿主机的高权限接口暴露给容器，边界仍然可能很宽。

误区四：只限制文件就够了

Agent可以不修改文件，却通过网络上传数据；也可以不访问B文件夹，却通过进程、密钥或本机服务获取信息。文件、网络、进程、凭证和资源边界需要放在一起看。