Claude Code会读取文件、运行Shell命令、调用MCP工具,并使用开发者设备上的凭证执行操作。Anthropic新推出的合规API端点让安全团队首次能最清晰地查看这些活动,但也暴露了一个更大的问题:仅靠活动日志无法判断代理的访问是否合法。
AI已从浏览器标签页迁移到Claude Code等工具所运行的端点。这些工具部署在开发者设备上,本地执行Bash命令,并通过MCP服务器、技能和插件连接第三方。所有这些都是为了让用户将工作外包给机器,专注于设计、思考和创作。
本地代理并非小众类别,它们占客户环境中AI代理总数的68.6% Token Security discovers,且通常会继承员工的凭证、网络位置和权限。
向端点的转移对安全产生了重大影响。对于Claude Code,没有集中式控制台来监控跨本地配置、身份与访问以及运行时的端点代理。在2026年8月之前,Anthropic的原生控件对这些代理的实际操作可见性有限,迫使团队使用第三方扩展才能实现最基础的治理。
借助Anthropic合规API中新的本地会话记录端点,你可以更好地治理本地代理,同时了解仍存在哪些局限性。
工具并非聊天机器人
工具是复杂的编排器,它接收用户输入并将其与完整会话上下文一起发送给大语言模型(LLM)。LLM本身不维护状态,它从工具处获取响应所需的所有信息,以临时方式生成回复。实际执行命令、向第三方认证以及连接MCP服务器的组件是工具,而非LLM。
将端点代理比作人体:LLM是大脑,负责处理数据并下达指令;其他所有部分都是工具,从手脚到感官器官。这是一种奇特的混合体,我们的安全模型必须调整以适配它。大脑运行在Anthropic的云端,但手脚运行在你的端点上,这正是你需要具备可见性和控制权的地方。
非传统设计
如今常说SaaS已死,这有点像SaaD(SaaS死亡),因为传统SaaS为我们处理了很多事情。我们期望服务能让我们从集中式仪表板管理和监控企业,控制组织策略,并清晰查看企业内代理可执行的操作。
本地工具并非如此。Claude Code挑战了传统的共享责任模型,将更多负担放在管理员身上。在Token委托Cloud Security Alliance开展的 调查 中,共有418名IT及安全专业人员参与,其中68%的人表示他们对AI代理的可见性很高。在同一项调查中,82%的人在过去一年中发现了一个安全、IT或治理部门未知的代理。
想想这个:我作为代理驻留在你的主机上,但我早在任何LLM出现之前就已存在。我比Anthropic更了解你的Claude Code,因为端点是我的领域。
由于Claude Code的大部分执行发生在本地,端点遥测可以揭示云服务无法看到的进程、文件和配置。但EDR提供的是证据,而非治理模型,它无法将代理的活动与其所有者、意图、凭证和权限关联起来。
Anthropic自己的工具有所帮助,但不足以防止LLM执行破坏性操作,即使这些操作可能是合法的。要有效治理本地AI代理,需要三层关键数据收集:你需要了解Anthropic提供了什么、只有端点代理能收集什么,以及你需要如何处理这些数据。
第1层:托管设置,策略基线
Anthropic的执行机制是托管设置。每个安装了Claude Code的端点都有一个托管设置记录:Mac和Linux上是JSON文件,Windows上是注册表项。其规则优先于全局、项目和用户设置,允许你在组织内的每个Claude Code会话上强制执行基线。对于Claude Code企业版,你可通过GUI应用策略;若没有企业版,你的MDM可跨端点写入托管设置记录。
可用规则涵盖很多方面:
-
特定MCP服务器的允许和拒绝列表
-
Bash命令的正则表达式
-
禁用技能运行命令等功能
这些规则有帮助,但它们剥夺了开发者大量操作空间,且静态允许/拒绝策略不适应现代AI的发展速度。更糟糕的是,它们不了解上下文或意图。实际上,它们就像河流中间的一块巨石,扰乱了水流但无法阻止它。
第2层:合规API
直到最近,Anthropic的合规API主要覆盖claude.ai的操作,即来自网页界面和Claude桌面的活动,对Claude Code的覆盖非常有限。在11年2026月,Anthropic推出了本地会话的新端点:
| 端点 | 返回内容 |
|---|---|
| GET /v1/compliance/apps/sessions/local | 会话元数据列表 |
| GET /v1/compliance/apps/sessions/local/{session_id} | 单个会话的元数据 |
| GET /v1/compliance/apps/sessions/local/{session_id}/messages | 会话记录 |
这些让你能基于代理与Anthropic模型的交互,查看运行在端点上的代理。发送给模型的所有内容都记录在三种类型的块中:文本、tool_use和tool_result。它们共同覆盖用户提示、Bash命令、读写操作,甚至MCP命令。
模型在服务器端不维护状态。技能和插件的.md文件仅存在于端点上,因此工具会在每一轮将完整上下文重新发送给模型。任何到达模型的内容都会被记录到合规API中,这对治理和监控来说非常棒。
如果解析得当,会话记录可让你记录工具使用情况并构建代理清单:每个代理的技能、使用的MCP服务器及其插件。
合规API还覆盖管理操作,主要在组织级别,对单个用户更改配置的覆盖较少。我预计这一覆盖范围会随时间扩大。
为什么你可能仍需要OpenTelemetry
OpenTelemetry(或OTel)是用于跟踪、指标和事件日志的开源标准,每个常见工具都内置了它,只需配置即可。
端点上的某些操作永远不会到达LLM,因此合规API永远看不到它们。钩子是最明显的例子:它们在本地运行,介于模型决策和工具实际运行之间,可阻止工具执行或提示发送。
OTel还记录工具权限决策及其决策者,无论是策略、钩子还是用户批准。此外,权限变更进入bypassPermissions/auto模式后,会记录在OTel中,但不会记录在合规API中。
会话记录与日志的区别
OTel专为记录原子操作而构建。会话记录是冗长、描述性极强的JSON,没有详细程度调节,你必须处理它们才能获得相同的日志效果。如果你不想收集和存储极密集的会话记录,OTel可能是更简单的工具(直到更好的工具出现)。
还有一个明确的界限:如果你在非Anthropic的模型上运行Claude Code,你将完全没有合规API覆盖,因为它仅记录与Anthropic模型的交互。在Bedrock、Foundry或Google Cloud上运行的会话不会被覆盖。
一个重要说明:本地会话记录可能包含敏感数据,包括个人身份信息(PII)、机密和客户数据。它们的存储本身就成为敏感数据源,需像对待敏感数据一样处理。
第3层:只有端点能告诉你的信息
合规API和OTel捕获代理的操作,都无法看到磁盘上的内容:配置文件、已安装的技能和插件及其.md文件(除非在会话中使用过),或在会话外启动的进程。这正是端点代理发挥作用的地方。收集配置文件、检索技能和插件的.md文件,并关联EDR日志以捕获代理发出的风险Bash命令。Token Security finds 平均每个本地代理发现超过10个配置文件,分散在端点各处。
还有一个存储在磁盘上的信息,你也可以从合规API中获取:会话记录。Claude Code默认在本地存储所有会话历史30天,以便用户快速恢复之前的工作。获得端点访问权限的恶意行为者也可以读取这些文件,因此需采取同样的谨慎措施。
在构建覆盖计划时不要忘记会话记录。从负责任的使用开始:防止用户在会话中写入原始机密,标记包含客户或敏感数据的项目和会话,并按计划删除它们。然后添加检测和响应:查找包含明文机密的用户提示,并对可能泄露客户数据的会话采取行动。
关于解析会话记录的一点说明
要从Claude Code会话中获取原子操作日志,你需要处理合规API的会话记录。如上所述,每条消息仅为文本、tool_use或tool_result,包裹在user、assistant(LLM的响应)等字段中。查找实际的插件、技能和MCP服务器需要一些额外的技术。
Bash命令
简单情况:每个命令都会作为tool_use出现,其名称为"Bash",完整命令行位于input值中。
MCP服务器
这些会以tool_use形式出现,其名称为mcp__<server>__<command>。第一方服务器使用可读名称,因此你通常可以一眼看出类型:Jira、Slack、Notion。用户连接的服务器会显示为UUID,你可以从命令后缀(slack_send_message)或维护的UUID到名称的映射中恢复服务。
每一个都代表该端点上的固定凭证,约三分之一来自供应商生态系统之外:Token Security发现的MCP服务器中,35.1%是社区构建或来源不明的。
技能
技能不像MCP命令那样在字段中命名,但你可以推断它们。当技能触发时,LLM无法在没有上下文的情况下使用它,因此工具会通过API发送SKILL.md,要么直接注入技能内容,要么通过读取其路径。该读取操作会暴露技能名称及其位置:tool_use输入包含路径,tool_result文本包含技能内容。
插件
插件更难,因为插件不是单个文件。它捆绑了不同的扩展类型,包括技能和脚本。当插件的某个脚本或.md文件被读取到上下文中时,你可以通过路径约定恢复插件名称。
所有这些都无需接触用户提示,仅通过tool_use块和命令行即可完成。
托管设置 + 本地会话记录 + 端点收集 = 良好但不足
Claude Code的设计带来了单一图层无法解决的挑战。三者结合效果更好,但仍有不足:
| 图层 | 主要作用 | 遗漏内容 |
|---|---|---|
| 托管设置 | 强制执行静态策略基线 | 动态执行上下文 |
| 会话记录 | 保留每个会话的操作记录,按需检索 | 离线本地配置 |
| 端点/EDR | 收集静态配置并记录本地进程 | LLM特定的语义上下文 |
即使三者结合也不够,因为它们都无法捕获你的企业上下文,也无法深入将访问与意图关联起来。审查会话记录的管理员无法区分从互联网下载的恶意插件和工程师编写的合法插件。缩小这一差距需要来自组织其他部门的上下文,例如将端点上运行的技能和插件与内部仓库实际管理的技能和插件关联,这会提高合法性。一旦你拥有了整个组织的上下文,检测到单个恶意技能就会为你提供其运行位置的热力图,缓解措施可快速实施。
遥测可以显示发生了什么。治理需要将这些信号与代理的所有者、目的、身份、凭证、权限和访问路径关联起来。这种上下文使得确定访问是否合理、将权限调整为最小特权并在代理目的结束时撤销权限成为可能。身份是将端点和会话数据转化为可执行AI代理安全的控制平面。
了解Token如何在端点、云、SaaS和开发者环境中保护AI代理 with a quick demo,随时可查看。
注: 本文由安全研究员Dan Abramov专业撰写并贡献。

