Sandboxing for agents
Sandboxing for agents 指通过操作系统、文件系统、网络和代理层为 agent 预先划定能力边界，让它在边界内高自治运行，越界时再触发审批或阻断。这个概念的重点不是“判断 agent 想做什么”，而是“即使 agent 被 prompt injection 影响，它客观上还能做什么”。
- sandboxing 的核心价值是把安全问题从“每一步都判断意图”部分转成“先限制可用能力范围”。
- 对 coding agent 来说，最关键的两类边界通常是
filesystem isolation和network isolation。 - 文件系统隔离限制 agent 只读写指定目录，避免它接触 SSH key、系统配置、其他项目或宿主机敏感文件。
- 网络隔离限制 agent 只访问允许的服务，避免数据外泄、恶意下载或任意对外连接。
- 两种隔离往往需要同时存在，因为单独使用其中一种都容易留下明显逃逸面。
- 这个概念与 Permission delegation for agents 相关，但不相同。后者关注“谁来批准动作”，前者关注“即使批准机制失效，动作本身还能触达哪些资源”。
- 它也与 Agent scaffold 直接相关，因为沙箱、代理、allowlist、越界提示和 scoped credential 都属于 scaffold 的权限与运行时边界层。
- 在云端执行场景里，sandboxing 往往还要进一步结合凭据代理，把真正高价值 credential 留在沙箱外，由受控服务代执行敏感操作。
- 从这个角度看，sandboxing 不是自治的对立面，反而常常是更高自治的前提：因为先有硬边界，系统才敢少弹窗、多放权。
- 《My fireside chat about agentic engineering at the Pragmatic Summit》把这一点讲得更直白：prompt injection 的第一防线不是“别被骗”，而是“就算被骗了也别有太大破坏面”。因此沙箱往往比单纯的提示或审批更 load-bearing。
- 同一篇文章也保留了一个很现实的张力：即使最清楚风险的人，也会因为便利而在本机开启高权限模式。这说明沙箱的难点不只是技术实现，还包括能否在安全与摩擦之间找到用户愿意长期遵守的平衡。
ℹ️ Conflict:
- sandboxing 不等于不需要审批。对于越界访问、高风险写操作或新网络目标，系统通常仍需要人工确认或更强规则。
- 安全性高度依赖具体配置。过宽的目录范围、过松的代理规则或错误的 host allowlist，会让“有沙箱”迅速退化成“看起来像有沙箱”。
- 更强隔离虽然更安全，但也会提高环境复杂度，并可能和某些真实开发工作流产生摩擦。
- Beyond permission prompts- making Claude Code more secure and autonomous
- My fireside chat about agentic engineering at the Pragmatic Summit
- Permission delegation for agents
- Agent scaffold
- Agentic engineering
- Anthropic
- Anthropic, “Beyond permission prompts- making Claude Code more secure and autonomous”, 2025-10-20.
- 原文摘录：[llm-wiki/raw/anthropic/Beyond permission prompts- making Claude Code more secure and autonomous](/raw/anthropic/Beyond permission prompts- making Claude Code more secure and autonomous.md)
- Simon Willison, “My fireside chat about agentic engineering at the Pragmatic Summit”.
- 原文摘录：[llm-wiki/raw/01_AI/My fireside chat about agentic engineering at the Pragmatic Summit](/raw/01_AI/My fireside chat about agentic engineering at the Pragmatic Summit.md)