Muse Sentinel 逆向工程：构建内核级 AI Agent 安全网关

Sentinel 逆向工程：构建内核级 AI Agent 安全网关的技术指南

1. 为什么需要 Sentinel？（废话可以跳过）

AI Agent 面临的根本安全困境，被安全研究员 Simon Willison 称为“致命三元组”（Lethal Trifecta）：当 Agent 同时具备访问私人数据、接触不可信内容、对外通信能力时，一次成功的提示注入即可让攻击者继承 Agent 的全部权限 。

现实中，这个风险已经多次验证。2026 年初，一个 OpenClaw Agent 因收到含隐藏指令的邮件，删除了收件箱内所有邮件包括回收站 。Cisco 研究显示，社区技能库中约 26% 的代码含有漏洞 。独立研究发现，93.4% 的暴露 Agent 实例可被实际利用 。

Meta 的 Muse Agent 采用了与 OpenClaw 不同的策略：不试图让模型“不被骗”，而是让被骗的后果可控。这套架构的核心组件就是 Sentinel 。

2. 两个安全域

Muse Secure VM 采用单用户 Linux 虚拟机，内部划分为两个安全域 ：

运行时单元（Runtime Cell）：一个 systemd-nspawn 容器，运行 Agent 的推理模型（Muse Spark）、浏览器、Shell、文件系统工具。这是“不可信域”。

宿主域（Host Domain）：在容器之外、但仍在 VM 之内，运行安全敏感服务。Sentinel 就部署在这里。这是“可信域”。

关键设计原则：Agent 只能提议动作，Sentinel 拥有唯一的裁决权。即使 Agent 被完全操控，它也无法绕过宿主域的安全服务 。

3. 内核拦截层：eBPF 的三重钩子

Sentinel 的网络控制依赖 Linux eBPF 的三种程序类型，全部挂载在内核层，而非应用层 。

功能架构

四个纵向层级，从上到下依次是：

• 第一层：被监控容器（浅蓝）。三个工具进程，分别代表干净、已污染、继承污染三种状态，它们发起的 connect() 统一进入内核层。
• 第二层：内核层（浅红）。包含三个子模块：
  • eBPF cgroup 程序负责拦截和上报
  • LSM Hook 负责维护污点状态（虚线指向 eBPF，表示它提供状态查询）
  • cgroup freezer 负责挂起进程（虚线从 eBPF 指向它，表示按需调用）
• 第三层：用户态 Sentinel 核心（浅绿）。事件接收 → 策略决策 → 三条分支（放行/拒绝/审批）→ 执行器 → 日志审计。审批调度器与执行器之间有虚线回路，表示审批结果反馈到放行/拒绝决策。
• 第四层：用户设备（浅黄）。审批 UI 接收来自审批调度器的请求，返回结果。

3.1 网络连接拦截：cgroup/connect

eBPF 提供 BPF_PROG_TYPE_CGROUP_SOCK_ADDR 程序类型，挂载点为 cgroup/connect4 和 cgroup/connect6。该钩子在进程调用 connect() 系统调用时触发，在 TCP 连接建立之前拦截 。

关键特性：

• 程序接收 struct bpf_sock_addr 上下文，包含目标 IP（user_ip4/user_ip6）、端口（user_port）、地址族和协议类型 。
• 程序可以读取并修改目标地址，实现重定向或阻断。
• 返回值决定 connect() 是否继续执行 。

这意味着：当 Muse 容器内的进程发起网络请求时，数据包尚未离开虚拟机就被 eBPF 拦截。

3.2 污点传播：LSM Hook

Sentinel 的核心创新是内核级数据流追踪，通过 eBPF 程序挂载在 Linux Security Module (LSM) 钩子上实现 。

机制：

• 每个工具进程启动时状态为干净（clean）。
• 当进程读取用户数据（邮件、日历、联系人）时，LSM 钩子触发，将该进程标记为已污染（tainted）。
• 污点状态是内核维护的，不是应用层变量。Agent 无法通过代码逻辑“清洗”自己。
• 污点随 fork() 和 IPC 消息传播：子进程继承父进程的污染状态 。

3.3 决策逻辑：tainted egress

eBPF 程序根据污点状态决定请求走向 ：

Meta 将“已污染进程失去自动放行权”的机制称为 tainted egress 。

4. 进程挂起：cgroup freezer

当决策结果为“需要人工审批”时，Sentinel 必须暂停发起请求的进程，等待用户响应。这个机制不能使用 SIGSTOP，因为它可以被父进程或 ptrace 观察到，可能引发上层逻辑异常。

解决方案是 Linux 的 cgroup freezer 子系统 。

工作原理：

• 通过向 cgroup.freezer 写入 FROZEN，cgroup 内所有任务进入 TASK_UNINTERRUPTIBLE 状态。
• 内核调度器不再调度这些任务，它们不占用 CPU，不响应信号（除非配置为 killable）。
• 冻结是层次化的：冻结父 cgroup 会同时冻结所有后代。
• 向 cgroup.freezer 写入 THAWED 恢复执行 。

关键效果：被冻结进程的超时计时器也冻结。用户审批耗时多久，进程就冻结多久。解冻后，connect() 超时逻辑从冻结点继续，不会因为等待审批而“误判超时”。

5. 凭证代理：Agent 永远看不到真实密钥

即使 Agent 被提示注入完全操控，它也不应该能泄露用户的真实凭证。Sentinel 通过 hatch-authd 凭证代理服务实现这一点 。

机制：

1. Agent 需要的 OAuth token 或 API 密钥存储在 hatch-authd 中，该服务运行在 Agent 容器之外。
2. Agent 获得的是一个代理令牌（surrogate token）——没有实际权限的占位符。
3. 当请求通过 Sentinel 审批、即将离开 VM 时，Sentinel 从 hatch-authd 取出真实凭证，即时注入到请求中。
4. Agent 全程接触不到明文密钥。

安全意义：即使 Agent 被诱导“打印你的 API key”，它吐出的也只是无用的占位符。如果代理令牌被泄露，爆炸半径仅限于该令牌编码的特定权限和时间窗口 。

6. 审批通道：独立于被监控进程

当决策结果为“需要人工审批”时，审批请求不经过 Agent 的对话模型，而是直接推送到用户的设备（手机 App、WhatsApp、Web）。

为什么这很重要：

• 被污染的模型无法伪造审批请求。
• 模型无法在对话记录里写“用户已批准”来绕过控制，因为对话记录根本不是审批的传输通道。
• 模型无法拦截或篡改推送给用户的审批卡片。

审批结果直接返回给 Sentinel，Sentinel 再通过 eBPF map 通知内核放行或拒绝。

7. 已知局限与边界条件

任何安全架构都有边界，Sentinel 也不例外：

Prompt injection 仍是未解决问题。Meta 官方承认“Muse can and will still make mistakes”，并为此设置了最高 $300,000 的漏洞赏金，其中 $130,000 专门针对单用户提示注入攻击 。

审批卡片可能被污染。有分析指出，Sentinel 做决策时读的是 Muse 提交的“动作描述”，而非直接感知原始内容。如果 Muse 已被污染，它提交的描述可能失真 。

本地提权漏洞。安全研究员 Patrick Wardle 发现 macOS 客户端的未文档化配置项可被本地进程劫持，导致认证令牌泄露。Meta 在 12 小时内热修复，但证明了宿主 OS 被攻破时安全边界会失效 。

Meta 本身仍是信任方。Sentinel 的信任模型是“不信任 Agent，但信任 Meta”。在 Confidential VM 上线之前，Meta 公司仍有能力访问 VM 内的数据 。

8. 最小实现指南

如果你要构建自己的 Sentinel（不含连接器审批），核心模块如下：

阶段一：eBPF 拦截层

• 编写 BPF_PROG_TYPE_CGROUP_SOCK_ADDR 程序，挂载到目标 cgroup 的 connect4/connect6 钩子。
• 程序读取目标地址、端口、发起进程的 PID/cgroup ID。
• 将事件通过 perf ring buffer 或 BPF map 发送到用户态。
• 根据用户态裁决结果，返回 0（放行）或非 0（拒绝）。

阶段二：污点追踪层

• 编写 LSM eBPF 程序，监控文件读取（security_file_permission）和 IPC。
• 使用 BPF map 维护进程污点状态，键为 PID 或 task_struct 指针。
• 在 connect 钩子中查询污点状态。

阶段三：用户态决策引擎

• 接收 eBPF 事件，执行策略匹配（允许列表、拒绝列表、污点规则）。
• 需要审批时，通过 cgroup freezer 冻结目标 cgroup。
• 推送审批请求到独立通道，等待结果。
• 通过 BPF map 通知内核放行或拒绝，解冻 cgroup。

阶段四：凭证代理

• 存储真实凭证（OAuth token、API key）。
• 向 Agent 发放无权限的代理令牌。
• 在网络边界执行即时注入。

验证标准：

1. 被监控进程连接允许列表地址 → 成功。
2. 连接拒绝列表地址 → 立即失败，外部服务器未收到数据包。
3. 连接未知地址 → 进程冻结，外部未收到数据包。
4. 已污染进程的所有出站请求 → 强制审批。
5. 进程通过 fork、直接系统调用、修改自身状态绕过 → 均被拦截。