开头先交代一个背景。我在给一个 AI Agent 平台做上线前的安全审计时遇到了一件让我坐不住的事沙箱里采集到的审计日志和 Agent 进程在系统里实际产生的行为记录有大约 7% 对不上。这个数字不是指时间戳差了几毫秒而是指操作缺失、参数被改写、或者文件内容前后矛盾这类实质性偏差。第一反应是怀疑自己的解析脚本写错了后来排查到日志链路本身可以被人为干预才意识到问题的严重性——如果一个 AI Agent 的监察体系所依赖的日志本身就是可以被伪造的那这套监察体系到底在监察什么这篇文章不是学术报告是我把那次审计和后续设计监察体系的完整思路整理出来的实战分享。适合给正在做 AI Agent 平台、沙箱隔离、自动化运维审计的团队做参考尤其是那些准备把 Agent 大规模放开到生产环境、却被合规和风控卡住的同学。如果你以为“沙箱里的日志就是可信的”这篇文章可能要给你当头一棒。1. 一次让我冒冷汗的审计7% 的沙箱记录根本对不上1.1 这个 7% 是怎么测出来的当时我们手头有一套自研的 Agent 沙箱整体架构是容器化隔离加日志服务Agent 在沙箱里执行工具调用时沙箱平台会记录调用内容、时间、输入输出然后汇入统一审计平台。理论上是完整的看起来也很完整。但在审计前我多做了一个动作在宿主机上用另一个独立采集程序记录了同一批 Agent 的系统级行为包括进程启动、文件写入、网络外联、子进程树关系两边数据一比对结果非常难看。测试任务是让 Agent 在沙箱里做一系列固定操作创建 /tmp/report.txt 并写入指定内容删除 /tmp/old_data.dat通过 HTTP 向 mock 服务器发送一段 JSON执行一条 shell 命令并返回输出总共跑了约 200 次完整任务循环我对沙箱日志和宿主机采集的原始事件做了逐一关联。结果对不上的记录约占 7%对不上的形态分成几类偏差类型占比具体表现日志缺失3.1%Agent 明确执行了删除操作沙箱审计里完全没有对应记录参数被改写1.8%实际 shell 命令带了--force日志里记录的却是精简后的命令时间戳漂移1.3%系统事件发生在 10:02:11日志记录却是 10:02:09且不是时区问题输出内容矛盾0.8%Agent 自述“文件写入成功”但宿主机显示写入路径被重定向到了临时目录这里最刺激的不是漏报而是参数被改写和时间戳漂移。漏报还能用“采集器能力不足”来解释但参数和时间戳被改动说明日志链路已经可以被有意干预了。我当时只是做审计没有刻意攻击就已经是这个结果。如果是恶意 Agent 或者被攻破的 Agent 在故意掩盖行为比例恐怕远不止 7%。1.2 为什么审计人员会特别在意“伪造”这两个字在安全审计里日志的价值取决于两件事一是能不能采到二是采到了之后能不能信。采不到是技术问题。比如某个 syscall 没有对应的 hook或者容器网络抓包丢包最多算采集盲区风险可控。但记录被伪造是信任问题。一旦审计人员发现日志里出现了一个“实际操作不存在”的记录或者一个“实际操作确实发生但记录被涂改”的痕迹整条日志链的可信度就会崩塌。后面的根因分析、溯源、定责全部失去了根基。我在审计总结里写过一句话沙箱日志是 Agent 的口供不是 Agent 的罪证。口供可以撒谎也可以被逼着撒谎真正能定案的是口供之外独立获取的物证。7% 这个数字恰恰说明在现有架构里沙箱日志连“可靠的口供”这个标准都达不到它更像一份被涂改过口供。1.3 这里我先给一个结论经过这次审计我的核心判断是别再把 Agent 沙箱自带的日志当作证据级数据。任何监察体系都必须把“数据采集”和“记录存储”这两件事分开设计。采集端要下沉到 Agent 碰不到的地方存储端要做防篡改和独立见证。如果这两个前提没做到后面叠再多告警规则和风控策略都是在一片流沙上盖高楼。2. 根因拆解Agent 沙箱日志为什么这么容易被伪造2.1 沙箱不是保险箱它只是权限收紧的容器很多人对“沙箱”有一个误解觉得代码进了沙箱就安全了。真实情况是沙箱包括容器、虚拟机、MSIX 这类应用隔离机制本质上是一个权限策略集合它能限制进程能访问哪些资源但它自己也是跑在操作系统上的软件。凡是软件就有被攻破的可能。最近有一个热词很能说明问题codex.exe 直接被拒绝访问了——这是 MSIX 沙箱保护导致的。这个例子的价值在于MSIX 沙箱确实能在某些路径上拦下恶意尝试但这种“拦截”是通过策略和内核对象实现的它跟“记录和审计”是两码事。沙箱能拦行为不代表它能如实记录行为。甚至恰恰相反很多沙箱为了性能审计功能是默认关闭或半关闭的。限制手段再强如果缺失独立审计Agent 在沙箱内部干了什么你仍然只能靠它自己的汇报来了解。还有一点容易被忽略沙箱内的日志服务往往跟 Agent 跑在同一个用户态环境里。同一个权限边界内的组件Agent 一旦通过漏洞拿到同等级权限日志文件、日志管道、日志 SDK 都是可写的。沙箱隔离的是外部的恶意进程不是隔离“已经从内部被攻破的 Agent”。2.2 日志从产生到落地中间的路比你想的长得多一个完整日志链路通常长这样Agent 进程 - 运行时Python/Node/Go runtime - 日志 SDKlogging 库 / OpenTelemetry - 日志 agentfilebeat / vector / fluent-bit - 写盘或上报队列 - 审计数据库这段链路每跳一层就多一个可以被干预的点。SDK 里打个 log 是用户态写文件日志 agent 采集是用户态读文件队列上报是用户态网络请求。任何一个环节被 hook、被注入、被改配置日志内容都可能被拦截、丢弃或篡改。我在审计时做了一个验证在沙箱环境里用 LD_PRELOAD 预加载一个共享库hook 掉write和open系统调用让所有带rm的日志在写入前被替换成无害的echo。结果沙箱审计平台里显示的记录全是echo开头的无害命令而宿主机采集到的事件里rm执行得明明白白。这套攻击的成本极低可能几千行 C 代码都用不到就能让业务侧的审计数据完全失真。2.3 Agent 的“工具调用”日志不是系统事实AI Agent 的架构里日志大体分两层一层是 Agent 自己输出的工具调用记录比如“我调用了 delete_file(path’/tmp/old_data.dat’)”这样的 JSON另一层是操作系统记录的真实事件比如unlink(/tmp/old_data.dat)这个系统调用。这两层之间有本质区别。Agent 输出的工具调用记录是大模型根据它的推理过程生成的文本。它描述的是 Agent“认为”自己做了什么甚至可能是 Agent“希望审计员认为自己做了什么”。系统调用记录才是客观事实。一个经典的例子Agent 被要求删除/tmp/a.txt但环境变量或者配置文件被改动实际删除的是/tmp/b.txt。Agent 的日志里会堂而皇之写上“已删除 /tmp/a.txt”因为它确实不知道真实情况。这种不一致不一定是恶意但恰恰说明依赖 Agent 自述做审计有多脆弱。监察体系的铁律应该是Agent 说什么不重要系统记录到什么才算数。凡是要做安全决策的数据必须来自 Agent 触达不到的那一层。2.4 典型伪造路径一览结合我在审计中摸到的攻击面梳理几条最典型的路径直接改日志文件沙箱日志以文件形式存在本地Agent 拿到写权限后直接改写或删除记录。多数平台对日志文件缺少完整性校验改完校验和也不会被发现。hook 日志写入函数预加载一个 .so 或 inject 一个 DLL重写日志写入函数在数据落地前清洗敏感操作。这是最隐蔽的手法日志链路本身是正常的只是内容被“过滤”了。替换上报队列日志 agent 采集后发送到消息队列如果队列未做强认证Agent 可以投递伪造记录或者消费掉真实记录。时间戳伪造很多审计系统只记录业务时间不跟系统时钟做交叉验证。Agent 只要改掉内部时钟或者篡改时间字段就能把攻击行为伪装成历史遗留问题。批量重放抓取一段合法操作日志在需要掩盖真实行为时把旧记录重放进审计流制造“一切正常”的假象。这些路径有一个共同点它们都没有攻击“内核态事件采集”这一层所以内核态数据成了最后一道可以信任的防线。这也是下面监察体系设计的基础。3. 监察体系设计的三条主线信任分层、独立见证、交叉验证3.1 主线一给数据定级不再把沙箱日志当唯一事实我设计监察体系时做的第一件事不是选工具而是给所有数据划分信任层级。从低到高分成三层L1 Agent 自述层Agent 的工具调用日志、LLM 推理输出、业务日志。信任度最低只能参考不能定案。L2 平台记录层沙箱平台的审计记录、API 网关日志、任务调度记录。信任度中等可以作为线索但仍可能被绕过。L3 独立见证层内核级系统事件eBPF/ETW、管理程序层日志、旁路网络包。信任度最高是监察体系的事实基础。这三个层级在后续的规则引擎里对应不同的权重和处置权限。比如发现 L1 和 L2 不一致时可以触发告警只有 L1 自己的异常只能作为可疑参考一旦 L3 确认了某个恶意行为直接进入阻断流程。这个分级带来的最大好处是即使 Agent 层和平台层的日志被伪造我们也不会把伪造后的内容当成事实去分析。伪造行为本身会留下痕迹比如 L3 有记录而 L1/L2 没有这本身就值得告警。3.2 主线二独立见证层让“证人”和“当事人”分开审计学里有个基本原则证人不能跟当事人利益相关。放在 Agent 监察体系里就是日志的记录者不能跑在 Agent 能影响的代码路径上。独立见证层应该部署在哪里我的建议是优先级从高到低排宿主机内核层Agent 跑在容器的 namespace 里宿主机内核通过 eBPF 或者 Linux audit 框架可以捕获容器内经所有进程的系统调用。无论容器内部怎么伪装syscall是绕不过去的。管理程序层如果 Agent 跑在轻量级虚拟机microVM里hypervisor 可以旁路记录客户机每个 vCPU 的行为包括中断、系统调用、内存访问模式。这层成本高但安全性最强。旁路网络采集通过交换机端口镜像或者 tap 设备把 Agent 所在网段的流量复制一份到独立的审计系统解码。网络数据包难以伪造源信息尤其是 TLS 之外的明文协议阶段。独立见证层采集到的原始事件要在第一时间计算哈希并按时间顺序串成哈希链。每条新记录的哈希要包含前一条记录的哈希这样一个节点被篡改后面所有节点的哈希都对不上。这是最基础的防篡改手段成本极低但对“改一个值而不被发现”的防护效果立竿见影。我建议用类似区块链的链式结构但没必要真的上链。把哈希链的根值定期同步到对象存储的不可变版本里或者同步到外部时间戳服务就足够满足绝大多数企业审计需求了。3.3 主线三行为一致性核验用系统事件校验 Agent 的自述有了独立见证层的数据之后监察体系要做的事情就清晰了持续做“对账”。对账的输入是两端数据Agent 声明的行为来自 L1一段 JSON例如“我要调用 shell_exec命令是rm -rf /tmp/cache”系统记录的事实来自 L3内核事件序列例如clone - execve(/bin/rm) - unlink(/tmp/cache)核验引擎要做的是把 Agent 声明映射到预期系统事件集合然后跟实际事件集合做比较。匹配逻辑可以用规则集也可以训练一个轻量映射模型我的经验是最初先上规则集跑通链路之后再引入模型提升覆盖率。映射后的比对结果可以用一个“不一致分”来表达0 分声明事件与系统事件完全匹配没有异常。0.3 分存在时间偏移或路径别名但语义一致。比如 Agent 声明删除/tmp/cache/系统事件是删除/tmp/cache2属于路径别名。0.6 分Agent 声明了某操作但系统事件里完全找不到对应痕迹。这是明显篡改或幻觉。0.9 分系统事件里出现了 Agent 声明之外的敏感操作比如 Agent 没提网络外联但系统事件里有外连记录。这是隐蔽行为上了账。每条 Agent 工具调用生成一个不一致分聚合后生成会话级评分。当评分超过阈值时监察系统把上下文打包交付给安全运营或者自动策略引擎。这种“声明-事实”的对账逻辑比单纯堆告警规则要难绕过得多因为它把 Agent 的自述拖进了不可信的评判席。4. 一套可以动手落地的分层监察栈4.1 采集层宿主机 eBPF 事件采集我落地监察体系时选的是 eBPF。因为它可以直接在宿主机内核态挂载探针从事件产生的源头捕获数据用户态进程包括容器内的 Agent没有能力去篡改内核态探针的输出。具体用到的探针包括execve捕获进程启动记录二进制路径、参数、环境变量前若干项。openat捕获文件打开记录文件路径、打开标志是否写、返回值。unlink/unlinkat捕获文件删除这是审计 Agent 文件破坏行为的关键事件。connect捕获网络连接记录目的 IP、端口并关联到进程 PID。我用 libbpf 实现的一个简化版execve追踪器骨架大致长这样struct { __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY); } events SEC(.maps); SEC(tracepoint/syscalls/sys_enter_execve) int trace_execve(struct trace_event_raw_sys_enter *ctx) { struct event_t e {}; u64 pid bpf_get_current_pid_tgid() 32; u64 global_ts bpf_ktime_get_ns(); e.pid pid; e.ts_ns global_ts; bpf_probe_read_user_str(e.comm, sizeof(e.comm), (void *)ctx-args[0]); bpf_perf_event_output(ctx, events, BPF_F_CURRENT_CPU, e, sizeof(e)); return 0; }这里有两个细节容易被忽略。第一时间戳不要直接取bpf_ktime_get_ns()之外的业务时间内核时间戳是整个监察体系里所有数据关联的主键。第二pid是内核视角的进程号在容器环境里它的值跟容器内ps看到的 PID 不一定一致后面做关联时需要把 Host PID、容器内 PID、Agent 任务 ID 做一张映射表。Windows 环境下对应的方案是 ETW 加内核回调底层逻辑一致。如果对隔离等级要求更高可以上 VBS基于虚拟化的安全隔离把审计进程放到一个独立虚拟信任边界里但成本会贵很多。4.2 记录层防篡改审计记录流水线采集到的事件不能直接落到普通文件里我使用的格式是链式事件结构。每条记录至少包含以下字段{ event_id: a1f2..., seq: 1042, prev_hash: 7c9d..., agent_id: agent-4f31, session_id: sess-9b7, event_type: unlink, event_payload: { pid: 8712, path: /tmp/old_data.dat, exit_code: 0, host_timestamp_ns: 1715750000123456789 }, event_hash: 5e81... }seq是单调递增序号防止重放攻击prev_hash是上一条事件的哈希把整个审计流串成链条event_hash是当前事件 payload 的哈希防止事件内容被改动。链条定期做聚合比如每 10 分钟出一个根哈希同步到独立的可信时间戳服务或者对象存储的不可变版本桶里。很多人会问既然我都要设计监察体系了直接把日志存到额外的数据库不就行了吗不行。普通数据库记录可 UPDATE 可 DELETE即使有操作审计数据库管理员和攻击者如果能拿到数据库权限日志一样能被改掉。哈希链的作用不是防止数据库被写坏而是让“任何对历史记录的改写”都能被事后检测到。即使攻击者改了当前副本里的内容只要跟外部时间戳服务里存的历史根哈希一比对立刻就知道哪一段链被人动过。4.3 决策层策略引擎与分级响应独立的采集层和记录层建好之后决策层才能发挥价值。决策层的作用是把“不一致分”转成具体处置动作。租约策略示例不一致分处置动作说明0 - 0.3记录归档正常操作只留痕0.3 - 0.6标记可疑 上下文保存进入待观察名单不做主动干预0.6 - 0.8二次验证 动态令牌降权减少 Agent 可用额度强制人工复核0.8 以上冻结沙箱 全网广播撤销 API key阻断 Agent 进一步操作进入事件响应流程在响应通道上也要遵循“独立控制面”原则。冻结动作必须走独立的控制面通道不能依赖 Agent 所在沙箱内部的调用来执行。我的实现是让监察系统直接调用宿主机上的沙箱管理 API由管理面把沙箱网络断开、进程冻结、磁盘 IO 拒绝这些动作完全不经过 Agent 的代码路径Agent 即使已经拿到了沙箱内部的高权限也无法对抗。4.4 成本与性能考虑任何监察体系都要谈成本不加节制的全量采集会把系统拖垮。我在压测里得到的数据是eBPF 追踪execve、openat、connect这几个高频系统调用在 CPU 密集型 Agent 任务下性能损耗在 3%-7% 之间。考虑到监察体系的重要性这个损耗在多数场景下是可以接受的。事件量是另一个问题。单个 Agent 会话高峰时每秒可能会产生上千个文件打开事件不完全采样日志系统一天能积累几个 TB。我的建议是分级采样所有execve、connect、unlink、rename事件全量记录这些是安全敏感操作数据量相对少。openat事件按进程维度采样Agent 主进程全量沙箱内其他低敏进程按 1/10 比例采样。纯读取事件read/readv不做系统调用级审计只做文件信息变更审计否则性能扛不住。不要为了审计完整性把所有事件都采全因为真正能在安全事故里派上用场的事件类别通常不超过十种。抓住关键操作比什么都记更重要。5. 防守方视角的对抗推演绕过检测还能走哪几条路设计完监察体系之后我心里还是没底。作为一个安全背景的人我知道所有防御设计都必须经过“假装自己是攻击者”的推演。我列了几条可能的绕过路径每条都做了具体的推演。5.1 绕过路径 A攻击采集层如果攻击者已经拿下了沙箱内 Agent 进程的权限他能不能反过来攻击宿主机的 eBPF 探针答案是很难但要分情况。eBPF 探针运行在内核态普通容器内进程无法直接卸载或者修改一个挂载在 tracepoint 上的 eBPF 程序。但如果攻击者通过容器逃逸拿到了宿主机的 root 权限那么他可以bpftool detach摘掉探针或者加载一个恶意 eBPF 程序干扰原有的审计逻辑。针对这种情况防线上要做两件事启用内核的 lockdown 模式禁止 eBPF 程序随意加载和卸载给审计探针加BPF_LSM挂载点用安全模块保护探针本身。这两层防御在主流内核版本上都已经支持属于配置工作不涉及定制内核。现实中的攻击者往往不会走这么重的攻击路径。对他们来说更简单的做法是不去动 eBPF 探针而是让事件无法产生。比如把文件删除操作替换成rename到一个隐藏目录这样unlink探针不会触发文件却已经被移走了。这个细节说明监察体系的事件覆盖率必须持续迭代不能固定在一组探针上就不再更新。5.2 绕过路径 B伪造业务侧事实交叉验证的基准是系统事件但如果攻击者能够伪造业务侧事实情况会变得非常棘手。举个例子Agent 声明它调用了网络外联目的是访问合法 API。系统事件里确实有connect记录IP 和端口能对上。但实际发送的 HTTP payload 里夹带了数据外传。这种伪造不发生在系统调用层而发生在“应用层语义”里。eBPF 看到的是连接存在看不到请求体的含义。应对方案是键盘记录级审计和 payload 审计双管齐下。对 Agent 的工具调用要求平台层在发起前先对 payload 做哈希并把这个 payload 哈希传给独立见证层网络层采集到同一连接的数据包时同样在独立侧计算 payload 哈希。两边哈希一致才能认定业务侧事实为真。这个方案能让“改业务事实而不被发现”的成本大幅上升。5.3 绕过路径 C时间与重放攻击审计记录里的时间戳如果可以被伪造整个哈希链的逻辑就会产生裂缝。攻击者可以先把当前时间改成一个“未来时间”做一笔恶意操作再把时间改回来让这条记录看起来发生在“过去”。哈希链能防篡改但它不能防“带有正确哈希的错误时间”。对策来自两个方向第一采集层使用系统级单调时钟也就是bpf_ktime_get_ns这类时钟源它不受用户态date命令影响第二定期用外部时间服务校准宿主机的系统时钟并在审计记录里同时保留“采集时间”和“业务时间”。采集时间由采集层生成、加密签名业务时间直接从 Agent 的声明里提取。两个时间戳的差值超过阈值时直接判定为时间异常。重放攻击的防护逻辑类似。攻击者抓一段旧的合法记录在今天重新投递到审计数据库。因为链式记录里seq是单调递增的重放的记录序号会跟当前的最新序号冲突或倒挂再叠加外部时间戳服务里存的根哈希对比重放记录会立刻显出原形。5.4 绕过路径 D利用监察体系自身的高危权限这是我提醒整个监察体系设计同行注意的一条。监察系统自己拥有审计权限、阻断权限、管理面 API 权限一旦监察系统本身被攻破所有设计都白搭。所以监察体系的架构设计要遵循三个原则只读优先审计数据存储层对外只暴露只读接口任何写入必须经过独立的审计网关签名。这样即使 Agent 拿到数据层访问权限也无法写入伪造记录。密钥分离采集层、记录层、决策层使用不同的凭据。采集层的密钥只用于推数据入场决策层的密钥只用于读数据出库和触发阻断任何一层被攻破不会波及其他层。最小暴露监察系统的管理端口不绑定在业务网段只允许跳板机访问。管理面的操作全量记录并在另一个独立系统上留备份。这个思路用一个词概括就是“纵深防御”。监察体系本身也是被监察的对象。6. 落地中的几个取舍判断个人向前面讲的是技术框架最后聊聊我实际操作中做过的几组取舍这些判断没有标准答案但可能对你有参考价值。第一个取舍是采集粒度。我一开始想把所有事件全量记录结果上线半天审计存储直接爆了查询性能也明显劣化。后来改成“敏感操作全量 常规操作采样”的策略存储量降了 70%安全事件覆盖率几乎没有下降。采集设计从一开始就应该默认“存不下所有的数据”思考哪些事件丢了你能接受比思考哪些事件必须记下来更容易梳理清楚。第二个取舍是监察系统要不要自动阻断。很多安全运营希望监察系统发现异常后直接杀掉 Agent 进程我个人的建议是默认不自动阻断先做“审计可信”再逐步放开到“自动处置”。原因很简单AI Agent 的行为模式和传统安全事件差异很大固定规则很容易把 Agent 的正常探索行为识别成恶意行为。我见过连续误杀 7 个合法 Agent 任务的案例最后运营团队被迫把阈值调高到形同虚设。比较稳妥的做法是先用三个月积累真实 Agent 行为基线再引入自动阻断策略且阻断后必须 24 小时内人工复盘一次。第三个取舍是团队配置。监察体系的建设不是一个安全团队能独立完成的事。你需要 SRE 处理采集层的性能和稳定性需要 ML 平台团队提供 Agent 声明数据的 schema 和 tool call 的语义映射还需要安全团队设计对抗检测规则。三方缺一不可。我见过不少项目纠结于选型、纠结于要不要搞一个大而全的平台反而忽略了这件事本质上是一个“三拨人坐下来对数据口径”的工程问题。最后我想说的是7% 这个数字给我最大的提醒不是那个具体的比例而是它背后的假设我们在设计任何监察体系之前都应该先回答一个问题——如果被监察者拿到了看一眼日志的权限这个体系还成立吗把这个问题想透了设计出来的东西才不是绣花枕头。