被反复确认的 AI Agent 行为审计痛点 过去一年,企业内部把 Coding Agent 推到生产环境时,几乎都会撞上同一类工程痛点——Agent 在沙箱里、网络代理后、文件读写隔离层的背后,实际做了什么事,企业治理侧看不清楚。这条痛点不是个别问题,是 Coding Agent 这种工作负载的本质特征——Agent 自主调用、自主执行、自主组合工具——和传统软件"用户做了什么操作"的审计范式叠

被反复确认的 AI Agent 行为审计痛点

过去一年,企业内部把 Coding Agent 推到生产环境时,几乎都会撞上同一类工程痛点——Agent 在沙箱里、网络代理后、文件读写隔离层的背后,实际做了什么事,企业治理侧看不清楚。这条痛点不是个别问题,是 Coding Agent 这种工作负载的本质特征——Agent 自主调用、自主执行、自主组合工具——和传统软件"用户做了什么操作"的审计范式叠加后的必然结果。传统软件审计假设"应用层调用可见",Coding Agent 工作负载的很多关键行为发生在进程级、文件级、网络协议级,应用层审计完全看不见。

两份独立工程实践在同一时段给出了同一组工程结论——必须从 OS 层、应用层之外的更底层做可观测,而不是依赖 Agent 自身输出的日志。第一份是 2026 年 8 月公开的 AgentSight——一个在 eBPF 层做 AI Agent 行为可观测的工具,核心思路是用 eBPF 在内核层钩住 Agent 的关键操作,不需要修改 Agent 代码就能记录全部行为。第二份是 2026 年 3 月公开的 Agent Shield——一个 macOS 上的 OS 级后台守护进程,用 FSEvents、lsof、子进程树监控来观察 Claude Code、Cursor 等 Agent 的实际行为。两份独立实践共同指向同一组企业 Agent 行为审计的工程新基线。

为什么传统审计视角在 Coding Agent 上失效

2026 年 3 月公开的 Agent Shield 项目,作者在工程开篇明确指出了传统审计方法在 Coding Agent 上的具体失效点:"每一个我考察过的工具——CodeGate、Pipelock、还有 Sysdig 这周刚发布的——都坐在网络路径里,检查 API 调用。这种架构看不到文件读取、子进程派生、用 ping 进行的 DNS 外泄,也看不到 Agent 写入自己记忆目录的行为——SpAIware 的藏身之处。攻击面不在 API 层,在 OS 层。"

这段工程总结指出了传统 Coding Agent 审计的三个具体盲区。第一个盲区是文件读写——Agent 读 ~/.ssh/id_rsa、写 ~/.aws/credentials、改 ~/.claude/ 这些操作都发生在文件系统层,不通过任何 API 网关;网络代理看不到这些操作。第二个盲区是子进程派生——Agent 通过 Bash 工具调用 ping、curl、curl-pipe-bash 这些命令时,网络层看到的是合法的 ICMP / HTTPS 包,但实际语义是"DNS 协议里塞了凭据"或者"远端 shell 脚本下载执行",这是网络层代理无法解读的语义。第三个盲区是持久化植入——Agent 把恶意指令写入自己的记忆目录(~/.claude/、~/.cursor/ 等),所有未来的会话都会自动加载这些内容;这种攻击的注入点是文件,不是网络请求,网络代理完全看不见。

这三条盲区共同指向一个工程现实——任何把 Coding Agent 审计局限在 API 层或网络层的方案,在攻击者选择 OS 层攻击路径时都是无效的。企业治理侧必须把审计延伸到 OS 层,看到文件读写、子进程派生、内存映射这些低层操作,才能真正识别 Coding Agent 的越权行为。

AgentSight 的 eBPF 层可观测方案

AgentSight 是 2026 年 8 月底公开的一个项目,在 eBPF 层做 Coding Agent 行为可观测。eBPF 是 Linux 内核提供的安全可编程机制,允许用户空间程序在内核层钩住特定系统调用、网络事件、文件操作,而不需要修改内核源码或加载内核模块。AgentSight 利用 eBPF 在内核层钩住 Agent 进程的关键操作,把每次文件打开、读写、网络连接、子进程派生都记录下来,提供给 Agent 治理侧做行为审计。

AgentSight 的工程价值在于"无侵入"——它不需要修改 Agent 代码,不需要 Agent 主动调用任何 SDK,不需要把 Agent 跑在特殊的容器里。它直接挂在 OS 层,任何 Coding Agent(无论 Claude Code、Codex 还是其他)只要跑在 Linux 上,就能被 AgentSight 完整观测。这条"无侵入"特性对企业 Coding Agent 部署特别重要——企业里同时跑多家 Agent、多种工具版本、混合本地和云端工作负载,如果要求每家 Agent 都主动集成观测 SDK,几乎不可能落地;eBPF 层无侵入方案则绕开了集成难题,统一观测所有 Agent。

这条工程选择也回应了上一轮"沙箱分层"基线里提到的"函数级沙箱"的局限——pctx-py-sandbox 这类函数级沙箱在 Podman 容器里运行,容器内的行为可以被沙箱拦截,但容器外的行为(比如 Agent 调用其他工具、写入 ~/.claude/、派生新进程)需要更外层的观测。AgentSight 这类 OS 层可观测和沙箱层拦截形成互补,共同覆盖 Coding Agent 的所有行为面。

Agent Shield 的 OS 层行为追踪方案

Agent Shield 是 2026 年 3 月公开的项目,在 macOS 上做 Coding Agent 行为追踪。它用三种 macOS 系统能力组合工作——FSEvents 文件系统事件监控、lsof 文件描述符查询、子进程树轮询。这三种能力在 macOS 上对应 Agent 行为的关键维度:FSEvents 监控 Agent 对哪些路径做了读写、lsof 监控 Agent 打开了哪些网络连接、子进程树轮询监控 Agent 派生出了哪些进程。这套组合在 macOS 上能给出 Agent 行为的完整视图,而不需要修改 Agent 代码。

Agent Shield 的具体工程实现有几个值得专门讲的细节。第一,它把所有事件数据存到本地 SQLite 数据库,不上传任何数据——这意味着 Agent 行为的观测数据始终留在企业内部,不会泄漏给第三方。第二,它有一个关联引擎——当一个 Agent 在 1 分钟内"读了 ~/.aws/credentials"+"派生了一个连接到外网的 curl 子进程"+"向那个外网发了一个写请求",单独看每一步都不异常,关联起来就是凭据外泄模式。关联引擎用时间窗口聚合事件,识别这种多步骤攻击模式。第三,它和具体威胁情报绑定——CVE-2025-55284 这种已知漏洞的特征、SpAIware 这种持久化植入的特征、AgentHopper 这种跨仓库传播的特征,都被预先建模成检测规则,Agent 一旦产生匹配行为就立即告警。

这套设计的工程意义在于,它把"Agent 行为审计"从"看 Agent 输出什么"提升到了"看 Agent 在 OS 层做了什么"——后者是任何 Agent 偏离用户意图的工程真相来源。无论 Agent 输出了多好看的最终回复,如果它在底层读 ~/.ssh/、派生外部连接、写持久化植入,这条行为就构成安全事件。Agent Shield 的关联引擎让这类行为模式被实时识别,不是事后追溯。

从单点工具到企业 Agent 行为审计的工程新基线

把两份独立实践合并,可以画出企业 Agent 行为审计的工程新基线。这条基线由五条构成,缺一不可。

第一条,审计必须延伸到 OS 层。任何 Coding Agent 审计方案都不能停留在 API 层或网络层,必须包含文件读写、子进程派生、网络连接、内存映射等 OS 层行为的完整记录。这条规则对应 Agent Shield 作者明确指出的"攻击面不在 API 层,在 OS 层"的工程现实。这条规则要求企业内部必须部署 AgentSight、Agent Shield 这类 OS 层可观测工具,不能依赖厂商 SDK 提供的应用层审计日志。

第二条,审计必须无侵入且跨厂商。eBPF 这类无侵入机制是 Coding Agent 审计的工程基线,任何"必须修改 Agent 代码才能观测"的方案都不适合多 Agent 多厂商的企业环境。这条规则要求企业内部的可观测性必须能够同时观测 Claude Code、Codex、Cursor、自研 Agent 等不同厂商的 Coding Agent,而不需要每家单独适配。

第三条,审计必须支持跨事件关联。单步骤异常(读 ~/.aws/credentials、连接外网 IP、写本地文件)在 Coding Agent 工作负载里都是常见操作;真正的攻击模式是这些步骤的特定组合。审计必须有关联引擎,识别"读敏感路径 + 派生外部连接 + 写持久化位置"这类多步骤攻击。这条规则对应 AgentHopper 类跨边界传播攻击的现实威胁——没有关联引擎,这种攻击链会被每个独立步骤的"看起来正常"误导。

第四条,审计数据必须留在企业内部。任何 Agent 行为数据——文件读写记录、网络连接日志、思维链——都属于敏感信息,不能上传到第三方。这条规则对应企业内部合规要求——审计数据本身就是合规审计的输入,审计数据上传到第三方等于让第三方知道企业里发生了什么。这条规则要求 OS 层审计工具必须支持自部署、数据本地存储,不能依赖云端管理面板。

第五条,审计必须和已知威胁情报绑定。审计不是无差别记录所有行为——审计必须有针对性,识别已知攻击模式的特征。SpAIware、AgentHopper、CVE-2025-55284 这种已知威胁的检测规则必须预先建模,Agent 行为一旦匹配就立即告警。这条规则对应"攻击模式在演化,审计规则也必须演化"的工程现实——只记录不识别的审计,等同于不审计。

从 Coding Agent 行为审计推到所有企业 Agent

把视野拉宽到企业 Agent 全景,以上五条基线具有普遍意义。任何企业内部 Agent——不只是 Coding Agent,也包括销售 Agent(可能扫描 CRM 收集客户信息并发到外部)、客服 Agent(可能读取聊天记录导出敏感对话)、运维 Agent(可能在没有授权的情况下重启生产服务)——面对同样的 OS 层行为审计需求。Agent 的核心特征是"自主执行",自主执行就意味着 Agent 会调用操作系统能力,这些调用必须被审计。

企业 Agent 治理负责人现在应当把 Coding Agent 行为审计的工程新基线作为整个企业 Agent 工具链行为审计的样板工程。具体来说,"OS 层审计、无侵入跨厂商、跨事件关联、数据本地存储、威胁情报绑定"这五条规则应当通用化,覆盖企业内部所有 Agent 的所有 OS 层行为。每一条规则对应一个独立的工程组件——可以是 eBPF 探针、可以是 FSEvents 监控器、可以是事件关联引擎、可以是本地数据存储、可以是威胁情报订阅——实现形式各异但原则一致。

企业 Agent 治理负责人现在必须回答的三个问题

面对上述基线,企业 Agent 治理负责人现在至少要直接回答三个问题。第一个问题:你企业内部 Coding Agent 部署是否覆盖 OS 层行为审计?如果只依赖 Agent 厂商提供的应用层审计日志,任何 OS 层攻击路径(文件读写、子进程派生、记忆目录植入)都不可见。

第二个问题:你企业内部的多家 Agent(Claude Code、Codex、Cursor、自研)是否能被统一观测?如果每家 Agent 需要单独的适配,跨厂商关联攻击模式无法被识别。

第三个问题:你企业内部 Agent 行为审计的数据是否留在本地?如果审计数据上传到第三方,合规风险和数据泄漏风险都会增加。

结语

Agent 的能力边界在过去一年被显著推前,从"按 prompt 写代码"演化到"按 prompt 自主调用操作系统能力"。每推前一步,工程侧的审计基线就必须同步推前一步。把"看 Agent 输出什么就够了"作为主要假设的部署,在 Agent Shield、AgentSight 这类工具的实测里被反复证伪——攻击面在 OS 层,不在应用层。把"OS 层审计、无侵入跨厂商、跨事件关联、数据本地存储、威胁情报绑定"作为基线,重新设计企业 Agent 行为审计方案,是当下能落地的工程基线。

任何企业 Agent 项目,只要涉及 Agent 自主调用操作系统能力,工程基线就必须做到这五条——OS 层审计、无侵入跨厂商、跨事件关联、数据本地存储、威胁情报绑定——否则,今天不是某次 OS 层攻击事件的主角,也会是下一次 OS 层攻击事件的主角。