把 Agent 放进容器，就能放心给它电脑权限了吗？

把 Agent 放进容器，就能放心给它电脑权限了吗？

容器里看见的文件，可能正是宿主的真文件

我们让代码助手在容器内修库存脚本。容器有自己的目录树和进程环境，看起来与个人电脑分开。但启动配置把宿主整个工作目录挂载进来，还允许访问外网，并复用已登录的浏览器会话。此时“运行在容器里”只描述了一部分隔离方式，不能说明它可触及的数据范围。

假设容器路径 /workspace 对应宿主真实项目。助手在里面删除文件，可能就是删除宿主项目文件；若以只读方式挂载，同样的删除调用会被操作系统拒绝。真正决定行为的是挂载与访问模式，不是容器名称是否带sandbox。安全边界需要具体到资源和动作。

第一张是文件：哪些目录可读、可写，临时文件在哪里，敏感目录是否挂载。第二张是进程：能否启动子进程、接触其他进程、调用宿主接口。第三张是网络：允许哪些目标、端口与协议，是否能访问内部服务。第四张是资源：CPU、内存、磁盘、执行时长和并发数量有没有上限。

只读文件限制不了外发：能读到敏感文件又能访问任意网络，仍可能泄露内容。禁止外网也不等于不破坏本地：允许写关键目录，就可能损坏工作成果。限制工具名称也不等于限制工具内部行为：一个shell命令可能访问比表面单一动作更广的资源。需要将几种边界组合起来检查。

配置A只挂载任务副本，禁止访问其他目录，网络仅允许获取指定公开依赖，临时目录在任务结束后清理。若助手写错结果，影响集中在副本与输出；独立检查通过后再决定是否接纳变更。配置B挂载宿主用户目录、允许任意网络、继承管理凭据。同一个“列文件”工具在B里可能看到远超任务所需的信息。

这不是说A绝对安全。容器与宿主通常共享内核，配置错误或底层漏洞仍可能影响隔离；虚拟机有独立客户机内核但仍存在共享目录、网络和管理接口。边界强度不同，不能把任何技术标签理解成永不逃逸。任务需求、成本与风险决定合适组合。

观察过程 · 改变条件

先预测结果，再逐步查看；切换条件时留意是哪一个中间量改变。案例是教学构造的规则回放，不是模型训练实测。

教学构造场景 · 按下方规则逐步回放；不调用真实模型，不代表实际成功率。

这一轮的输入

仅暴露输入副本与专用输出目录

读入范围

可读库存输入，不可读任务外目录。

1 / 3

先预测，再核对结果与原因

错误修改的影响被限制。

隔离来自明确挂载、权限和生命周期，仍需独立验证。

假设每次运行都有新容器，但共享一个包缓存。一次任务把缓存中的构建产物改了，后续发布任务直接复用它，污染就跨越了容器生命周期。类似地，共享浏览器登录、数据库、消息队列和持久卷，都可能让一次运行影响下一次。删除容器本身不等于撤销所有副作用。

在教学库存例子中，可以让每次任务使用独立输入副本和输出目录，记录内容摘要与运行ID；需要共享的数据明确标只读。依赖缓存若允许写，必须有校验与隔离策略。不能因为缓存命中提高速度，就自动把来自不可信任务的缓存变成可信构建输入。

检查配置文件还不够。用无害测试确认：读取允许文件成功，读取任务外测试文件失败；写输出目录成功，写只读输入失败；允许的测试网络目标可达，禁止目标不可达；超时任务被终止且子进程清理。这里测试的是预期政策，不涉及真实敏感文件或破坏性操作。

两个条件变化尤其容易让测试过期：新加一个宿主挂载，或给浏览器接入已登录账号。前者扩展文件边界，后者扩展远程服务能力，即使镜像和模型完全未变，系统的实际权限已经改变。配置版本应与运行日志一起保存。

下一课进一步收紧“可以访问订单服务”这句话：查询、修改和删除不同，身份、授权和密钥也不同。即使隔离环境允许连到服务，模型仍不应该因为要查一个订单就拿到管理员密码。

问题 1

只读挂载是否也防止数据外发？

展开解释

不一定。只读禁止修改，仍允许读取；若同时有外发网络能力，数据仍可能离开，需要单独限制网络和动作。

问题 2

删除容器是否清除共享缓存里的改动？

展开解释

通常不会自动清除。持久卷、缓存、浏览器会话等有独立生命周期，必须识别与管理。

问题 3

为什么新加挂载后要重新测边界？

展开解释

因为Agent可触及的资源已经改变。模型和镜像不变不代表系统权限不变，旧验证证据不覆盖新连接。