一、AI Agent 不是 Chatbot——安全模型必须推倒重来

2025 年底，某商业银行在内部测试中让 AI Agent 执行了一条简单的指令："把上周的合规报告发到我的邮箱。"Agent 完成了任务——但同时读取了同一目录下另一份标注为"机密"的授信审批表，并将其中的客户企业名称嵌入了回复邮件中。事件被 SIEM 系统捕获时，数据已经离开隔离区 37 秒。

这不是模型幻觉问题，这是执行边界缺失问题。

传统 SaaS 安全模型围绕"用户身份 → 菜单权限 → 数据行"设计，但 AI Agent 彻底打破了这个范式。Agent 不是用户，它是一个以容器/进程形态运行的自动化实体，拥有独立的执行上下文、访问凭证和工具调用链。更复杂的是——一个 Agent 可能同时操作数据库、调用 API、读写文件系统、执行 Python 代码，在传统安全模型中，这跨越了至少四个独立的安全域。

NIST 在 2025 年发布的 AI 系统安全指南（SP 800-218A 补充草案）明确指出：AI Agent 的安全必须从计算运行时层面开始，而非仅靠应用层鉴权。 具体而言，每个 Agent 实例需要独立的执行边界、受控的资源配额和可审计的操作日志——这些能力传统 Kubernetes RBAC 或网络策略均无法完整提供。

二、三层隔离架构：从内核到 Hypervisor 的纵深防御

ANI 的 AI Agent 安全模型建立在三层级联沙箱之上。每一层解决不同粒度的安全问题，三层联合构成纵深防御。

三层架构的设计逻辑：

• 第一层（进程级沙箱） 是性能与安全的平衡点。LLM 推理是对延迟最敏感的操作，VM 级隔离的额外开销（~5-8% 性能损失）在此场景中不可接受。通过 Landlock LSM（Linux 5.13+）在进程维度限制文件访问路径，配合只读 rootfs + 空网络命名空间，以几乎零开销实现"最小可用环境"。
• 第二层（容器级隔离） 是 Agent 工具调用的默认安全域。Agent 需要调用 API、读写文件、访问数据库时，Kata Containers（轻量级虚拟化容器运行时）提供硬件辅助的隔离边界，eBPF 程序实时过滤危险系统调用（如 `ptrace`、`mount`、`kexec_load`），OPA 在 Pod 启动时动态注入策略规则。
• 第三层（VM 级隔离） 是最高安全等级。当用户要求 Agent 执行自定义 Python/Shell 代码时，ANI 自动将执行上下文路由到 Firecracker microVM——一个由 KVM 硬件虚拟化保证的独立地址空间，即使代码中嵌入了恶意系统调用，也无法逃逸出 VM 边界。

三、安全等级的自动化路由：不是"选一层"，而是"三层都要"

实际运行中，一个 AI Agent 的生命周期可能需要动态穿越三层。以"分析销售数据并生成 PPT"为例：

安全等级判定的核心规则：

操作类型	路由目标	安全控制	额外限制
LLM 推理	L1 进程沙箱	Landlock 路径白名单	只读 rootfs，无网络
API 调用 / DB 查询	L2 容器隔离	eBPF 系统调用过滤	NetworkPolicy 白名单出口
文件读写	L2 容器隔离	OPA 动态策略	路径前缀校验（禁止 …/ 穿越）
用户自定义代码执行	L3 VM 隔离	KVM + seccomp	无出站网络，执行超时 120s
系统命令调用	L3 VM 隔离	Firecracker jailer	只读 overlay rootfs

四、权限管控：RBAC 是起点，动态凭证是终点

传统 RBAC 管理的是"哪个用户能访问哪个 API"。AI Agent 的权限管控需要回答另一个问题：“这个 Agent 实例，在这一次执行中，能以什么身份访问什么资源？”

ANI 的权限模型包含三层：

1. Agent 身份（静态）：每个 Agent 在创建时被分配一个 SPIFFE ID（X.509 SVID），这是其在集群中的唯一身份。Agent 的 RBAC 角色定义其"理论上能访问什么"。

2. 执行凭证（动态）：Agent 每次执行任务时，WorkloadRuntime Port 调用 Vault 的临时凭证引擎，生成仅有效期 15 分钟的临时凭证（数据库密码 / API Key / 对象存储签名 URL）。凭证在 Agent 执行结束时立即吊销——即使 Agent 日志被截获，攻击者只能拿到已过期的凭证。

3. 工具级白名单（运行时）：Agent 可调用的工具列表在部署配置中显式声明。例如"销售数据分析 Agent"的工具白名单为 `[db_query, file_read, pptx_generate]`——任何未在白名单中的工具调用（如 `send_email`）在 OPA 策略引擎层面即被拦截，根本不进入 Agent 的执行上下文。

五、数据隔离：不止是"不让读"，还要"读完不留痕"

企业场景中最隐蔽的安全风险不是越权读取，而是数据驻留污染——Agent 在内存中缓存了敏感数据，下一个任务如果不清理上下文，可能将其泄露给无权限的用户。

ANI 的数据隔离策略分三个维度：

维度	机制	具体实现
**存储隔离**	每个 Agent 实例绑定独立 PVC 子路径	Longhorn CSI + subPath 策略，实例间不可见彼此文件
**内存隔离**	任务级上下文清零	每个 task 执行后强制回收容器/MicroVM，不留内存残留
**网络隔离**	出口按安全等级分段	L1 无网络，L2 白名单出口，L3 无出站——杜绝数据外泄载体

数据分级策略：

• 公开数据（L0）：允许在 L1/L2/L3 自由流动
• 内部数据（L1）：仅在 L2+ 隔离等级可用，禁止进入 L1（杜绝模型训练污染）
• 机密数据（L2）：仅在 L3 VM 隔离中可用，禁止持久化到 Agent 工作区
• 绝密数据（L3）：需额外审批，审批通过后在独立 MicroVM 中处理，处理完毕立即销毁 VM 镜像

数据分级的执行点不在 Agent 代码逻辑中，而在 WorkloadRuntime Port 的路由决策中——Agent 只知道自己"能干什么"，不知道自己"在哪一层干"。这是对传统"开发者自己写 if-else 判断数据等级"模式的根本性改进。

六、审计追踪：回答"谁、何时、做了什么、为什么"

在安全沙箱的设计中，审计不是事后补救，而是与隔离机制同等的第一性需求。ANI 的审计管道包含四个层级：

L1 — 系统调用审计：通过 Falco（CNCF 毕业项目）在内核态捕获所有系统调用，规则引擎定义异常行为模式（如 Agent 尝试访问 `/etc/passwd`）。

L2 — 文件访问审计：Longhorn 存储层支持 per-volume 审计日志，记录每个文件的 open/read/write/delete 操作及其调用者 SPIFFE ID。

L3 — 网络流量审计：Cilium Hubble 在 eBPF 层记录所有 Pod 出口流量（源 IP / 目标 IP / 端口 / 协议 / 字节数），配合 NetworkPolicy 的 DENY 日志形成完整流量拓扑。

L4 — Agent 决策审计：这是最独特的一层。Agent 的每一次工具调用决策（“为什么选择了 db_query 而不是 file_read”）被记录为结构化日志，包含推理步骤的 trace 信息。审计回溯时，可以完整复现 Agent 的决策链。

四层日志统一汇入 Loki + Grafana 审计面板，保留周期默认 180 天（满足等保三级"审计日志保存不少于 6 个月"的要求），所有日志写入时由 HashiCorp Vault 签发 HMAC 签名，日志条目不可篡改。

七、与竞品安全模型的差异对比

维度	ANI 三层沙箱	华为 MetaStudio	百度千帆
隔离层级	进程 / 容器 / VM 三级级联	容器级为主 + ModelArts 资源组隔离	容器 + 部分 VM（千帆安全围栏）
代码执行安全	Firecracker microVM 独立内核	依赖 CANN 沙箱（昇腾专属）	沙箱执行环境（平台托管）
动态凭证	Vault 临时凭证，15min TTL	华为云 IAM 临时令牌	百度云 STS 临时凭证
审计粒度	系统调用 + 文件 + 网络 + Agent 决策四层	ModelArts 作业日志 + 云审计	千帆操作审计 + 云审计
数据分级执行点	WorkloadRuntime Port 路由决策（架构级）	开发者代码中判断	平台配置中声明
部署模式	私有机房，全链路不出域	公有云 / 混合云	公有云为主

ANI 的方法论底层逻辑是：安全能力必须下沉到计算运行时层，因为 AI Agent 的"用户"已经从人类变成了自动化程序。 架构上的 ports/adapters 设计天然地将安全策略（Port）与执行载体（Adapter）解耦——WorkloadRuntime Port 决定"这个任务应该在什么安全等级执行"，而 Kata/Firecracker/Landlock 各 Adapter 只负责执行隔离策略本身。这种分离使得新的安全技术（如即将成熟的 AMD SEV 加密虚拟机）可以作为新 Adapter 插入，不影响已运行的 Agent 工作流。

八、实际操作建议：评估你的 AI Agent 安全现状

如果你是正在规划 AI Agent 部署的技术决策者，以下四个问题可以帮助你快速评估当前安全状态的成熟度：

1. Agent 能否读取超出其任务范围的文件？ 如果你的 Agent 运行在完整 rootfs 的容器中，答案是"能"。
2. Agent 执行自定义代码时，能否逃逸到宿主机？ 如果使用的是标准 runc 容器（无 VM 级加固），逃逸风险不可忽视。2025 年 CVE-2025-0185 就是一个标准的 runc 容器逃逸漏洞。
3. Agent 任务结束后的内存残留是否能被下一个任务读取？ 如果 Agent 是长期运行的 Pod（容器常驻），答案同样是"能"。
4. 你能在事后还原 Agent 为什么访问了某个文件吗？ 如果只有容器日志，没有 Agent 推理链的 trace 信息，你看到的只是"what"，看不到"why"。

如果任何一个问题的答案是"能"或"不能"（取决于问题方向），你的安全模型需要从应用层下沉到计算运行时层——这正是三层沙箱架构设计的原始动因。