大模型安全与智能体对抗实战：从提示词风险到执行级安全控制的全景架构
大模型安全与智能体对抗实战：从提示词风险到执行级安全控制的全景架构
专栏名称：《大模型安全与智能体攻防进阶》
适合读者：AI 架构师、安全工程师、Agent 开发者、技术负责人
关键词：大模型安全、AI Agent、多智能体系统、提示注入、执行护栏、安全治理
专栏定位：面向企业级智能体系统，讨论威胁建模、权限隔离、诱捕监测、执行控制与事件响应。
内容与合规声明
本文讨论的威胁模型、案例和代码仅用于：
- 获得明确授权的安全测试；
- 企业内部防御体系建设；
- 隔离实验环境中的安全研究；
- 智能体（Agent）系统的风险评估与加固。
本文不提供针对真实目标的攻击步骤、绕过方法、恶意载荷或未授权访问方案。文中的攻击方、企业名称、资产名称及事件编号均为虚构示例。
需要特别说明的是，本文提出的是一套防御架构与工程方法，并不意味着部署某个组件后即可自动获得完整的安全保证。实际效果仍需通过威胁建模、代码审计、对抗测试和生产环境监控来验证。
一、为什么智能体安全不能只保护模型接口
传统大模型应用的安全边界主要集中在输入和输出：
用户输入 → 模型推理 → 文本输出
当大模型被升级为能够调用工具的智能体后，系统链路变为：
用户请求
↓
上下文与记忆
↓
模型规划
↓
工具选择
↓
身份鉴权
↓
数据库、文件、消息系统和业务 API
↓
产生真实副作用
风险也随之发生变化。
一段恶意内容可能不再只是影响模型回答，而是进一步改变：
- 智能体选择了什么工具；
- 工具获得了哪些参数；
- 任务是否被转交给其他智能体；
- 敏感数据是否进入日志或上下文；
- 系统是否执行写入、删除、通知或支付操作；
- 异常指令是否通过记忆被后续任务重复使用。
传统安全 vs. 智能体安全对比
二、专栏核心案例：CASE-DEF-0007
全专栏使用同一个虚构案例贯穿各期，避免每篇文章采用不同场景，导致安全对象和防御结论无法衔接。
2.1 案例背景
某企业部署了“星河数字员工”集群，包括：
- 客服智能体
Support Agent； - 数据分析智能体
Data Agent； - 财务辅助智能体
Finance Agent； - 安全监测智能体
SOC Monitor。
这些智能体可以访问知识库、工单系统、内部 API 和部分业务工具。攻击者试图通过受污染的技能内容和上下文诱导，影响多个智能体的决策，并放大其异常操作。
2.2 威胁工单
| 字段 | 内容 |
|---|---|
| 案例编号 | CASE-DEF-0007 |
| 威胁编号 | THREAT-BOT-0007 |
| 防护对象 | 企业级多智能体业务集群 |
| 初始入口 | 第三方技能、文档、提示词等间接输入 |
| 主要风险 | 上下文污染、权限误用、任务传播和异常动作放大 |
| 防御目标 | 发现异常协同行为、隔离可疑任务、阻断高风险副作用 |
| 防御链路 | 监测 → 诱捕 → 裁决 → 阻断 → 审计 → 恢复 |
三、智能体攻防全景架构
这套架构的关键不是部署更多安全组件，而是确保每一次有副作用的动作，都必须经过无法绕开的策略检查。
模型可以提出行动建议，但不能自行决定最终行动。
四、统一对象模型：让多篇文章讨论同一组实体
如果没有统一的对象模型，“提示词攻击”、“工具越权”和“事件响应”很容易变成互不关联的概念。本专栏统一使用以下六类对象。
4.1 ThreatSignal：威胁信号
用于描述异常行为，不直接等同于安全事故。例如：
- 多个智能体在短时间内请求同一敏感能力；
- 上下文中出现来源不明的操作要求；
- 智能体尝试扩大任务范围；
- 工具参数与原始业务目标不一致。
单个信号可能是误报。系统需要结合身份、会话、任务和调用关系进行关联分析。
4.2 CapabilityProfile：能力档案
同一种能力可以服务于正常业务，也可能扩大攻击面。
例如，文件读取能力既可以用于分析日志，也可能导致跨目录访问。能力档案应明确：
- 合法用途；
- 允许访问的资源范围；
- 输入参数约束；
- 所需信任等级；
- 是否允许产生副作用；
- 是否需要人工审批。
4.3 ExecutionInvariant：执行不变量
执行不变量是动作执行前必须始终成立的条件。例如：
目标资源属于当前租户
并且调用者拥有明确权限
并且写操作已被显式声明
并且敏感数据已经脱敏
并且高风险动作取得有效批准
只要其中一项不成立，系统就应拒绝执行、隔离或转入人工复核。
五、A1-A5 冲突裁决协议
智能体安全的难点往往不是“能否发现风险”，而是当安全要求与业务效率冲突时，系统究竟如何决策。
为此，专栏定义五条统一裁决协议。
| 编号 | 协议 | 核心规则 | 对应风险 |
|---|---|---|---|
| A1 | 异常协同断链 | 发现多个智能体同步出现异常行为时，优先阻断任务传播并保留证据 | 多智能体异常放大 |
| A2 | 诱饵严格隔离 | 诱饵可以记录可疑行为，但不得与真实资产、真实凭证或生产网络连通 | 诱捕环境反向扩大风险 |
| A3 | 安全关卡不可绕过 | 调试、内部调用和紧急通道也必须经过最低限度的权限与范围检查 | 快捷通道越权 |
| A4 | 高风险动作强制阻断 | 写入、删除、支付和权限变更等高风险动作必须满足全部执行不变量 | 只告警不拦截 |
| A5 | 按威胁缺口升级 | 优先补齐没有控制措施覆盖的风险，不以组件数量衡量安全成熟度 | 重复建设与防御盲区 |
这些协议需要落实为机器可执行策略，而不能只停留在制度文档中。
六、一次高风险动作如何被裁决
以财务智能体请求执行一项资金相关操作为例：
该流程体现了以下基本原则：
模型负责提出意图，安全控制面负责决定意图是否可以转化为真实动作。
不能将“模型认为合理”直接等同于“系统已经授权”。
七、四层纵深防御
7.1 第一层：输入与上下文治理
负责控制进入模型上下文的信息：
- 标记数据来源；
- 区分系统指令、用户内容和外部文档；
- 对不可信内容进行隔离；
- 限制日志、检索结果和工具返回值中的敏感字段；
- 防止外部文本直接获得高优先级的指令语义。
这一层的目标不是理解所有恶意文本，而是防止不可信数据自动获得控制权。
7.2 第二层：能力与身份治理
每个智能体只获得完成当前任务所需的最小能力：
- 使用短期身份；
- 按任务签发凭证；
- 限制资源范围；
- 禁止跨租户访问；
- 区分读取和写入权限；
- 任务结束后立即吊销凭证。
权限不应来自提示词中的角色声明，而应来自独立的身份系统和策略引擎。
7.3 第三层：执行级强制控制
所有真实副作用必须经过统一关卡：
智能体输出
↓
结构化动作意图
↓
参数校验
↓
身份与授权检查
↓
执行不变量检查
↓
允许、拒绝、隔离或人工审批
这是整个体系最关键的一层。输入检测可能漏报，模型可能误判，但只要高风险动作无法绕过执行关卡，事故影响就能被限制在可控范围内。
7.4 第四层：监测、审计与恢复
系统应记录：
- 谁发起了任务；
- 哪个智能体生成了动作；
- 使用了什么能力；
- 策略为何允许或拒绝该动作；
- 是否触发诱饵；
- 产生了什么外部副作用；
- 任务凭证是否已经吊销。
审计日志应避免直接保存完整的敏感上下文，可采用脱敏字段、摘要和受控证据引用等方式。
四层防御体系架构
八、专栏目录与学习路线
| 期数 | 主题 | 主要问题 | 工程产出 |
|---|---|---|---|
| 第 0 期 | 动态威胁建模 | 智能体系统需要保护什么？ | 对象模型与信任边界 |
| 第 1 期 | 异常协同识别 | 如何发现多智能体异常放大？ | A1 断链策略 |
| 第 2 期 | 隔离诱捕 | 如何记录可疑行为而不影响生产？ | A2 诱饵隔离 |
| 第 3 期 | 源头控制 | 如何减少敏感数据进入上下文？ | 字段级最小可见 |
| 第 4 期 | 能力建模 | 同一工具能力有哪些合法与危险用途？ | CapabilityProfile |
| 第 5 期 | 威胁与控制对账 | 如何发现没有防线承接的风险 | A5 缺口矩阵 |
| 第 6 期 | 上下文隐私 | 如何防止日志和转录内容泄露 | 脱敏与作用域控制 |
| 第 7 期 | 分布式执行关卡 | 为什么单点网关不足以覆盖所有调用 | HarnessGuard |
| 第 8 期 | 执行不变量 | 如何在真实副作用前强制裁决 | ExecutionInvariant |
| 第 9 期 | 持续演进 | 如何将检测、阻断和恢复连成闭环 | 安全运营架构 |
推荐阅读顺序：
建立对象模型（第0期）
↓
理解异常协同与诱捕（第1-2期）
↓
控制数据与能力（第3-4期）
↓
部署执行级关卡（第7-8期）
↓
完成威胁对账与持续演进（第5、6、9期）
九、如何评价这套体系是否真正有效
不能用“部署了多少组件”评价智能体安全。更有意义的是观察控制效果。
| 指标 | 说明 |
|---|---|
| 高风险动作关卡覆盖率 | 写入、删除、支付等动作中经过强制裁决（或审批）的比例 |
| 未授权动作阻断率 | 权限或范围不满足时的实际阻断成功率 |
| 跨租户访问成功率 | 应接近零，并通过对抗测试验证 |
| 异常传播发现时间 | 从首个异常信号到任务链被切断的时间 |
| 误阻断率 | 正常业务被拒绝或转人工的比例 |
| 凭证有效期 | 智能体凭证在被吊销前可能被滥用的最长时间窗口 |
| 审计完整率 | 高风险动作是否具备完整的身份、策略和结果记录 |
| 恢复时间 | 从确认安全事件到完成隔离、凭证吊销和业务恢复的时间 |
安全评估至少应包含：
- 单元测试和策略测试；
- 隔离环境中的对抗测试；
- 典型业务流回归测试；
- 权限绕过测试；
- 诱饵隔离验证；
- 日志脱敏检查；
- 故障和降级场景演练。
安全评估指标可视化
十、常见设计误区
10.1 只在输入端检测提示词
输入检测可以降低风险，但无法覆盖模型内部规划、工具返回内容以及跨智能体消息。高风险动作仍然需要执行级强制控制。
10.2 让模型自行判断是否获得授权
模型可以解释规则，但不应成为权限来源。授权必须由身份系统、策略引擎和资源服务共同执行。
10.3 将告警作为阻断手段
对于写入、删除、支付和权限变更等高危操作，仅记录告警通常不足以控制风险。当高风险条件不满足时，应在操作执行前予以阻断。
10.4 诱饵与生产资源共享凭证
如果诱饵可以访问真实资产，它就不再是安全传感器，而会成为额外的风险入口。诱饵必须使用虚构数据、独立身份和隔离网络。
10.5 用组件数量衡量安全成熟度
多个检测器可能覆盖同一种风险，却仍然遗漏提权或数据泄露。成熟度应以威胁覆盖率、控制措施有效性和恢复能力衡量。
十一、专栏边界
本专栏重点讨论防御架构与工程实现，但不声称能解决所有智能体安全问题。
以下内容仍需要结合具体环境单独验证：
- 模型本身的鲁棒性；
- 第三方模型服务的安全边界；
- 云平台和基础设施漏洞；
- 供应商组件的可信度；
- 法律、隐私与行业合规要求；
- 高并发环境下的性能开销；
- 安全策略误报对业务连续性的影响。
示例代码仅用于解释安全机制。在进入生产环境前，需要补充身份认证、密钥管理、并发控制、异常处理、监控、测试和变更审批等环节。
十二、结语
智能体系统将大模型从“生成内容的软件”转变为“能够发起真实动作的软件”。安全边界因此从模型的输入输出扩展至上下文、记忆、身份、工具、数据以及业务副作用。
一套可落地的智能体安全体系至少需要回答五个问题：
- 外部内容能否改变高优先级指令？
- 智能体可以访问哪些数据？
- 智能体可以调用哪些能力？
- 谁决定高风险动作是否执行？
- 发生异常后能否快速切断链路、追溯和恢复？
本专栏的核心主张可以归纳为一句话：
不要把安全寄托在模型始终作出正确判断上，而要让系统在模型判断失误时仍然守住权限与执行边界。
后续文章将围绕 CASE-DEF-0007，逐步展开威胁信号、诱饵隔离、能力档案、执行关卡和审计响应的实现方式。
互动讨论
你在落地 AI Agent 业务时，遇到过 Prompt 诱导越权 或 多智能体协同攻击 的风险吗？欢迎评论区交流踩坑经验！
更新日志
| 版本号 | 发布日期 | 修订内容 |
|---|---|---|
| v2.0 | 2026-08-17 | 发布，完成项目核心架构评测、安全风险审计与场景落地建议 |
推荐标签：
大模型安全、AI Agent、人工智能、系统架构、安全治理、多智能体系统
更多推荐
30
0- 0
已为社区贡献47条内容
所有评论(0)