隆重推出 Beacon：面向 AI Agents 的端点遥测技术

第一代 AI 安全以模型网关为中心。下一代将转向端点——也就是 Agent 实际执行工作的地方。

当 AI 系统主要用于回答问题的时候，网关是合理的。安全团队可以在用户和模型之间设置一个控制点，检查提示词和输出，执行 DLP（数据防泄漏），管理模型访问，并记录交互过程。

Agent 迫使这种架构进化。安全问题不再只是模型说了什么或看到了什么，而是 Agent 能做什么：使用用户的工具、继承用户的权限、在敏感环境中改变状态。

最典型的例子是开发者机器。像 Claude Code、Codex 和 Cursor 这样的编码 Agent 与源代码、终端、包管理器、云 CLI、本地凭证以及接近生产环境的系统一起运行。一个简单的自然语言请求可能演变成文件读取、Shell 命令、依赖变更、凭据操作和代码修改。

同样的模式现在正从开发者扩展到知识工作者。连接桌面的 Agent 开始跨 SaaS 应用、本地工具和内部系统运行。像 Claude Cowork 和 OpenClaw 这样的 Agent 工作区指向了企业 AI 的下一个阶段：用户的笔记本电脑成为跨企业应用执行委托工作的运行时。

今天面临的严峻现实是，安全团队可能只有在 Agent 执行了命令、修改了文件、安装了依赖或泄露了数据之后，才能看到爆炸半径。失败模式已经非常严重：通过 Claude Code 项目配置实现远程代码执行，通过 Copilot Chat 提示注入导致私有代码泄露，以及通过恶意 npm 包将本地编码 Agent 变成攻击路径的凭据窃取。

这就是 Beacon 旨在填补的端点可见性缺口。

Beacon 是 @asymptotelabs 为 AI Agent 提供的开源端点遥测层。这是我们让本地 Agent 活动变得可观察、可理解，并最终在整个企业中可管控的第一步。

这对安全团队意味着什么

对安全团队来说，这很重要，因为现有的技术栈并非为解释委托工作而设计。网关、EDR 和 Agent 原生遥测仍然重要，但每个都只看到 Agent 活动的一部分。要安全地管控 Agent，团队需要看到 Agent 如何在端点上从意图转化为行动。

三个缺口尤为突出：

1. 端点日志显示的是结果，而非工作流。它们可以捕获命令、文件更改和进程活动，但很少将这些事件与 Agent 请求、工具决策、审批路径或最终差异关联起来。
2. Agent 遥测需要一个通用层。像 Claude Code、Cursor、Codex 和 Claude Cowork 这样的 AI 编码 Agent 都暴露不同的遥测信号。安全团队需要跨这些 Agent 的统一端点级记录。
3. 可见性先于控制。团队在知道哪些 Agent 在运行、它们拥有什么权限、正在采取什么行动之前，无法强制执行配置、管控敏感操作、管理 MCP 访问或保护机密。

端点日志无法捕获 Agent 工作流

传统的端点遥测是必要的，但不足以理解 Agent 行为。

它可以显示命令运行了、文件更改了、进程产生了或连接打开了。但它通常无法显示事件背后的工作流：Agent 被要求做什么、它决定做什么、以及该行动对于任务是否合理。

同一个 Agent 行动可能因任务不同而安全或危险。例如：

• 在基础设施事件期间，kubectl 命令可能是合适的，但对于一个被要求更新单元测试的编码 Agent 来说就不合适。
• 在本地调试期间读取 .env 文件可能是预期的，但在编辑文档时却可疑。
• 在基础设施仓库中修改 Terraform 可能是正常的，但作为依赖更新的副作用引入则很危险。

在每种情况下，原始事件都不够。安全含义取决于其周围的工作流：提示词、计划、访问的上下文、调用的工具、接触的文件、使用的凭据以及授予的审批。

考虑一个被要求进行简单测试更改的编码 Agent：用户请求可能类似于：“更新计费重试逻辑的单元测试。”

传统遥测可能显示：

这些事件很有用，但它们与 Agent 工作流脱节。日志显示测试文件更改了、秘密文件被读取了、Terraform 被修改了、部署命令运行了。但它没有显示这些操作是否属于用户请求的一部分、是哪个工具决策产生的、或者用户是否批准了敏感步骤。

一个 Agent 感知的记录将这些相同的事件连接回工作流：

没有这个追踪，安全团队只能事后从低级工件中重建意图。他们可以看到 Agent 活动的结果，但无法判断 Agent 的行为是否适合它被要求做的工作。

Beacon：AI Agent 的端点遥测层

大多数安全和 IT 团队可以回答哪些模型被批准或哪些网关已部署。一旦 Agent 在本地运行，安全问题就移近端点：

Agent 清单：安装了哪些 Agent 工具？哪些用户和设备在运行它们？

运行时上下文：Agent 在哪些仓库和工作区中运行？它们可以继承哪些工具、凭据和本地权限？

Agent 活动：Agent 正在读取或修改哪些文件？它们生成了哪些命令、审批和差异？

遥测与审计：正在收集哪些遥测数据，发送到哪里？安全团队能否将原始用户请求与所采取的行动联系起来？

Agent 原生遥测有帮助，但它是碎片化的。Claude Code 和 Codex 可以导出 OpenTelemetry。Cursor 暴露了会话、提示词、工具使用、命令执行、审批、类似 MCP 的活动和文件编辑的钩子。Claude Cowork 可以通过管理员配置的 OTLP 端点导出遥测。

安全团队需要的是一个跨 Agent 的工作流记录：Agent 被要求做什么、它拥有什么上下文、调用了哪些工具、需要哪些审批、以及端点上发生了什么变化。

Beacon 通过在支持的地方配置 OpenTelemetry、在可用时收集本地信号、并将碎片化的 Agent 活动映射为通用端点事件格式来填补这一空白。

如图 1 所示，Beacon 连接了四个层次：

1. Agent 运行时：Claude Code、Codex、Cursor、Claude Cowork、OpenClaw 和本地模型生成提示词、计划、工具调用、审批、差异和运行时状态。
2. 端点活动：这些 Agent 与机器交互：文件、终端、包管理器、MCP 服务器、云 CLI、仓库、凭据和本地配置。
3. Beacon 标准化：Beacon 将碎片化的 OpenTelemetry、基于钩子的信号和端点信号转换为通用的 JSON 事件流，使安全团队能够跟踪从 Agent 请求到本地操作的链条。
4. 安全目的地：Beacon 目前写入兼容 Wazuh 的 JSONL。相同的标准化事件流可以扩展到企业已经使用的 SIEM、数据湖、可观测性平台、检测管道和端点工作流中。

有了 Beacon，提示词、工具调用、命令、文件编辑、审批、MCP 交互和运行时更改都成为同一个端点级记录的一部分：一个更清晰的从用户请求到本地操作的链条，跨 Agent 和工具。

可见性优先，控制随后

Agent 正在成为企业内部新的执行层。

它们读取文件、调用工具、使用凭据、修改系统，并以委托工作给它们的人的权限行事。仅靠模型网关无法理解或管控这些活动。

端点是 Agent 上下文、权限和行动汇聚的地方。在这里，提示词变成命令，工具继承权限，凭据被使用，更改被做出。

这使得端点遥测成为 Agent 安全的基础。

Beacon 使本地 Agent 活动在企业正在采用的工具中变得可观察。它为安全团队提供了一个通用记录，记录 Agent 被要求做什么、它们接触了什么、改变了什么、以及敏感操作是否被批准。

这一层必须是可信的。Beacon 是开源的，采用 MIT 许可证，因为它运行在接近开发者工作流、源代码、凭据和接近生产环境的系统附近。开发者应该能够检查收集了什么。安全团队应该能够验证遥测数据。IT 团队应该确切知道他们在部署什么。

Agent 活动应该在可管控之前先可观察。

Beacon 是我们实现这一目标的第一步。