智能体出厂时，安全应该已经装在哪儿？——智能体\"内生安全\"的功能要求与工程落地

原创

看破
看破

Cybersecurity Architecture

2026年10月16日 07:53
北京

去阅读

引子：为什么安全不能后装

回到技术本质，AI 智能体仍然是一类应用软件：依托操作系统运行，调用系统资源，访问网络与本地文件，执行代码与指令。所以它并不会因为\"AI\"这个前缀就自动免疫权限滥用、数据泄露、未授权访问这些老问题。

但智能体和传统软件有一个根本差别：传统软件的行为在发布时就确定了，智能体的行为在运行时才生成。它不再是逐行执行预设代码的被动程序，而是具备自主决策、工具调用、记忆存储与逻辑推理的实体。

这个差别决定了安全该装在哪儿。

传统软件可以主要靠外部防护——防火墙、WAF、运行时监控。这些手段之所以有效，是因为它们保护的对象行为可预期，边界画得住。智能体不行：它的下一步动作是这一轮推理的产物，外部设备看不到推理过程，只能在动作已经生成之后才介入，而那时候已经晚了——动作已经带着参数走到了工具调用这一层。

所以安全必须出场自带。这就是业内说的内生安全：不是事后加在智能体身上的一层壳，而是它出厂时就装在系统里的机制。

于是问题变得很具体：智能体出厂的时候，安全应该已经装在哪儿？

一、先看清要兜住什么：OWASP 2026 十大风险

2026 年 8 月，OWASP 发布最新版《OWASP Top 10 for LLM Applications》，梳理了大模型及智能体应用的十大核心风险。这份清单是制定出厂要求的输入——先明确要兜住什么，再谈配什么功能。

最右一列请留意：它是全文的索引。后面每一条要求都有编号，可以反向追到它兜的是哪一条风险；反过来，风险表里每一条也能查到由哪些要求覆盖。能双向追溯的清单才是可验收的清单，反之只是愿望。

这十条还有一个共同点：它们都不是代码写错了。传统软件的漏洞有 CVE 可对应，可以靠补丁修；这十条里没有一条对应某个具体的代码缺陷，它们来自智能体自主决策、动态交互的架构本身：

• 指令传播无法静态追踪。模型的黑盒特性，让安全团队无法在事前穷举\"这段输入会导致什么动作\"。
• 上下文每次都是新的。每一次交互生成全新上下文，静态规则覆盖不了动态场景。
• 交互面天然很大。外部工具、知识库、接口越多，攻击的入口越多。

所以业内有一个判断正在成为共识：智能体的安全风险已经从传统软件的\"代码漏洞范式\"，转向了\"架构缺陷范式\"。范式变了，对策的位置也得变——补丁打在代码上没用，机制必须长在架构里，而且出厂时就得在。

下面拆成两份清单：R 系列是按数据流位置排的功能要求，回答\"每个节点必须具备什么能力\"；G 系列是贯穿全局的五条约束，回答\"整套设计按什么标准验收\"。

二、出厂必备：六组功能要求（R1–R21）

智能体处理一次任务，数据依次经过六个位置。每个位置必备的能力如下，共 21 条。每条附一句验收判据——都是二值问题，答不上\"是\"，这条就没做。

2.1 身份层

2.2 入口层

R4 里的\"可信标记\"是整个清单的分水岭。模型判断的是\"这句话像不像攻击\"，标记记录的是\"这句话从哪来\"——后者才是确定的。所以这一条不靠模型实现。

2.3 工具调用层

2.4 执行层

R12 里的\"档位\"，建议按下面四档配置，而不是按调用逐个审批：

R14 那句判据容易被忽略，却是这条要求的实质：如果每三次调用就弹一次确认，操作员第二天就会变成无脑点击，这一层就此消失。把\"需要人工确认\"当成安全感的来源，是最常见的一种自欺。

2.5 记忆层

R18 的取舍要说清楚：记忆污染不可逆，清除成本远高于拒收成本，所以缺省动作是拒，不是存。

2.6 审计层

R19 是最常被漏的一条。很多方案只记\"执行了什么\"，不记\"模型原本想执行什么\"——于是一次成功的拦截和一次根本没发生的意图，在日志里长得一模一样。

三、验收标准：贯穿全局的五条约束（G1–G5）

上面 21 条是按位置列的交付清单。下面五条不专属任何位置，是验收尺子：它们不新增功能，而是给出\"前面那些做到了没有、做得够不够\"的判断标准。每一条都标注了它约束哪些 R。

G5 需要额外提醒一句，否则很容易被误用：写进提示词的部分属于默认配置，是五条里最弱的一条。它能降低误触发的概率，但不能作为唯一依赖——真正兜底的是同一条里被它约束的 R14 与 R19：二次鉴权无确认不执行，全流程审计留存形成不可篡改的证据链。

一句话概括两份清单的关系：R 系列是\"要装什么\"，G 系列是\"做到什么程度算数\"。

两份清单合起来有三个用法，都不需要额外工具：

• 设计评审：逐条过 R 系列，每条只问验收判据那一句，不许展开讨论。答不上\"是\"的，进待办而不是进 PPT。
• 上线卡口：把 G 系列做成发布前的检查项。G 只有五条，适合当闸门；R 有 21 条，适合当台账。
• 事故复盘：从日志里的异常动作往回查，是 R 里哪一条没实现，还是实现了但 G 里的验收标准放得太松。

用法上的差别也就是两份清单的分工：台账负责不遗漏，闸门负责不放行。

四、落到代码里：五个可插的位置

21 条要求要落地，得有地方插。不管用什么框架，智能体能插安全的位置基本就这五个：

其中两个位置最常被漏掉，值得单独问一句：

post\_model\_pre\_tool 这个位置，你的框架里有没有？ 没有的话，模型输出和真实执行之间没有缝隙，安全只能靠模型自觉。

pre\_egress 是不是独立于工具白名单？ 也就是说，白名单里的工具被诱导去外泄数据，能不能被单独拦住。如果外泄检查等同于工具白名单，那么\"允许的工具\"就等于\"允许的一切\"，R10 这条不存在。

4.1 一个可参考的实现

DeepSeek Harness（DSH）是一款开源、插件化的智能体开发框架，核心设计理念是\"一切皆插件\"——模型适配器、工具注册表、会话日志管理、智能体循环逻辑都可以通过插件组合搭建。模块化的好处是：安全能力不需要改框架核心代码，就能以插件形式插进去，这正是出厂要求理想的工程载体。

社区已经迭代出覆盖多个 hook 点的安全插件：

真正要确认的不是\"装没装这几个插件\"，而是你的框架里这五个位置是否存在，以及里面有没有东西。换成任何框架，都得回答同一个问题。

4.2 这些要求覆盖不到的部分

一份诚实的清单必须写明边界，否则读者会以为 21 条覆盖了全部：

供应链风险（LLM04）：模型来源核验、第三方插件与工具依赖审计，不在运行时控制范围内，需要独立的来源校验与安装前扫描；

训练阶段投毒（LLM05 前半段）：发生在模型交付之前，运行时拦不住；

多智能体之间的信任传递：这套要求只处理单个智能体内部的数据流。

承认边界比声称全覆盖可信——这也是判断一份安全清单是否成熟的简便方法。

结语：原生风险只能靠原生方案兜底

从 2026 版 OWASP LLM Top 10 可以清楚看到一件事：智能体的安全风险已经从传统软件的\"代码漏洞范式\"，转向了\"架构缺陷范式\"。提示词注入、过度代理、记忆污染、向量投毒这些新型风险，没有传统 CVE 可以对应，也就不可能靠打补丁解决。

原生风险只能靠原生方案兜底。身份独立、权限极简、来源追踪、入库准入、全链路审计——这些不再是智能体开发的附加能力，而是它出场时就该自带的配置。把话说到最实处，就是开头那张清单里的 21 条要求，和追问每一条的那些二值判据。

OWASP 项目负责人有一句话讲得很到位：不必执着于打造完全无法被欺骗的模型，而应搭建一套稳健的系统架构，确保模型即便被诱导、被欺骗，核心业务与核心数据也不会崩塌失控。

这句话反过来就是一把尺子：模型被骗是时间问题，问题是它被骗的那一次，这 21 条里还有几条是真的在工作的。

这不需要等下一个漏洞公告。把模型换成攻击者，跑一遍，数一数就知道了。

智能体内生安全 #智能体安全