当团队里出现一个“什么都能找到、什么都敢使用”的新成员时，真正的风险并不只在于它会不会写代码，而在于它是否知道哪些内容值得信任。对 Agent 来说，这个问题更加突出：它可能读取仓库、调用工具、安装依赖、访问环境变量，还可能根据不可靠的指令继续行动。
“Secure by default is your only way forward”给出的方向很明确：不要把安全寄托在 Agent 每次都做出正确判断上，而要提供一个经过加固的基础，并在 Agent 与外部世界之间建立清晰边界。
信任不能靠猜
传统开发流程里，人类工程师通常会主动判断：这个脚本来自哪里？这个依赖是否可信？这个命令是否会修改生产环境？Agent 则可能把搜索结果、仓库文档、Issue 内容、依赖元数据和工具返回值一起当作上下文。
这意味着，任何“看起来像指令”的文本都有机会影响后续行为。例如，仓库中的文档可能要求执行一个下载脚本，第三方工具的输出可能诱导 Agent 访问敏感文件，某个依赖的安装步骤也可能包含超出任务范围的操作。
因此，安全设计不应只依赖提示词中的一句“请谨慎操作”。更可靠的做法是把信任判断转换成系统约束：
- 默认使用最小权限，而不是继承宿主机的全部权限。
- 默认隔离网络、文件系统和凭据。
- 对安装依赖、执行命令、写入目录等高风险动作设置边界。
- 将外部内容视为不可信数据，而不是自动执行的指令。
- 对无法证明安全的操作要求人工确认。
加固基础应该包含什么
一个面向 Agent 的基础运行环境，至少需要明确四个范围：
- 文件范围：Agent 只能读写任务需要的工作目录，不能随意读取用户目录、SSH 密钥或云凭据。
- 网络范围：默认拒绝外网访问，只允许经过审核的域名或内部服务。
- 执行范围：限制可执行程序和系统调用，避免任意提权或修改宿主机配置。
- 身份范围：使用短期、低权限、可撤销的凭据，并避免把宿主机环境变量全部暴露给 Agent。
这些限制的价值不在于让 Agent “什么都做不了”，而在于缩小一次误判的影响面。Agent 仍然可以完成构建、测试、代码分析等任务，但它的行动半径被限制在明确的工作区内。
一个可落地的最小边界
下面是一个可以改造的 Docker 示例。它不是完整的生产级沙箱，但适合作为本地实验或 CI 任务的起点：默认使用非 root 用户，只挂载工作目录，禁止网络，并丢弃 Linux capabilities。
运行前，将 ./workspace 替换为实际的代码目录，并确认任务确实不需要访问外部网络。
docker run --rm \
--network=none \
--cap-drop=ALL \
--security-opt=no-new-privileges:true \
--read-only \
--tmpfs /tmp:rw,noexec,nosuid,size=128m \
--user 10001:10001 \
--mount type=bind,src="$PWD/workspace",dst=/workspace \
--workdir /workspace \
agent-sandbox:latest \
sh -lc 'python -m pytest'
这个命令表达了几个关键决策：
--network=none防止测试过程意外访问外部服务或上传数据。--cap-drop=ALL删除容器默认的 Linux 能力。--read-only让根文件系统不可写，临时文件只进入受限的/tmp。--user 10001:10001避免以 root 身份执行 Agent 产生的命令。--mount只暴露明确的工作目录，而不是整个宿主机文件系统。
如果构建流程必须联网，可以把网络从“默认拒绝”改成“显式允许”。例如在 CI 中使用代理或依赖缓存，只开放构建所需的内部地址，并记录每次网络访问。
把高风险动作放到边界外
Agent 不应直接拥有发布、删除数据、修改权限或读取长期凭据的能力。更稳妥的架构是让 Agent 生成一个结构化请求，再由边界服务校验请求并执行。
可以这样定义一个最小的动作协议：
# agent-action.yaml
version: 1
action: run_tests
workspace: /workspace
command:
- python
- -m
- pytest
network: disabled
requires_human_approval: false
边界服务需要检查 action 是否在允许列表中、workspace 是否位于受控目录、命令参数是否符合 schema，以及网络权限是否与任务匹配。对于发布生产、删除资源、读取密钥等动作，应将 requires_human_approval 设为 true，并在执行前暂停等待人工确认。
这里的重点是“能力和决策分离”：Agent 可以提出行动，但不应自动获得超出任务范围的权限。边界服务也不应盲信 Agent 生成的字段，而要重新计算实际权限。
采用时的检查清单
可以从一个低风险任务开始，例如在隔离环境中运行测试或生成代码摘要，然后逐步扩大能力范围。上线前至少确认：
- 工作目录之外的文件是否完全不可读写。
- 外部网络是否默认关闭，开放项是否有记录。
- Agent 是否以非 root 用户运行。
- 凭据是否短期、低权限且不会进入上下文。
- 高风险命令是否使用允许列表，而不是任意 shell 字符串。
- 每次工具调用是否记录了调用者、参数、结果和审批状态。
- 失败时系统是否默认拒绝，而不是自动放宽权限。
安全的 Agent 基础不是一组写在文档里的注意事项，而是一套即使 Agent 误解上下文、采纳了不可信内容，也能限制损害范围的运行约束。面对一个“拿到什么就用什么”的新成员，最可靠的管理方式不是期待它永远谨慎，而是让安全成为它无法绕开的默认环境。