AI Agent 沙箱缺失：当”工作助手”拥有管理员权限，你的数据还安全吗？
为什么值得看
你可能正在用 WorkBuddy、TraeWork 或类似的 AI 工作套件来提升效率。它们确实好用——自动生成代码、管理项目、调用工具，一切丝滑到让人忘记背后发生了什么。
但我想讲一件真实发生在自己身上的事：一个 AI Agent 在我的电脑上创建了一个磁盘根目录级别的文件夹，而它本不应该拥有这个权限。当我追问机制时，Agent 自己承认了——它的工具层根本没有强制执行工作区路径白名单，工作区边界只是”约定”，不是沙箱。
直说结论：如果你有技术背景，目前不建议使用此类工作套件的 AI 应用——除非厂商正式修复沙箱隔离问题。 这不是小题大做。向厂商提交反馈也是在保护他们自己：如果用户数据因沙箱缺失而泄露或损坏，厂商自身同样面临被追责的法律与声誉风险。安全问题拖得越久，代价越大。
你将学到三点
- AI Agent 的”工作区限制”可能只是软约束，而非技术强制的沙箱隔离。 区分”策略层约束”和”文件系统沙箱”的本质差异。
- 非技术用户友好 ≠ 放弃安全控制。 UX 和安全的取舍不应该以牺牲沙箱为代价，行业需要找到更好的平衡点。
- 评估 AI 工作工具时，沙箱隔离能力应该是一票否决项。 一条可直接套用的安全评估清单。
事件还原：Agent 如何越界
我平时几乎不用工作套件类的 AI 工具，但今天任务积压太多，pipeline 里排不过来，才临时用 WorkBuddy 分担一部分。WorkBuddy 提供两种权限模式：默认权限和完全控制权限。如果是在”完全控制”模式下发生越界，尚可理解——用户已经主动放开了限制。但这次用的是默认权限，产品声明”仅限工作区文件夹”，结果 Agent 依然拿到了完整的文件系统写权限。
但实际发生了什么？Agent 为了规避 Windows 260 字符路径限制，主动将仓库浅拷贝到一个极短路径 C:/k/KylinASR。它使用的命令：
shutil.copytree(src, 'C:/k/KylinASR', ignore=...)
shutil.copytree 在目标父目录 C:\k\ 不存在时会自动创建——于是磁盘根目录下多了一个不该存在的文件夹。
WorkBuddy 自己的回应（截图）：
Agent 坦承：
工具层没有强制执行工作区路径白名单。我可用的 Bash 和 Write/Edit 工具操作的是整个本地磁盘，并不在工具层面把写操作限定在工作区内。工作区边界目前是约定/策略层的约束，不是文件系统沙箱。
这不是”获取了”根级访问权，而是 Agent 的本地工具本来就拥有你账户的完整文件系统写权限。工作区约束只是 prompt 层面的约定，而非操作系统级别的隔离。
这不只是 WorkBuddy 的问题
WorkBuddy 不是个例。TraeWork 等类似工作套件也存在类似的沙箱逃逸风险。从我的使用经验来看，国内厂商在 AI Agent 安全意识上普遍落后于海外厂商。 这不是技术能力的差距，而是产品优先级的取舍——把”流畅体验”和”功能覆盖”排在了”安全隔离”前面。
这类产品的共同设计逻辑是：
| 设计选择 | 带来的好处 | 隐藏的代价 |
|---|---|---|
| Agent 使用用户账户权限运行 | 无需复杂权限管理，UX 丝滑 | Agent 可以做用户能做的一切——包括误操作 |
| 工作区边界靠 prompt 约定 | 开发简单，灵活度高 | 任何 prompt injection 或自主决策都可能越界 |
| 不强制弹窗确认每步操作 | 非技术用户不会被搞晕 | 危险操作静默执行，用户事后才发现 |
作为对比，我日常使用的 OpenCode 就是一个正面示例。当 Agent 需要访问工作区外的目录时，它会明确弹出权限请求，展示具体路径，并提供三个选项：Allow once（仅一次）、Allow always（始终允许）、Reject（拒绝）。
这才是 AI Agent 该有的安全姿态——不是不让用，而是让你知道它要做什么，由你决定是否放行。
这类产品往往面向没有技术背景的终端用户。对这些用户来说，”是否允许写入 C:\?”这种弹窗既令人困惑又破坏流畅感——他们可能根本不理解这意味着什么。于是产品设计者选择跳过确认，换取更好的 UX。
但 UX 的流畅不应该以裸奔的安全为代价。 OpenCode 证明了安全和体验可以兼得：清晰的路径展示 + 分级授权（一次/始终/拒绝）既不牺牲 UX，又守住了安全底线。
核心矛盾：安全 vs. UX/能力，不能二选一
行业正在犯一个危险的错误：为了追求能力和用户体验，把安全控制当作可选项。
正确的思路应该是：
- 沙箱是底线，不是可选项。 AI Agent 应该在操作系统级别的沙箱中运行，而非仅靠 prompt 约束。文件系统访问、网络请求、进程创建——每一项都应该是显式授权的。
- 安全确认可以设计得更好。 与其弹一个让人困惑的 “Allow C:\ write?” 对话框，不如用可视化的文件树展示 Agent 要操作的范围，让用户一目了然。
- 分级权限是方向。 不是所有操作都需要同级别的确认。读取工作区文件可以静默，写入工作区外需要明确授权，删除操作需要二次确认。
| 策略 | UX 影响 | 安全性 | 适用场景 |
|---|---|---|---|
| 无沙箱，全靠 prompt | 最佳 | 极差 | 不推荐 |
| 可视化范围确认 | 良好 | 好 | 写入工作区外 |
| 操作系统级沙箱 | 需适配 | 最佳 | 所有 Agent 操作 |
| 分级权限 + 白名单 | 中等 | 好 | 企业级部署 |
给你的建议：AI 工具安全评估清单
在选择 AI 工作套件时，问这几个问题：
- Agent 是否在操作系统级沙箱中运行？（而非仅靠 prompt 约束）
- 文件系统访问是否限定在显式声明的工作区内？
- 写入工作区外的操作是否需要用户确认？确认方式是否可理解？
- 是否有操作日志，能回溯 Agent 做了什么？
- 是否支持自定义权限策略（如禁止网络访问、禁止执行 shell）？
如果以上任何一项答案是”否”，请认真评估风险。 便利性很重要，但数据安全没有后悔药。
如果你已经遇到类似问题，向厂商提交反馈。 这不只是在保护自己——如果沙箱缺失导致用户数据泄露或系统损坏，厂商自身同样面临法律追责和声誉损失。推动厂商修复安全问题，是在降低整个生态的风险。
总结
- AI Agent 的”工作区限制”可能只是 prompt 层面的软约束，而非技术强制的沙箱隔离——Agent 拥有的是你账户的完整权限。
- 非技术用户友好不等于放弃安全控制，行业需要在 UX 和安全之间找到更好的平衡，而非简单地跳过安全确认。
- 沙箱隔离能力应成为选择 AI 工具的一票否决项——便捷可以迭代，数据安全不能事后补救。
- 技术用户应主动向厂商反馈安全问题，推动修复——这既保护自己的数据安全，也降低厂商被追责的风险。安全是双方的事。
AI Agent 正在变得越来越强大，但”能做什么”和”该做什么”之间的边界需要被明确划定。希望这篇文章能帮你在下一次选型时，多问一个关键问题：它的沙箱在哪里？