多 Agent 平台的整体安全体系设计—— oodagent 的信任链、通道纪律与合规举证

ENGINEERING BLOG · Agent Infrastructure × Security Architecture

多 Agent 平台的整体安全体系设计—— oodagent 的信任链、通道纪律与合规举证

01当第二个 Agent 出现，安全就不再是一份台账

在单体内，安全的主体是"系统"；在多 Agent 平台上，每一个 agent、每一条通道、每一次委派都是独立的攻击面。 oodagent 平台运行着 studio、agent、codeagent、im 四类节点，agent 之间互相委派任务、调用工具、回写数据—— 当"说话的"不再只是人，第一性问题从"标准有哪些条款"变成：谁在说话？话从哪条通道来？它被允许做什么？事后能不能举证？

这四个问题正好构成我们的四层安全体系：信任层 → 通道层 → 闸门层 → 记忆层。 而等保 2.0 三级合规（GB/T 22239-2019），是这套体系对监管语言的自然翻译，而不是设计的出发点—— 这也是本文的立场：先把安全体系做实，合规是它的一个视图。

一个脚注：公安部令第 176 号《网络空间安全监督检查办法》于 2026-10-01 施行， 千人规模企业财务系统按第三级口径建设。监管倒计时是真实的，但合规工具不应是"测评前一周的全员突击"， 而应是日常运维的副产品——本文第六节会展示这个"副产品"长什么样。

02信任层：双标识分离 + HMAC 三档放行

多 Agent 系统最常见的身份事故是把"我是谁"和"发到哪"混成一个标识。 oodagent 从第一天起把两者拆开：

agentId — 业务身份

可授权、可寻址、可审计。权限挂在它身上，A2A 委派链的每一跳都署名。

nodeId — 物理投递地址

节点寻址用。解析不到目标节点就显式失败，绝不"猜一个相近的投过去"。

per-agent 密钥

每个 agent 独立密钥，杜绝共享凭据——共享即丧失可追溯性。

人类身份统一签发

org 统一签发会话；服务态调用必须走 CurrentUserProvider 取当前用户，前端自报与固定兜底一律禁止。

agent 之间的信任不是"声称即信任"：A2aAgentIdentity 用 HMAC-SHA256 对每条委派消息签名， 请求头三件套 x-a2a-sig / x-a2a-kid / x-a2a-node 分别承载签名、密钥标识与来源节点， 并按业务场景选择放行档位：

设计取舍：audit 档看似"不设防"，实则是灰度期最诚实的姿态—— 一刀切 strict 会逼着运维私自加白名单（真正的失控），audit 档让每一次未登记调用都留下可追责的痕迹。

03通道层：三类通道分离，失败必须显式

如果把所有节点间通讯塞进一条"万能通道"，边界防护就无从谈起。 oodagent 按数据温度与方向把通讯拆成三类通道，每类有独立的安全约束：

三条通道之外，还有一条纪律值得单独说：投递失败必须显式，而不是静默。 解析不到目标节点就 UNDELIVERABLE 落库 + WARN，绝不退回通配广播—— 静默重试是分布式系统里最贵的债，而通配广播则是安全体系里最便宜的"旁路"： 它让一条本该被拒的消息，换个名字抵达了不该抵达的地方。

04闸门层：策略活在模型之外

Agent 与传统自动化的本质差别，是它的行为由自然语言驱动。因此授权策略如果写在 system prompt 里，就等于写在攻击面上——提示注入可以提取它、覆盖它、混淆它。 业界对 confused deputy（混淆代理）的研究已经把这一点讲透：agent 的"乐于助人"正是漏洞本身。 oodagent 的对策是把所有闸门放在模型够不着的位置：

• 权限码 RBAC：console.{域}.read/.write 按路径自动推导， 支持 observe（只记录）→ enforce（强制拦截）两阶段上线；免权限白名单仅含健康检查/登录/菜单等无敏感面。
• 域写开关默认关：每个管理域独立 *.write-enabled（默认 false）。 写动作在后端配置层校验——前端按钮禁用只是提示，服务端才是闸门。
• 被拒绝的尝试也审计：每次写动作（含 DENIED）记入审计流。攻击者探测的痕迹，就是防守者的情报。
• agent 不可修改自身护栏：自主维护闭环中，护栏/路径白名单/备份/审计配置属于 DENY 域—— LLM 无权放宽约束自己的那道闸。
• 终态语义不可改写：流程终态（审批结论等）为只读语义，任何 agent 不得"帮忙"修正。

一句话总结这一层：提示词负责让 agent 聪明，配置层负责让它安全。两者的部署位置必须物理分离。

05记忆层：冷热分离的审计链

安全的最后一公里是"事后能查"。多 Agent 平台的审计比单体难在两件事： 事件分散在多个节点进程内，且热数据天然不可信（进程重启即失忆）。oodagent 的解法是把审计 按"产生 → 冷却 → 归档"的流水线处理：

⚡产生（热）

节点进程内环形缓冲；写审计三元组 域·动作·结果，携带 X-Trace-Id 关联调用链。

❄️冷却（VFS）

异步落 VFS 分布式文件层——append-only，管理台只读，不碰热路径。

️归档（冷）

定期归档 + lucene 索引；留存期可配置，底线对齐法规（日志 ≥6 个月）。

举证（检索）

按域/时间检索 + CSV 导出；测评现场的证据从系统里长出来，不靠事后补截图。

与审计链配套的是五条冷热数据纪律（R1–R5）：默认冷视图、热数据必须标注来源与时效、 节点离线展示最后快照而非假零、热数据不得落库后冒充冷数据、实时通道只透传不重放。 它们看起来是数据架构，实际上是反伪造纪律——让"管理台上看到的"永远可以追溯到"节点里真实发生的"。

06合规切面：等保三级是体系的"翻译层"

有了上面四层，等保 2.0 三级的大部分条款不再是"额外工程"，而是把已有机制翻译成监管语言： 信任层对应身份鉴别（8.1.4.1）、通道层对应安全通信网络与区域边界（8.1.2/8.1.3）、 闸门层对应访问控制（8.1.4.2）、记忆层对应安全审计（8.1.4.3）。 为此我们在统一管理台建了一个「等保安全」控制面，共五个视图（截图均为线上实测，已脱敏）：

等保总览：定级状态 + 法规动态（176 号令倒计时）+ 体检结论双驱动提醒，十大类合规雷达

自动体检：结论必须带证据值

11 项自动体检：读取进程真实配置与请求现场，符合 4 / 不符合 4 / 人工确认 3，每行附证据键值与整改路径

体检的立场是诚实：审计留存 90 天 < 法规底线 180 天就亮"不符合"， 无法自动核查的就给"人工确认"并附核查路径——工具不知道答案时，诚实比好看重要。 好的合规工具应该制造"建设性的不舒服"，而不是用绿灯麻痹运维。

56 控制点自评与台账

三级控制点自评：GB/T 22239-2019 第三级 56 条主控项内置，按类折叠；结论 + 证据留痕；8 个控制点与体检项双向关联，杜绝"页面说符合、配置说不符合"的双口径

等保台账：定级备案 / 测评报告 / 整改 / 年度报送四类条目，到期预警

审计检索（举证）：按域/时间检索安全审计事件，CSV 导出（UTF-8 BOM）；页面如实标注"长期留存举证走审计归档/索引"

07与业界共识的交叉验证

这套设计不是闭门造车。我们对照了 2026 年业界多份 agentic AI 安全指引与研究成果，方向高度收敛：

70%⁵ ≈ 17%

五级 agent 委托链上，单点 70% 拦截率衰减到链端仅 17%（naitive.cloud）——印证通道分离与逐跳签名

78%

生产多 Agent 系统存在 confused deputy 脆弱性——印证"策略活在模型之外"

+20~32 pt

具备证据级审计日志的组织，AI 安全成熟度领先 20–32 个百分点——印证记忆层投入

5 国联合

ASD/CISA/NSA/Cyber Centre/NCSC-UK 指引核心：never grant broad or unrestricted access——与最小授权同源

08收束：五条不变量

如果把这个安全体系压缩成能贴在墙上的五句话：

1. 身份先于消息——双标识分离，逐跳签名，声称不算信任。
2. 通道即边界——数据温度决定通道，白名单决定穿透，失败必须显式。
3. 闸门在模型外——提示词管聪明，配置层管安全，被拒也要留痕。
4. 冷热不互骗——热数据标时效，冷数据可离线，管理台不制造第二权威。
5. 合规是视图——体系做实了，等保条款只是同一套机制的监管语言翻译。

本文涉及的平台组件：org 统一身份签发、A2aAgentIdentity（HMAC 三档放行）、节点桥契约（通道 A/B/C）、 console.ai 统一管理台（等保安全域）、VFS 审计链。文中截图均为线上环境实测（2026-09-29，已对登录态与内部信息脱敏）。

参考与延伸阅读

1. ooder 平台内部文档：《console.ai 节点桥接契约》（通道 A/B/C 与端点白名单约束，2026-09-25）、《Agent 自主开发范围策略》（护栏 DENY 域与统一身份约束，2026-09-16）
2. OODER 工程博客：《分布式 A2A：企业 Agent 基础架构的复杂度与必然性》（三档放行与显式失败的架构复盘，2026-09-28）
3. 公安部网络安全保卫局：《网络安全等级保护 2.0 标准解读》— mps.gov.cn
4. GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》第三级安全通用要求
5. Securing Multi-Agent AI Systems — blog.naitive.cloud（2026-03）
6. Agent-to-Agent Trust and Authorization — zylos.ai（2026-06）
7. Careful Adoption of Agentic AI Services — ASD/ACSC · CISA · NSA · Cyber Centre · NCSC-UK 联合指引（2026-05）
8. Least Privilege for AI Agents (agentic identities + RBAC) — Microsoft Learn, Zero Trust
9. Agentic AI Security Boundaries: Least Privilege, Permission Auditing & Containment — darioiannascoli.it（2026-06）

© 2026 OODER 平台组 · 工程实践总结；等保相关表述为工程口径，现场测评以标准原文与测评机构判定为准。