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”
}
实际字段会随产品不同而变化，但执行链路大致相同：
LLM根据任务判断需要运行测试；Harness把这个意图转换成结构化的工具调用；权限层检查命令、工作目录、文件范围和网络状态；操作系统或运行时在受限环境中启动命令；命令输出、错误信息和生成的文件再返回给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 &； 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文件夹，却通过进程、密钥或本机服务获取信息。文件、网络、进程、凭证和资源边界需要放在一起看。
本文由人人都是产品经理作者【PM维他命】，微信公众号：【PM维他命】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议
天顺优配提示：文章来自网络，不代表本站观点。
