Anthropic 工程团队最近公开了他们在三款 Claude 产品中构建 Agent 安全隔离的完整思路。这不是一篇泛泛而谈的"安全最佳实践"——它直接回答了一个工程难题:同一个模型,跑在不同风险等级的产品里,隔离策略该怎么分层设计?
三款产品分别是面向普通用户的 claude.ai、面向开发者的 Claude Code、面向企业协作的 Claude Cowork。它们共享同一个底层模型,但风险模型截然不同,隔离手段也因此逐层加码。核心原则只有一条:环境层隔离优先,模型层防护兜底。
下面逐层拆解,并给出可以直接改造的隔离方案示例。
claude.ai:最小权限 + 网络断路器
普通用户场景的风险特征很明确——用户基数大、意图不可预测、单次交互成本低但累积危害高。claude.ai 的隔离策略围绕两个关键词:
- 最小权限沙箱:Agent 能调用的工具集被严格裁剪。没有文件系统写入权限,没有任意网络请求权限,只有经过审核的有限工具(搜索、简单计算等)。
- 网络断路器(circuit breaker):即使 Agent 通过工具链间接获得了网络能力,出口流量也会被强制拦截。这不是"建议不要联网",而是物理层面不可联网。
换句话说,claude.ai 的防线不在模型行为上做精细判断——它直接把危险能力从环境中移除。模型想越界也越不了。
Claude Code:开发沙箱 + 操作审计
Claude Code 面向开发者,天然需要文件读写、命令执行、Git 操作等高权限能力。风险模型翻转了:你需要给它权力,但必须让权力可观测、可回滚。
隔离策略的核心变化:
- 开发沙箱:Agent 在隔离的文件系统分支(git worktree 或独立目录)中操作,变更不会直接污染主仓库。所有修改先进入沙箱,经确认后才合并。
- 操作审计日志:每一条 shell 命令、每一次文件写入都被记录。不是事后日志,而是实时流——用户可以在 Agent 执行前拦截,也可以在执行后回滚。
- 分级权限模型:低风险操作(读文件、git status)自动放行;高风险操作(删除文件、推送到远程、安装包)必须用户显式确认。
这里的关键洞察是:开发者场景不能靠"不给权限"来安全,而是靠"给权限但加审计和回滚"来安全。
Claude Cowork:企业级多租户隔离
Cowork 是最复杂的一层。多个 Agent 同时在同一个企业空间里协作,它们可能代表不同部门、不同角色,甚至不同信任等级的外部合作方。风险模型从"单用户越界"升级为"跨租户渗透"。
隔离策略叠加了新维度:
- 租户级环境隔离:不同团队/部门的 Agent 运行在独立的计算环境中,共享模型但不共享运行时状态。一个 Agent 的文件系统、网络配置、工具集对其他 Agent 不可见。
- 跨租户交互网关:Agent 之间的协作必须经过显式的网关层——类似 API gateway,每一条跨租户请求都要经过策略校验、内容过滤和审计。
- 企业策略引擎:管理员可以定义全局策略(如"禁止访问财务数据"、"禁止向外部发送邮件"),策略在环境层强制执行,不依赖模型自觉遵守。
这一层的设计哲学是:模型是共享的,但运行时是隔离的。协作是允许的,但必须经过网关。
核心原则:环境层隔离优先
三款产品的策略差异很大,但都遵循同一个优先级:
- 环境层隔离(第一优先):从物理层面移除或限制能力——网络断路器、沙箱文件系统、租户隔离环境。模型无法绕过。
- 模型层防护(兜底):在模型推理阶段加入安全约束——拒绝生成危险指令、过滤敏感输出。但这只是补充,因为模型行为不可完全预测。
- 审计与回滚(纵深):记录所有操作,提供回滚能力。这是最后一层保险。
为什么环境层优先?因为模型层防护本质上是"软约束"——prompt injection、工具链组合攻击、长上下文中的隐蔽指令都可能绕过模型层的安全判断。环境层隔离是"硬约束":你没有网络接口,就真的无法联网,不管模型怎么想。
实践:用容器 + 策略引擎构建 Agent 安全沙箱
下面给出一个可以直接改造的方案——用 Docker 容器做环境层隔离,用 Python 策略引擎做操作分级审批。这个方案模拟了 Claude Code 的"开发沙箱 + 分级权限"思路。
第一步:定义策略配置
# agent_policy.yaml — Agent 操作分级策略
sandbox:
# 沙箱容器配置:无网络、受限文件系统
container:
image: agent-sandbox:latest
network_mode: none # 环境层隔离:物理断网
read_only_root: true
volumes:
- ./workspace:/workspace # 只挂载工作目录
cap_drop:
- ALL # 移除所有 Linux capabilities
permissions:
# 低风险:自动放行
auto_approve:
- file_read
- git_status
- git_log
- git_diff
- shell_safe # 白名单命令:ls, cat, grep, find, wc
# 高风险:必须用户确认
require_approval:
- file_write
- file_delete
- git_push
- git_commit
- shell_unsafe # 非白名单命令
- package_install
audit:
log_path: ./audit/agent_actions.jsonl
real_time_stream: true # 实时推送操作流给用户
第二步:策略引擎实现
# policy_engine.py — Agent 操作分级审批引擎
import json
import yaml
from pathlib import Path
from datetime import datetime
SAFE_COMMANDS = {"ls", "cat", "grep", "find", "wc", "head", "tail", "git", "echo"}
class AgentPolicyEngine:
"""根据策略配置,对 Agent 操作做分级审批和审计记录。"""
def __init__(self, policy_path: str = "agent_policy.yaml"):
with open(policy_path) as f:
self.policy = yaml.safe_load(f)
self.log_path = Path(self.policy["audit"]["log_path"])
self.log_path.parent.mkdir(parents=True, exist_ok=True)
def check_permission(self, action_type: str, action_detail: str) -> dict:
"""
返回 {"approved": bool, "reason": str, "needs_user_confirm": bool}
环境层隔离已由容器保证,这里做操作层分级。
"""
auto = self.policy["permissions"]["auto_approve"]
require = self.policy["permissions"]["require_approval"]
# 判断操作类型归属
if action_type in auto:
# shell_safe 还需要检查具体命令是否在白名单
if action_type == "shell_safe":
base_cmd = action_detail.strip().split()[0]
if base_cmd not in SAFE_COMMANDS:
return self._reject(
f"命令 '{base_cmd}' 不在安全白名单中", action_type, action_detail
)
return self._approve(action_type, action_detail, needs_confirm=False)
elif action_type in require:
return self._approve(action_type, action_detail, needs_confirm=True)
else:
return self._reject(f"未知操作类型 '{action_type}'", action_type, action_detail)
def _approve(self, action_type, action_detail, needs_confirm):
self._log(action_type, action_detail, "approved", needs_confirm)
return {
"approved": True,
"reason": "策略允许",
"needs_user_confirm": needs_confirm,
}
def _reject(self, reason, action_type, action_detail):
self._log(action_type, action_detail, "rejected", False)
return {"approved": False, "reason": reason, "needs_user_confirm": False}
def _log(self, action_type, action_detail, status, needs_confirm):
entry = {
"timestamp": datetime.utcnow().isoformat(),
"action_type": action_type,
"action_detail": action_detail,
"status": status,
"needs_user_confirm": needs_confirm,
}
with open(self.log_path, "a") as f:
f.write(json.dumps(entry, ensure_ascii=False) + "\n")
# 使用示例
if __name__ == "__main__":
engine = AgentPolicyEngine()
# 低风险操作:自动放行
result = engine.check_permission("file_read", "/workspace/src/main.py")
print(result) # approved=True, needs_user_confirm=False
# 安全命令:自动放行
result = engine.check_permission("shell_safe", "git status")
print(result) # approved=True, needs_user_confirm=False
# 高风险操作:需要用户确认
result = engine.check_permission("file_write", "/workspace/src/main.py")
print(result) # approved=True, needs_user_confirm=True
# 非白名单命令:拒绝
result = engine.check_permission("shell_safe", "rm -rf /workspace")
print(result) # approved=False
第三步:启动沙箱容器
# 构建沙箱镜像(基于最小化基础镜像)
docker build -t agent-sandbox:latest -f Dockerfile.sandbox .
# Dockerfile.sandbox 内容:
# FROM python:3.12-slim
# RUN apt-get update && apt-get install -y git --no-install-recommends \
# && rm -rf /var/lib/apt/lists/*
# WORKDIR /workspace
# COPY policy_engine.py /opt/policy_engine.py
# 启动沙箱容器:断网、只读根文件系统、只挂载工作目录
docker run -d \
--name agent-sandbox-01 \
--network none \
--read-only \
--tmpfs /tmp:size=100m \
--tmpfs /run:size=10m \
-v ./workspace:/workspace \
--cap-drop ALL \
agent-sandbox:latest \
sleep infinity
# 在沙箱内执行 Agent 操作(通过 docker exec)
docker exec agent-sandbox-01 python /opt/policy_engine.py
运行前需要准备:agent_policy.yaml 和 policy_engine.py 放在同一目录,./workspace 目录作为 Agent 的工作空间。修改 SAFE_COMMANDS 白名单和策略配置即可适配不同场景。
落地时的取舍清单
把 Anthropic 的三层防线思路用到自己的 Agent 系统里,需要做几个关键取舍:
| 决策点 | 保守选择 | 激进选择 | 建议 |
|---|---|---|---|
| 网络隔离 | 完全断网 | 按域名白名单放行 | 消费端断网,开发端白名单 |
| 文件系统 | 只读挂载 | 可写但审计 | 开发场景可写,必须配审计日志 |
| 操作审批 | 全部人工确认 | 低风险自动放行 | 分级审批,白名单命令自动放行 |
| 多租户 | 完全独立容器 | 共享容器+进程隔离 | 企业场景用独立容器,不要省这个成本 |
| 模型层防护 | 只靠环境隔离 | 环境+模型双重约束 | 环境优先,模型层兜底,不要反过来 |
最后一点最容易犯错:不要把模型层安全提示当成主要防线。 prompt injection 的攻击面远大于你的防御提示长度。环境层隔离是硬墙,模型层防护是软垫——硬墙挡不住的时候软垫才有意义,但软垫不能替代硬墙。
Anthropic 这篇文章的价值不在于某个具体技术细节,而在于它清晰展示了同一个模型在不同产品中如何用不同强度的环境隔离来适配不同风险等级。如果你的 Agent 系统也在从"单场景"走向"多场景",这个分层思路值得直接借鉴。