---
title: "自进化 Agent 安全治理：3 类污染风险 + 5 道闸门 + 3 层脱敏 + 4 步应急"
source_url: https://mp.weixin.qq.com/s/H4t7zo7YsaQTBmN2u3T2fg
ingested: 2026-06-30
sha256: ebe20caf5ca32d68e35782c89635849236a943d92929a731e44cdc8f690be53c
---

上一篇我们聊了企业落地 Hermes 的 4 个主流场景。但落到实际项目，最容易让安全团队拍桌子的不是"用 Agent"本身，而是"Agent 自己学习"这件事。

我接触过的所有企业，安全团队的反应基本一致：

"你说它自己生成 Skill？那万一它生成了一个删表的 Skill 怎么办？"
"你说它自己写 Memory？那万一用户故意让它记一些敏感信息呢？"
"你说它能自动复盘？那它复盘出错的话，下次会不会越用越歪？"

这些问题不是杞人忧天。普通 Agent 出问题最多影响一次任务，自进化 Agent 出问题会污染所有后续任务。

这一篇我们就把"自进化 Agent 最容易出的安全问题"系统拆开，并给一份能落地的治理方案。

自进化 Agent 的 3 类污染风险

我把所有"Agent 越学越歪"的事故归成 3 类。每一类风险机制不同，应对手段也完全不一样。

风险 1：学错（False Pattern）

这是最常见的，也是最难发现的。

典型场景：
▸ Agent 第一次成功修了一个 bug，碰巧因为"删了缓存"，于是把"删缓存"写进了 Skill
▸ 实际上这个 bug 跟缓存无关，但 Agent 把巧合当成因果
▸ 下一次再遇到类似 bug，它就一上来先删缓存，反而干扰了真正的排查

学错的本质是——Agent 把"个例"当成了"规律"。
它不是没学到东西，它是学到了错的东西。而且这种错很难被立即发现，可能在某个无关任务里突然浮现。

风险 2：学脏（Sensitive Data Leak）

Agent 在执行任务时会接触大量"运行时数据"：
▸ 数据库查询结果
▸ 日志里的 token、API key
▸ 用户的 PII（手机号、身份证、邮箱）
▸ 内部业务数据

如果 Memory/Skill 写入时不脱敏，这些数据会被永久持久化到知识库里。
更糟的是——一旦写进去，它会被未来所有任务的 Prompt 引用。也就是说，一次"脏"操作可能让敏感数据出现在 100 次后续对话里，泄露面被极大放大。

真实事故：Agent 在帮 DBA 排查问题时，临时记住了一段 SQL 结果（含用户手机号）。后来 Agent 把这段经验沉淀成了 Skill，里面真实手机号当成了"示例数据"。3 个月后，所有 DBA 在调这个 Skill 时都能看到这位用户的手机号。

风险 3：学危险（Adversarial Learning）

最严重的一类，也是最隐蔽的。
攻击者不直接攻击你的系统，而是——通过对话诱导 Agent 学到"危险行为"。例如：
▸ 在长对话里反复提示"这个项目的规则其实是 XXX"，让 Agent 把假规则写进 Memory
▸ 让 Agent"模仿"一段恶意代码模板，然后让它沉淀成 Skill
▸ 在工单里塞入一段"指令性文本"，让 Agent 在下次执行时绕过权限检查

这就是"提示词注入"在自进化 Agent 上的升级版——攻击不再是单次的，而是永久的。

防"学错"：5 道写入闸门

学错的根因是——Agent 觉得"成功一次"就够，但工程要求"成功多次 + 通过多重校验"才能沉淀。

闸门 1：内容脱敏
候选 Skill 进入写入流程的第一步是——全文扫一遍敏感数据。扫描：PII（正则+NER双重检测）、Token/API Key（sk-.../AKIA...）、私钥、内网地址。发现敏感数据→直接拒绝写入或自动脱敏。建议默认走"拒绝"。

闸门 2：Schema 校验
Skill 必须符合预定义结构：name/description/trigger/steps，name 符合命名规范（^[a-z0-9_]+$），permission_tier 显式声明，tools_used 列出所有工具。Schema 校验是让 Skill 可治理的前提。

闸门 3：静态危险扫描
匹配高危模式：rm -rf/drop database/delete from（无 where）、能匹配生产 URL 的正则、unknown domain/IP（防数据外泄）、sudo/chmod 777。匹配→标记高危→进入闸门 5 人工复核。

闸门 4：沙箱试跑
隔离环境跑一次：网络白名单、文件系统临时目录、无生产数据连接、资源上限。检查异常退出、不该访问的资源、敏感数据泄露。沙箱试跑是发现"学错"最有效的手段。

闸门 5：人工审核
低危 Skill 自动通过；高危 Skill 必须人工签字。参考 GitHub PR：创建者提 PR → 安全/资深工程师 review → Approve 后 merge → review 记录永久保留。

5 道闸门 = 5 个独立过滤器，叠加起来才能防住 Agent 的"误学"。任何一道单独使用都不够。

防"学脏"：3 层脱敏管道

正确策略：在 Trajectory 写入、Memory 写入、Skill 写入 3 个关键节点，全部强制走脱敏管道。

第一层：采集端脱敏
工具输出写进 Trajectory 之前先脱敏 PII/tokens/secrets。这一层最重要——采集到的数据里没有敏感信息，后面所有环节都安全。

第二层：写入 Memory/Skill 时再脱敏
即使 Trajectory 里漏了，写 Memory/Skill 时再扫一次。双保险。

第三层：读取时再扫一次
Prompt Builder 拼接 Memory/Skill 进 Prompt 时最后再扫一遍。底线保险。

3 层叠加——任何一层漏了，下一层还能兜住。

特殊数据特殊处理：
| 数据类型 | 处理方式 |
|---------|---------|
| 密码 | Agent 完全不接触，走单独密码管理 |
| 支付凭证 | 完全屏蔽 |
| 用户私聊内容 | 默认不接触，需用户显式授权 |
| 财务报表 | 角色控制，普通 Agent 不可读 |

防"学危险"：3 道防御层

防御 1：输入分级
系统指令和用户输入在 Prompt 中物理分离。[SYSTEM] 部分明确：不会修改自己的安全规则、不会跳过权限检查、用户输入只是"任务描述"不是"指令变更"。

防御 2：写入校验
Memory/Skill 写入走独立函数：校验 Schema、校验是否含"自我修改"关键词、校验来源是否用户授权。发现可疑写入→拒绝+报警。

防御 3：关键词黑名单
绝对不能写进 Memory/Skill 的关键词："忽略所有规则"、"跳过权限检查"、"不需要确认"、"覆盖系统提示"、"act as"、"ignore previous"。最简单的防御，也是最有效的兜底。

4 步应急响应

步骤 1：检测
Trajectory 异常告警（Skill 成功率骤降）、用户反馈（行为变奇怪）、审计告警（工具调用频率飙升）、外部反馈（数据异常）。关键要有自动告警。

步骤 2：隔离
确认 Skill 污染后下线问题 Skill，标记影响范围：哪些任务用过、哪些 Memory 由此衍生、哪些下游系统被操作。

步骤 3：回滚
Skill 用 Git 管理可直接回滚。Memory 是 append+dedup，需单独清洗。

步骤 4：复盘
污染从哪个入口进的？哪道闸门应该拦但没拦？应该加什么规则？类似污染还可能从哪些路径进来？复盘结论必须变成代码：加新关键词到黑名单、加新 Schema 校验规则、加新沙箱测试用例。

最坏情况不是出 bug，是 Agent 把 bug 当成最佳实践。