沙箱与凭证隔离
生成的代码和密钥永远不在同一个容器里。结构性安全比靠提示词更可靠
本页解决的问题
先给结论「沙箱与凭证隔离」要解决的关键问题是什么？
生成的代码和密钥永远不在同一个容器里。结构性安全比靠提示词更可靠
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
永远不能在同一个地方
传统架构：一个容器装所有东西
echo $API_KEY），就能窃取环境变量中的所有密钥。整个攻击链极短，防不胜防。https://token@github.com/repo.git
沙箱内的 Agent 可以正常执行 push/pull 操作，但无法直接读取或提取 Token：它被嵌入在 Git 配置的深层，不是一个可读的环境变量。
三重隔离屏障
从工具到组织的分层权限控制
「核心原则」里的风险边界在哪里
「生成的代码和密钥永远不在同一个容器里。结构性安全比靠提示词更可靠」把安全问题从一句“请模型不要犯错”拉回到权限、数据和环境。真正需要保护的是：模型即使判断失误，系统也不能让错误变成不可逆的结果。
把模型建议和实际权限分开
在「生成的代码和密钥永远不在同一个容器里。结构性安全比靠提示词更可靠」涉及的流程中，要分别检查用户能要求什么、模型能建议什么、工具实际允许什么，以及谁有权批准写入或发送。网页、文档和工具返回值都可能携带不可信指令，不能因为它们看起来像说明就自动提升权限。
安全设计必须包含失败和恢复
结合「生成的代码和密钥永远不在同一个容器里。结构性安全比靠提示词更可靠」做一次反向演练：加入错误输入、缺失凭证或迟迟不到的审批，确认系统会拒绝、暂停并留下可追踪信息，而不是继续执行到底。
从「核心原则」走到「旧方案出了什么问题」
「核心原则」先把问题落在「生成的代码和密钥 永远不能在同一个地方 这是管理 Agent 安全的第一原则：凭证与执行环境的物理隔离」上；到了「旧方案出了什么问题」，讨论继续推进到「传统架构：一个容器装所有东西 所有东西在一个容器里 代码执行、API 密钥、OAuth Token、会话凭证，全部共存在同一个运行环境中。Agent 能看到的一切，恶意代码也能看到。 Prompt Injection 一步偷走密钥 攻击者只需通过 Prompt Injection 说服 Agent 执行一行代码（ echo $API_KEY ），就能窃取环境变量中的所有密钥。整个攻击链极短，防不胜防。 Agent 越…」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
做安全判断时，把“模型想做什么”和“系统允许做什么”分开，逐个检查数据边界、工具权限、人工确认和失败后的恢复路径。
- 「核心原则」：生成的代码和密钥 永远不能在同一个地方 这是管理 Agent 安全的第一原则：凭证与执行环境的物理隔离
- 「旧方案出了什么问题」：传统架构：一个容器装所有东西 所有东西在一个容器里 代码执行、API 密钥、OAuth Token、会话凭证，全部共存在同一个运行环境中。Agent 能看到的一切，恶意代码也能看到。 Prompt Injection 一步偷走密钥 攻击者只需通过 Prompt Injection 说服 Agent 执行一行代码（ echo $API_KEY ），就能窃取环境变量中的所有密钥。整个攻击链极短，防不胜防。 Agent 越…
- 「三层信任层级」：从工具到组织的分层权限控制 TOOL 工具级信任 最细粒度的控制。某些特定工具需要每次使用都经过人工审批，比如文件删除、数据库写入、发送邮件等高危操作。对于安全的只读操作（如搜索代码、读取文件），可以设为自动放行。 SESSION 会话级信任 某次对话的权限范围。用户在开始会话时授予 Agent 特定范围的权限（如「可以读写 /src 目录但不能改 /config」），整个会话期间权限范围保持不变。会话结束后权限自动…
最后的「三层信任层级」把讨论落到「从工具到组织的分层权限控制 TOOL 工具级信任 最细粒度的控制。某些特定工具需要每次使用都经过人工审批，比如文件删除、数据库写入、发送邮件等高危操作。对于安全的只读操作（如搜索代码、读取文件），可以设为自动放行。 SESSION 会话级信任 某次对话的权限范围。用户在开始会话时授予 Agent 特定范围的权限（如「可以读写 /src 目录但不能改 /config」），整个会话期间权限范围保持不变。会话结束后权限自动…」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。