Claude Code安全治理盲区：Anthropic新增Compliance API端点补上关键一课

Claude Code 会读取文件、运行 shell 命令、调用 MCP 工具，并借助开发者机器上可用的凭据执行操作。Anthropic 新推出的合规性 API 端点让安全团队得以空前清晰地洞察这些活动。但这些端点也暴露了一个更大的问题：仅凭活动日志，无法判断某个 Agent 的访问行为是否合法。

AI 的战场已经从浏览器标签页转移到了端点。Claude Code 这类执行框架（harness）正是其中的典型代表。它们运行在开发者的机器上，在本地执行 bash 命令，并通过 MCP 服务器、skills 和插件连接第三方服务。这一切的目的是让用户把繁重的劳动交给机器，自己专注于设计、思考和创造。

本地 Agent 并非小众品类。Token Security 在客户环境中发现的 AI Agent 中，本地 Agent 占比高达 68.6%，而且它们往往会继承员工自身的凭据、网络位置和权限。

这种向端点的转移对安全带来了深远影响。在 Claude Code 的使用场景中，没有一个集中式控制台可以跨本地配置、身份与访问、运行时等多个维度来监控端点 Agent。在 2026 年 8 月之前，Anthropic 的原生管控能力对这些 Agent 的实际行为几乎无从感知，团队不得不借助第三方扩展，才能勉强实现最基础的治理。随着 Anthropic 合规性 API 新增本地会话记录端点，现在可以更好地治理本地 Agent，同时也需要清楚了解其中仍然存在的局限。

执行框架不是聊天机器人

执行框架（harness）是一个复杂的编排器。它接收用户输入，连同完整的会话上下文一起发送给大语言模型（LLM）。LLM 本身并不维护状态；它从执行框架那里获得响应所需的全部信息，以即兴方式给出回答。真正负责运行命令、向第三方认证、连接 MCP 服务器的组件是执行框架，而不是 LLM。

我们可以把端点 Agent 比作人体。LLM 是大脑：负责处理数据并做出决策。其余的一切都是执行框架——从双手、双腿到感官器官。这是一种奇特的混合体，我们的安全模型必须随之调整适应。大脑运行在 Anthropic 的云端，但双手却运行在你的端点上，而那里正是可见性与控制力必须立足的地方。

非正统的设计

如今流行说 SaaS 已死，这话多少有些令人伤感，因为经典 SaaS 模式曾替我们处理了很多事情。我们期望一项服务能够让我们从中央仪表板管理和监控整个企业、控制组织策略，并清楚地看到企业中各个 Agent 能做什么。

但本地执行框架并非如此。Claude Code 打破了经典的共同责任模型，把更多负担压在了管理员身上。在 Token 委托云安全联盟（CSA）开展的一项覆盖 418 名 IT 与安全专业人士的调查中，68% 的受访者认为自己对 AI Agent 的可见性处于较高水平。然而在同一项调查中，82% 的受访者在过去一年里发现过安全、IT 或治理团队此前完全不知道其存在的 Agent。

猜个谜语：我以 Agent 的身份寄居在你的主机上，但早在任何 LLM 出现之前，我就已经在那里了。我对你的 Claude Code 的了解，比 Anthropic 还要深——因为端点就是我的地盘。

由于 Claude Code 的大部分执行过程发生在本地，端点遥测能够揭示云服务无法看到的信息：进程、文件和配置。但 EDR 提供的只是证据，不是治理模型。它无法将 Agent 的活动与其所有者、意图、凭据和权限关联起来。

Anthropic 自身的工具确实有所帮助，但还不足以阻止 LLM 执行破坏性操作——即便这些操作可能是合法的。要有效治理本地 AI Agent，需要从三个关键层面收集数据。你需要理解 Anthropic 能给你什么，什么只有端点 Agent 才能收集到，以及你需要对这些数据做什么。

第一层：托管设置——策略基线

Anthropic 的执行机制是托管设置（managed settings）。每台安装了 Claude Code 的端点都有一条托管设置记录：在 Mac 和 Linux 上是 JSON 文件，在 Windows 上是注册表项。它的规则优先于全局设置、项目设置和用户设置，让你能够在组织内的每一次 Claude Code 会话中强制执行一套基线策略。使用 Claude Code 企业版计划时，你可以通过图形界面应用策略；如果没有企业版，则可以通过 MDM 在各端点上写入托管设置记录。

可用的规则覆盖面相当广：

• 针对特定 MCP 服务器的允许和拒绝列表
• 基于 bash 命令的正则表达式匹配
• 禁止 skills 执行命令

这些规则确有帮助，但它们极大地压缩了开发人员的操作空间，而且静态的允许/拒绝策略原本就不是为现代 AI 的节奏而设计的。更糟糕的是，它们不了解上下文和意图。实际上，它们就像河中央的一块巨石，扰乱了水流，却无法阻断河流。

第二层：Compliance API

直到不久前，Anthropic 的合规性 API 还主要覆盖 claude.ai 上的操作，也就是来自 Web 界面和 Claude Desktop 的活动，对 Claude Code 的覆盖非常有限。2026 年 8 月 11 日，Anthropic 为本地会话引入了新的端点：

端点	返回内容
GET /v1/compliance/apps/sessions/local	会话元数据列表
GET /v1/compliance/apps/sessions/local/{session_id}	单个会话的元数据
GET /v1/compliance/apps/sessions/local/{session_id}/messages	会话记录（transcript）

这些端点基于 Agent 与 Anthropic 模型的交互，为你提供端点上运行的 Agent 的可见性。凡是传达给模型的内容，都会以三种块类型记录下来：text、tool_use 和 tool_result。它们共同覆盖了用户提示、bash 命令、读写操作，甚至 MCP 命令。

模型在服务端不保存任何状态。skill 和插件的 .md 文件只存在于端点上，因此执行框架在每一轮交互中都会把完整上下文重新发送给模型。任何到达模型的内容都会到达 Compliance API——这对于治理和监控来说相当了不起。

只要解析得当，会话记录就能让你记录工具使用情况，并建立一份 Agent 清单：每个 Agent 使用了哪些 skills、哪些 MCP 服务器，以及哪些插件。

合规性 API 还覆盖管理操作，但主要集中在组织层面，对单个用户修改配置的情况覆盖较少。预计这一覆盖范围会随着时间的推移逐步扩大。

为什么你可能仍然需要 OpenTelemetry

OpenTelemetry（简称 OTel）是一个面向链路追踪、指标和事件日志的开源标准，所有常见的执行框架都内置了它，只需进行配置即可启用。

端点上有些操作永远不会到达 LLM，因此合规性 API 也永远看不到它们。钩子（hooks）就是最典型的例子：它们在本地运行，介于模型决策和工具实际执行之间，可以阻止某个工具的执行或某条提示的发送。

OTel 还能记录工具权限决策以及决策者——无论是策略、钩子还是用户放行的。此外，权限模式切换为 bypassPermissions / auto 模式的操作会记录在 OTel 中，而不会进入合规性 API。

会话记录 vs 日志

OTel 的定位是记录原子级操作。会话记录是冗长且深度描述性的 JSON，没有冗余度调节选项，你必须对它们进行处理才能获得与日志等效的结果。如果你不想收集和存储极其密集的会话记录，OTel 可能是更容易上手的工具（在更好的工具出现之前）。

还有一个硬性边界：如果你让 Claude Code 使用非 Anthropic 的模型运行，就完全无法获得合规性 API 的覆盖，因为它只记录与 Anthropic 模型的交互。运行在 Bedrock、Foundry 或 Google Cloud 上的会话将不在覆盖范围内。

需要特别注意的是：本地会话记录可能包含敏感数据，包括 PII、密钥和客户数据。它们的存储本身就成为一个敏感数据源。请务必以对待敏感数据源的方式来对待它。

第三层：只有端点才能告诉你的信息

合规性 API 和 OTel 捕获的是 Agent“做了什么”。两者都无法看到磁盘上存了什么：配置文件、已安装的 skills 和插件及其 .md 文件（除非它们在会话中被使用过）、以及会话之外启动的进程。这正是端点 Agent 大显身手的地方。采集配置文件、获取 skill 和插件的 .md 文件，并与 EDR 日志关联，以捕获来自 Agent 的高风险 bash 命令。Token Security 发现，每个本地 Agent 平均拥有超过 10 个配置文件，散落在端点的各个角落。

磁盘上还存着一样东西，你也可以从合规性 API 中获取：会话记录。Claude Code 默认在本地保存所有会话历史 30 天，以便用户可以快速恢复之前的工作。能够访问端点的恶意攻击者同样可以读取这些文件，因此同样需要谨慎对待。

在制定覆盖计划时，别忘了会话记录。从负责任的使用开始：防止用户在会话中直接写入明文密钥；对包含客户数据或敏感数据的项目和会话进行标记，并按计划删除。然后加入检测与响应能力：找出包含明文密钥的用户提示，并对可能危及客户数据的会话采取行动。

关于解析会话记录的一些细节

要从 Claude Code 会话中获取原子级操作日志，你需要处理合规性 API 的会话记录。如上文所述，每条消息只有三种类型：text、tool_use 或 tool_result，并包裹在 user、assistant（LLM 的响应）等字段中。要找到实际的插件、skills 和 MCP 服务器，还需要一些额外的技巧。

Bash 命令

最简单的场景：每条命令都会以 tool_use 的形式出现，其 "name" 为 "Bash"，完整的命令行内容存放在 input 值中。

MCP 服务器

它们以 tool_use 的形式出现，名称为 mcp__<server>__<tool>。第一方服务器使用可读的名称，因此你通常一眼就能看出类型：Jira、Slack、Notion。用户自行连接的服务器则显示为 UUID，你需要通过命令后缀（如 slack_send_message）或自己维护的 UUID 到名称映射表来还原服务。

每一个这样的条目都代表着该端点上的一个长期凭据，而其中大约三分之一来自供应商生态系统之外：Token Security 发现的 MCP 服务器中，35.1% 是社区构建的或来源不明的。

Skills

skills 不像 MCP 命令那样有专门的字段来标识名称，但你可以推断出来。当一个 skill 被触发时，LLM 必须依赖上下文才能使用它，因此执行框架会通过 API 发送 SKILL.md——要么直接注入 skill 内容，要么对其路径发起一次 Read 操作。这次 Read 就会暴露 skill 的名称和位置：tool_use 的 input 中包含路径，tool_result 的 text 中包含 skill 的内容。

插件

插件更难处理，因为一个插件并非单一文件。它打包了多种扩展类型，包括 skills 和脚本。当一个插件的脚本或 .md 文件被 Read 进上下文时，你可以通过路径约定还原插件名称。

以上所有方法都不需要触及用户提示，仅凭 tool_use 块和命令行即可完成。

托管设置 + 本地会话记录 + 端点采集

Claude Code 的设计带来了单靠任何一层都无法解决的挑战。三者结合效果更好，但仍然力有不逮：

即使三者兼备也仍然不够。它们都无法捕获企业层面的上下文，而且在将访问与意图关联起来方面也不够深入。管理员审阅会话记录时，无法区分一个从互联网上拉取的恶意插件和一个工程师自己编写的合法插件。

要弥合这一差距，需要来自组织其他环节的上下文——例如，把端点上运行的 skills 和插件与你内部代码仓库实际管理的清单进行比对，从而提升其可信度。一旦你拥有跨组织的上下文，发现单个恶意 skill 就能生成一张它运行位置的热力图，响应速度将大大加快。

遥测只能告诉你发生了什么。治理则需要将这些信号与 Agent 的所有者、目的、身份、凭据、权限和访问路径关联起来。有了这些上下文，才有可能判断访问是否合理、将其收敛到最小权限、并在 Agent 使命结束时及时撤销权限。身份是控制平面，它把端点和会话数据转化为可执行的 AI Agent 安全策略。

---

参考来源：

Securing Claude Code: The New Compliance API, Local Visibility, and Identity Governance
https://thehackernews.com/2026/08/securing-claude-code-new-compliance-api.html

云栈社区持续关注 AI 安全治理与 Agent 基础设施领域的最新进展，欢迎在论坛中分享你的端点治理实践与疑问。