企业部署 Claude 的三项关键边界

把 Claude 接进企业，最容易出现的错觉是：区域选好了，保留期限填了，危险工具禁了，安全就有了。作者的结论是，真正决定风险的只有三件事：推理在哪里运行、数据实际留多久，以及 Agent 能碰到哪些资源。

这篇文章值得读的地方，是把采购表里的配置项拆成了实际能力边界。不过，文中的区域、型号和监管状态都属于容易变化的信息。下面按原文解释其思路，具体产品参数应视为作者提供的待核验信息，不能直接当上线依据。

禁了 WebFetch，为什么还拦不住联网

作者开头给出了一段看起来很严格的 Claude Code 配置：

{
  "permissions": {
    "deny": ["WebFetch"],
    "allow": ["Bash"]
  }
}

它解决的是工具调用入口的限制：不允许调用 WebFetch，允许调用 Bash。要盯住的是 allow 那一行，因为 Agent 仍然可能通过 Bash 执行 curl。

禁掉一个 HTTP 工具，并不等于禁掉网络访问。只要命令执行环境具备相应权限，Agent 仍有机会上传仓库内容、下载文件，或者调用其他程序访问网络。

工具黑名单限制的是调用名称，沙箱限制的才是实际能力。

作者由此把讨论重点转向运行时。提示注入（prompt injection）的危险，在于 Agent 可能把读到的数据当成指令。工单里的文字、外部文档里的内容，都可能影响下一步操作；当它同时持有真实凭证和工具权限时，错误就会变成实际动作。

作者援引 OWASP Top 10 for LLM Applications 中提示注入排名第一的情况，强调这不是等待一次补丁就能解决的问题。模型抗注入能力提升有价值，但团队无法把它当作自己可审计、可配置的权限控制。

团队能直接掌握的措施包括：隔离文件系统和网络；逐个批准工具与连接器；为每个 Agent 分配独立身份；准备并测试紧急停止开关；针对实际工具组合测试注入、工具滥用和提权。只让 Agent 读取一个仓库，与给它整个工作区的 token，是两种完全不同的风险。

数据驻留要约束路由，不能只看区域名称

原文称，Anthropic 第一方 API 的推理地域只有 global 和 us，没有 EU 或 UK 选项。作者用下面的代码展示如何指定和检查推理地域：

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    inference_geo="us",
    messages=[{"role": "user", "content": "..."}],
)
print(response.usage.inference_geo)  # "us"

它解决的是单次请求的地域选择与结果检查。关键是 inference_geo="us" 和返回的 response.usage.inference_geo。其中 claude-opus-5-5 是原文给出的模型名，原文没有提供可验证的型号依据，不宜直接复制运行。

按作者的描述，Claude 4.6 及以后版本的 US-only 推理，在输入、输出、缓存写入和缓存读取上都按标准价格的 1.1 倍计费。工作区地域又是另一项设置：原文称其目前仅支持美国，创建后不能迁移，需要另建工作区。

这里要分清两个问题：工作区放在哪里，以及请求实际在哪里计算。

如果数据保护影响评估（DPIA）要求必须在英国处理，作者建议考察云服务商渠道。原文列出的情况是：Amazon Bedrock 有伦敦区域 eu-west-2，Microsoft Foundry 提供 US Data Zone、Europe 尚在计划中，Google Vertex AI 则需要另查自身的区域支持。

但区域存在，不代表指定模型一定在当地完成推理。作者提醒，Bedrock 的欧洲地理配置不等于英国限定配置；伦敦可用的模型，也可能通过地理或全球配置路由。应核查具体模型 ID 的实时模型卡，而非只看区域介绍页。

多模型、多供应商场景下，作者主张用 AI gateway 集中执行地域、脱敏和日志策略。理由很直接：如果这些约束散落在每个持有 API key 的服务里，就容易出现漏配。

「保留 30 天」为什么不是完整答案

原文给出的 API 输入、输出删除周期是 30 天，但同时指出，被安全分类器标记的内容可能因信任与安全审查保留数年。文章没有交代更精确的期限和触发条件，因此不能把这个例外写成统一承诺。

对处理敏感类别数据的业务，作者认为数据保护官（DPO）需要知道的正是这些例外，而不只是默认周期。

零数据保留（ZDR）同样有适用范围。原文明确列出 Batch processing 和 Files API 属于排除项。如果系统的合规方案依赖 ZDR，就要沿着实际调用路径逐项检查，不能因为账号获得某种安排，就默认所有功能都覆盖。

日志还有另一条时间线：作者称，企业审计日志通过 Compliance API 获取，窗口为 180 天。他建议定期导出到安全信息与事件管理系统（SIEM），因为平台窗口未必满足企业自己的事件留存要求。

日志告警也不能只盯登录。账号正常登录之后，Agent 调用了什么工具、访问了哪些资源，同样需要关注。

我的判断

我赞同作者把控制落在 API 调用方这一侧。尤其是 Bash 的例子，很适合用来检查团队现有方案：配置是否限制了真正的能力，还是只限制了一个入口。

但文章没有给出实测攻击记录、整改前后对照数据，也没有证明加上 AI gateway 后就能满足某种合规要求。它是一套有针对性的工程检查思路，不能当作效果已经得到验证的部署方案。集中网关能减少重复配置，其自身如何鉴权、限制绕过、控制日志内容，仍需另行设计。

监管部分更要保留边界。作者引用了 2026 年 8 月发布的 NCSC 临时 Agentic AI 指南，称其建议沙箱、独立身份、日志采集和紧急关闭，同时明确它不具法定约束力。文中还提到自愿性的 DSIT AI Cyber Security Code of Practice、分阶段生效的 Data (Use and Access) Act 2025、仍在制定的 ICO 相关守则，以及 FCA、PRA 对既有原则的应用。这些都是原文陈述，此处没有独立核验，不能据此作法律结论。

对国内团队，可迁移的是拆解方法。英国区域要求和监管判断，不能直接套到国内项目；相同的是，采购说明无法替代真实的数据路径、权限边界和操作证据。

能拿来做什么

• 给 Claude Code 梳理一遍实际能力：允许 Bash 时，同时检查文件系统、网络和凭证访问范围，并配合 managed settings、沙箱、deny rules 与 MCP allowlist 收紧边界。
• 在 Node 服务接入多个模型或供应商时，把地域要求、脱敏和日志规则集中管理，并核对每个模型 ID 的路由条件，避免只凭区域名称做判断。
• 在试点前画清数据流，逐项确认普通请求、Batch processing、Files API 的保留规则及 ZDR 覆盖范围，再安排 DPIA 和传输风险评估。
• 上线前配置 SSO、SCIM、基于角色的访问控制、自定义保留期限和 IP allowlisting，逐个审批连接器，并用真实工具配置测试注入、日志导出和紧急停止。