构建 AI 智能体应用（七）：保护系统安全

Protecting Agentic Systems（Photo by Alvin Leopold on Unsplash）

系列导读: 本文是《Building Applications with AI Agents》系列解读的第七篇。

• 第一篇：核心架构模式演进
• 第二篇：工具选择策略与 MCP
• 第三篇：多智能体协作与编排
• 第四篇：验证与测量
• 第五篇：生产监控与可观测性
• 第六篇：持续改进循环

本篇将聚焦于代理型系统的安全防护，探讨如何从威胁建模到工程闭环，构建可信、可控的 Agentic System。

前置定义（先把词对齐）

• Agentic System（代理型系统）：能够把目标拆解为步骤、调用工具/服务、跨多轮执行并维护状态的系统。关键区别不是“更聪明”，而是“会行动、会委托、会记忆、会串联权限”。
• Tool / Action（工具/动作）：代理在运行时可以调用的外部能力，例如数据库查询、发邮件、改工单、执行代码、下单支付等。
• Planner（规划器）：将目标转为计划并选择工具的模块（可能是同一个 LLM，也可能是多阶段链路）。
• Trust Boundary（信任边界）：系统中“输入/数据/权限”的可信等级分界线。代理系统的痛点在于：LLM 往往把指令与数据混在同一个上下文里处理。
• Memory（记忆）：跨步骤或跨会话持久化的状态，可能是 KV/文档、向量库、知识图谱或数据库记录。记忆带来“可用性”，也带来“持久化攻击面”。
• RAG（Retrieval-Augmented Generation）：检索增强生成。代理从外部知识库/互联网/内部文档检索内容，再作为上下文参与推理。
• Containment（遏制/隔离）：把代理的“可行动范围”限制在可控的执行环境与权限边界内，包括沙箱、网络隔离、最小权限与审批门禁。
• HITL（Human-in-the-Loop）：人在回路。代理在关键决策前请求人工审批或协助。HITL 不是银弹：它也会产生自动化偏见与信任被利用的问题。

1. 引言：为什么“代理安全”是新物种

传统软件安全的核心问题通常围绕：输入验证、鉴权授权、依赖漏洞、注入攻击与数据泄露。代理型系统会把这些问题“放大并串联”，原因在于它具备四种关键能力：

1. 自主性（Autonomy）：它会自己决定下一步做什么。
2. 工具链（Tools）：它可以把语言变成动作（调用 API、执行脚本、修改系统状态）。
3. 持久状态（Memory / RAG）：它会把外部世界带进上下文，也会把上下文写回记忆。
4. 协作与委托（Multi-agent / Delegation）：它能把任务拆分给其他代理或组件，形成链式或网状工作流。

于是攻击者的机会从“让模型说错一句话”升级为“让系统在你权限之上行动”，并且可能：

• 通过 间接 Prompt Injection 把恶意指令埋在网页/文档/邮件里；
• 通过 工具误用 把合法工具变成破坏性动作（删库、批量导出、绕过流程）；
• 通过 身份与权限滥用 取得代理的调用凭证；
• 通过 记忆投毒 获得跨会话持久控制；
• 通过 多代理传播 触发级联失效或横向移动。

2026 年的主流共识是：代理安全必须是“持续迭代、主动防御、分层治理、身份为中心”的组合拳，而不是一次性的 prompt 修补。与此同时，标准与治理也在加速推进，例如 NIST/CAISI 围绕 AI Agent Systems 安全发布 RFI 征集产业与学术输入，这意味着“可验证、可审计、可对齐”的工程实践会越来越重要（见参考资料）。

延伸阅读：NIST/CAISI AI Agent Security RFI：https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems

2. 代理系统的独特风险：能力与失效模式

这一章不从“攻击”开始，而从“系统为什么会失控”开始。理解失效模式，才能把防护点放在正确的层级。

2.1 目标不一致（Goal Misalignment）

含义：代理对“目标”的解释与设计者意图发生偏差，尤其当目标含糊、约束不清或指标单一（如只优化效率/转化率）。

典型表现：

• 为了完成 KPI，选择“灰色路径”（绕过审批、过度采集数据、做不该做的动作）。
• 在多目标冲突时，默认牺牲安全（例如“先把工单关掉”比“先核验事实”更快）。

工程缓解思路：

• 把目标写成“可验证的成功判据”，而不是一句口号。
• 设计“硬约束”与“软约束”：硬约束用策略引擎强制（禁止动作），软约束用评估与告警驱动（质量/合规评分）。
• 给出明确升级路径：无法确认时转人工、转只读模式、或降级到更短链路。

2.2 概率推理与幻觉（Probabilistic Reasoning & Hallucination）

代理系统不是确定性程序：同样输入在不同上下文、不同温度、不同模型版本下，可能产生不同计划与输出。风险不是“会错”，而是“错得很像真的”，并且可能推动工具执行错误动作。

工程缓解思路：

• 将“生成”与“执行”解耦：生成计划不等于立刻执行。
• 关键动作前做校验：例如二次检索、规则验证、或在工具层做参数约束与回显确认。
• 为高风险动作引入多重证据：至少包含来源引用、工具返回值、以及策略允许的操作范围。

2.3 动态自适应（Dynamic Adaptation）

代理会根据环境变化调整策略，这使得控制与测试更难：工具 API 的字段变化、权限策略变化、数据分布漂移，都可能导致“慢性退化”或突然失控。

工程缓解思路：

• 把版本维度纳入可观测性：prompt 版本、模型版本、工具版本必须可追溯。
• 用 Shadow/Canary + 门禁指标发布代理行为（不是只发布代码）。
• 把生产失败链路固化为回归样本，避免“修一次、过几周又复发”。

2.4 视野受限（Limited Context / Partial Observability）

代理常常在信息不完整的情况下做决定：它看到的上下文可能缺关键字段，或者检索结果被污染、过期、片面。视野受限会促使代理“补全空白”，从而引发错误推理与误动作。

工程缓解思路：

• 明确“不确定性协议”：要求代理在缺信息时提出澄清问题或进入只读/咨询模式。
• 对检索与外部数据设置信任边界：把“数据”当作不可信输入处理，而不是当作系统指令。

2.5 人在回路（HITL）的新脆弱性

HITL 常被当作“安全阀”，但它也会引入可预测的人类弱点：

• 自动化偏见：人类倾向于相信“看起来很自信”的输出。
• 警报疲劳：过多的低价值告警会淹没关键告警。
• 技能退化：长期依赖代理导致人工介入能力下降。
• 激励错位：业务效率与安全合规之间冲突，导致审批形同虚设。

工程缓解思路：

• 审批不是“点同意”，而是“可解释的证据包”：计划、参数、影响面、回滚方案、证据来源。
• 设计分级门禁：仅对高风险动作触发 HITL，其他动作走自动化策略与审计。
• 通过演练/CTF 训练“识别提示注入与社会工程”的能力（把监督者也当成需要训练的对象）。

2.6 过度自治与缺乏遏制（Excessive Agency & Lack of Containment）

当代理被赋予“太多工具 + 太高权限 + 太少约束”，它就从“助手”变成“高能执行体”。这类风险在多代理环境更明显：某个代理的偏差会被传播、放大并级联。

核心原则：有界自治（Bounded Autonomy）。自治不是开关，而是一组边界：预算、权限、可执行动作集合、失败次数阈值、以及升级与降级策略。

3. 新兴威胁向量：从 Prompt Injection 到 Promptware

这一章将威胁按“可攻击面”拆解，并把每类威胁映射到工程控制点。

3.1 输入面：直接 Prompt Injection

机制：攻击者在用户输入中显式插入“覆盖指令”，诱导代理忽略系统目标与约束。

风险点：

• 系统与用户指令的优先级被覆盖。
• 代理被诱导泄露系统提示、密钥、内部策略或执行不当工具调用。

防御点（方向）：

• 输入归一化与规则化：拒绝明显的控制词模式只是底线，更重要是“把指令与数据分离”。
• 工具调用必须经策略层审批：哪怕文本被注入，工具层也不应允许越权动作。

3.2 检索面：间接 Prompt Injection（Indirect）

机制：攻击者把恶意指令藏在网页、文档、邮件或图片里，代理检索/解析后把它当作上下文的一部分，从而被“环境”劫持。

风险点：

• 代理把外部内容当成“可信指令”。
• 多步链路导致注入难以追溯（从检索 → 总结 → 写入记忆 → 未来触发）。

防御点（方向）：

• 检索内容在进入上下文前需要“降权与隔离”：明确标注为不可信数据域。
• 检索源分级：签名来源、内部知识库与互联网内容应有不同的策略。
• 对“写入记忆”的动作设置更高门槛（见 3.5）。

3.3 结构化/JSON 注入（Structured / JSON-based）

机制：把恶意指令伪装成“日志、配置、系统消息、JSON 字段”，利用模型对结构化文本的权威感进行欺骗。

防御点（方向）：

• 对结构化输入执行严格 schema 校验与字段白名单。
• 将“模型可见内容”限制为必要字段；对高风险字段脱敏或不提供。

3.4 越狱、社会工程与逃避攻击（Jailbreaking / Social Engineering / Evasion）

机制：通过角色扮演、混淆编码、分步诱导等方式绕过安全策略；或反过来操纵人类审批者（HITL）完成越权动作。

防御点（方向）：

• 将“安全策略”下沉到执行层：审批门禁、权限系统、审计与回滚。
• 对高风险动作的审批提供强证据，减少“话术说服”空间。

3.5 记忆投毒与破坏（Memory Poisoning & Corruption）

机制：攻击者诱导代理把恶意内容写入长期记忆（向量库、偏好记录、知识库），从而实现跨会话持久影响。

典型后果：

• 行为慢性漂移：代理越来越偏离原目标。
• 持久化控制：每次会话都被同一段“被污染记忆”影响。

防御点（方向）：

• 记忆写入必须是显式策略：谁能写、写什么、写入前校验、写入后可追溯。
• 记忆分区与 TTL：把“偏好”“事实知识”“短期工作缓存”分开，降低污染半径。
• 对记忆检索内容做二次过滤与来源显示：让系统与人都能看见“这条记忆来自哪里”。

3.6 工具误用与意外代码执行（Tool Misuse / Unexpected Code Execution）

机制：代理被诱导滥用合法工具，或通过自然语言驱动执行路径触发 RCE/脚本执行/危险 API。

防御点（方向）：

• 工具能力最小化：把“万能工具”拆成“只读工具/受限写工具/高风险写工具”。
• 受控执行环境：容器/沙箱/网络隔离；对文件系统、网络出口、进程权限做硬限制。
• 参数与影响面验证：写操作必须回显变更摘要，并可一键回滚。

3.7 代理间攻击与不安全通信（Inter-Agent Attacks / Insecure Inter-Agent Communication）

机制：攻击者伪造代理间消息、污染共享黑板/任务队列、诱导代理互相传播恶意上下文。

防御点（方向）：

• 代理间通信必须有身份、签名与授权（谁能对谁说什么）。
• 把共享上下文当作不可信输入：任何代理写入的内容，都需要被消费方校验。

3.8 多代理工作流级联失效（Cascading Failures）

机制：多步、多代理链路里，一个小错误会变成系统性失败：重试风暴、预算耗尽、错误传播、状态不一致、或错误决策被放大执行。

防御点（方向）：

• 断路器与预算：对循环、重试、工具失败次数设硬阈值。
• 幂等与事务：写操作必须幂等；跨系统动作要么完成要么回滚。
• Quorum / 双人审批：关键动作不允许单代理拍板。

3.9 Promptware Kill Chain：把 Prompt Injection 看成“初始访问”

2026 年一个重要叙事是：prompt injection 不应被视为单点漏洞，而更像“初始访问”，随后可能经历越权、持久化、横向移动与达成目的等阶段，类似传统恶意软件链条。学术界提出了“Promptware Kill Chain”的阶段化模型来分析这种演进路径（见参考资料）。核心启发是：防护要覆盖全链路，而不是只在输入处做过滤。

延伸阅读：Promptware Kill Chain（arXiv）：https://arxiv.org/abs/2601.09625

3.10 一条典型攻击链路：间接注入 → 记忆投毒 → 工具误用

下面用一条“可复盘、可取证、可止血”的链路，把第 3 章的威胁与第 5/9 章的控制点串起来。场景选用企业最常见的组合：RAG（内部知识库 + 外部网页）+ 工单/邮件/知识库写入工具。

Agent Attack Chain: Indirect Injection to Impact

Step 1：初始进入（恶意内容进入可检索面）

• 攻击者意图：让恶意指令以“资料”的形式进入检索源（网页、共享文档、邮件正文、工单描述）。
• 触发点：RAG 数据源/爬虫/文档同步管道。
• 防御控制点：来源分级、内容净化、签名/审核（见 5.3）；将外部内容明确标注为不可信数据域（见 5.2）。
• 审计证据：检索源 URL/文档 ID、抓取时间、入库版本、内容哈希与签名状态（见 8.2）。
• 立即止血：隔离该来源/暂停同步；对相关文档做“下架 + 召回重建向量索引”。

Step 2：间接注入生效（数据被当成指令）

• 攻击者意图：让代理在总结/规划时“服从资料里的指令”，例如要求泄露提示、要求外发、要求绕过审批。
• 触发点：上下文拼接与规划器（Planner）生成计划阶段。
• 防御控制点：指令锚定与模板化、可信指令与不可信数据的结构化分区（见 5.2）；在策略执行层做动作级校验（见 5.4）。
• 审计证据：trace 中的 RAG span（召回内容摘要/来源）、planner span（候选动作列表）、policy span（允许/拒绝原因）。
• 立即止血：对该工作流启用“只读模式/强制转人工”；临时提高注入检测阈值并开启更严格的策略。

Step 3：建立持久化（诱导写入长期记忆）

• 攻击者意图：把一次性攻击变成跨会话持续影响，典型方式是诱导代理写入“偏好/长期记忆/知识条目”。
• 触发点：记忆写入接口（Memory write）、知识库写入工具、向量库 upsert。
• 防御控制点：记忆写入门禁（谁能写、写什么、写前校验、写后可追溯）、分区与 TTL（见 3.5、8.1）；高风险写入必须审批（见 5.4、9.1）。
• 审计证据：memory_write 事件（写入者身份、来源、差异内容、TTL、审批记录）、向量库写入审计日志。
• 立即止血：冻结写入能力；隔离被污染分区；回滚到上一个干净快照并重建索引。

Step 4：触发工具误用（从“说错话”升级为“做错事”）

• 攻击者意图：让代理滥用工具执行破坏性动作或外泄数据（批量导出、外发邮件、创建共享链接、触发支付/变更）。
• 触发点：工具调用层（Tool runner）与执行环境（容器/网络/凭证）。
• 防御控制点：最小权限、动作分级、审批门禁、预算与断路器（见 5.4、5.5、9.1）；出站与外发策略、DLP（见 5.6、9.2）。
• 审计证据：tool_call 记录（参数、返回值、影响面摘要）、凭证签发日志、外发阻断日志、DLP 命中详情。
• 立即止血：吊销短期凭证、封禁高风险工具、阻断出站；必要时隔离代理运行环境。

Step 5：复盘与防复发（把事故变成门禁与回归资产）

• 目标：避免“修完 prompt 过几周又复发”。
• 固化产物：
  • 红队回归用例：把本次链路的关键输入与证据包脱敏后进入回归集（见 6 章）。
  • 发布门禁：新增“记忆写入/外发/批量导出”变更必须过门禁（见 7.2、附录 B.1）。
  • 指标告警：将注入命中、memory_write 异常、工具误用拒绝率等纳入最小指标集（见附录 B.1）。

4. 保障基础模型安全：选型与部署策略

代理系统的安全基线，首先来自“选对模型 + 用对模型”。模型越强，通常越能完成复杂规划，也越可能产生不可预测行为；模型越弱，越可控，但可能无法处理复杂任务。关键是把模型放在适合它的风险区间里。

4.1 模型选择的工程维度

• 能力匹配：是否真的需要强规划与长链路工具调用？不需要就别上“强自治”。
• 透明度与可审计性：开源权重便于审计但需要更多自建防护；闭源 API 往往有内置策略，但可解释性与可控性受限。
• 部署形态：本地/隔离部署有利于数据边界与合规；云部署要把身份、网络与日志治理做到位。
• 合规契合：隐私法规、行业合规、审计要求往往决定“能不能把某些数据喂给模型”。

4.2 混合模型策略（Hybrid）

常见可靠模式是“分层用模”：

• 高风险动作前：用更小、更可控的模型做校验/分类/规则判断。
• 创造性与复杂推理：用大模型完成规划与解释，但把执行权收紧在策略层与工具层。

4.3 持续迭代：把评估当作发布门禁

模型版本、提示版本、工具版本都在变，安全必须跟随变更持续回归：

• 每次变更都要能回答：成功率、成本、误动作率是否退化？
• 关键场景要有回归集：包括对抗样本、边缘样本与历史事故样本。

5. 防御技术：多层防御体系（可落地架构）

代理安全的核心不是“一个 guardrail”，而是“多层控制点 + 明确边界”。下面给出一个可落地的参考架构，把防御分成七层。

Multi-layer Defense Architecture for Agentic Systems

5.1 输入净化与验证（Input Sanitization & Validation）

目标：把输入从“任意自然语言”变成“可控的协议”，并且避免敏感信息在日志与上下文里扩散。

落地要点：

• 归一化（Unicode、空白、控制字符）与长度限制。
• PII/敏感字段脱敏：脱敏要在进入上下文与日志前完成。
• 结构化输入强校验：JSON/YAML 必须过 schema；未知字段拒绝或剥离。
• 统一入口治理：在入口层引入代理网关/AI 防火墙式组件，集中做限流、脱敏、策略路由与审计，避免防护散落在各个业务服务里难以维护。

5.2 指令锚定与模板化（Instruction Anchoring）

目标：降低模型把“数据当指令”的概率，并把系统目标与约束表达得可执行。

落地要点：

• 模板化系统提示：把目标、约束、可调用工具、禁止动作写成固定结构。
• 把外部数据放入明确的“非指令区”（例如 <UNTRUSTED_DATA> 块），并要求模型只把它当资料引用。
• 把“必须遵守的策略”下沉到策略执行层：不要指望模型自觉遵守。

5.3 RAG 与外部数据的安全治理（Retrieval Security）

目标：把检索当作“供应链”，需要来源、完整性与隔离。

落地要点：

• 来源分级：内部知识库（签名/审核）与互联网内容（不可信）走不同策略。
• 内容净化：对检索内容做注入特征扫描、链接策略、脚本片段剥离、以及敏感信息屏蔽。
• 回显来源：输出必须能追溯引用了哪些文档/段落，便于审计与纠错。

5.4 策略执行层（Policy Enforcement）：让“行动”可控

这是代理安全的核心层：无论文本如何被劫持，执行层都不应越权。

落地要点：

• RBAC/ABAC：按角色/属性对工具动作授权（读/写/删/批量导出/外发等）。
• 有界自治：预算（token/时间/步骤/重试次数）、断路器（连续失败停止）、以及降级路径。
• 审批门禁：高风险动作必须产生证据包并可回滚。

5.5 工具执行环境：沙箱化与最小权限（Sandbox & Least Privilege）

落地要点：

• 网络：默认无外网，仅允许到白名单域名；出站代理统一审计。
• 凭证：短期凭证、细粒度 scope、按工具分配；避免长寿命 API Key；对高风险调用可引入“持有证明（proof-of-possession）”式令牌，降低令牌被窃取后的可滥用性。
• 文件系统与进程：容器隔离、只读根文件系统、禁止任意 shell（或严格限制）。

5.6 输出过滤与数据泄露防护（Output Filtering / DLP）

落地要点：

• 输出格式校验：结构化输出必须符合 schema；非结构化输出做敏感信息扫描。
• 最小披露：默认不输出内部系统提示、凭证、或可用于进一步攻击的细节。
• 高风险场景要求引用证据：降低幻觉带来的误决策。

5.7 新兴机制：模型级与系统级防御怎么用

研究与产业界出现了两类典型方向：

• 模型级防御（Model-level）：通过训练/对齐让模型更能抵抗注入，例如 SecAlign（基于偏好优化的防御思路，见参考资料）。
• 系统级防御（System-level）：在模型外构建安全层，把不可信数据的影响限制在可控范围，例如 CaMeL 提出的 capability/信息流控制式思路（见参考资料）。

延伸阅读：

• SecAlign（arXiv）：https://arxiv.org/html/2410.05451v2
• CaMeL（arXiv）：https://arxiv.org/abs/2503.18813

工程建议：把这些方法当作“增强层”，而不是替代 RBAC、网络隔离、审计与回滚等基础工程控制。

5.8 提示与策略“作为工件”管理（Prompt/Policy as Artifact）

代理系统的行为很大程度上由提示模板、工具描述、策略规则共同决定。把它们当成“代码工件”管理，能显著降低无意变更带来的安全回归：

• 版本化：提示模板、工具 schema、策略规则都有版本号与变更记录。
• 评审与门禁：变更必须通过代码审查与回归集验证（尤其是新增工具、写权限、外发能力）。
• 元数据：记录适用工作流、风险等级、允许的工具集合、以及依赖的外部系统版本。
• 回滚：提示/策略同样要支持快速回滚，而不是只能回滚代码。

6. 红队测试：把攻击面变成回归资产

红队的价值不只是“找漏洞”，更是把漏洞变成可以被持续修复与回归验证的资产。

6.1 迭代生命周期（闭环）

1. 规划：确定高风险工作流、资产与信任边界。
2. 执行：生成对抗输入、间接注入样本、多步链路操纵样本。
3. 评估：按成功判据统计攻击成功率（ASR）、误动作率、外泄率等。
4. 缓解：修策略/修工具/修隔离/修提示模板。
5. 反馈：把失败链路固化为回归集，并纳入发布门禁。

6.2 红队场景库（建议最小集）

• 注入：直接/间接/结构化注入，跨工具链路传播。
• 工具误用：合法 API 被诱导用于破坏性目的（批量导出、批量删除、外发邮件）。
• 记忆投毒：诱导写入偏好/知识，后续触发。
• 代理间攻击：伪造消息、污染共享黑板/任务队列。
• 级联失效：重试风暴、循环、预算耗尽、状态不一致。
• HITL 信任利用：用“看起来合理的解释”诱导人工批准高风险动作。

6.3 工具生态（只给“用途分类”，不硬绑定某个产品）

你会看到一批面向 LLM/Agent 的红队工具与基准在持续演进（例如 Garak、PyRIT、Promptfoo、Giskard 等），以及面向战术/技术复用的框架（如 MITRE ATLAS）。工程上更重要的是把它们接入你的闭环：把测试结果变成门禁，把失败样本变成回归集；并在类生产环境结合混沌工程注入延迟、故障与漂移来验证“可恢复性”。

7. MAESTRO 威胁建模：把安全变成持续属性

传统威胁建模（如 STRIDE）擅长分析确定性系统，但在代理场景容易遗漏“自治、非确定性、无清晰指令/数据边界、以及多代理级联”。MAESTRO 的核心贡献是：用分层架构把代理系统拆解为可定位的控制点，并强调跨层级联风险。

7.1 MAESTRO 七层（工程化理解）

常见解释方式是把系统按依赖向上堆叠：

1. Foundation Models（基础模型）
2. Data Operations（数据运营：采集/清洗/存储/检索/向量库）
3. Agent Frameworks（代理框架：编排、记忆、工具调用机制）
4. Deployment & Infrastructure（部署与基础设施）
5. Evaluation & Observability（评估与可观测）
6. Security & Compliance（安全与合规控制）
7. Agent Ecosystem（生态：多代理/多租户/第三方插件与协议）

CSA 的 MAESTRO Threat Analyzer 仓库提供了工具化示例与分层分析思路（见参考资料）。

7.2 把威胁建模接入 CI/CD（最小可行做法）

• Threat Model as Code：把关键工作流、工具清单、权限与信任边界以结构化文件管理，并跟随 PR 变更。
• Threat Diff：每次 PR 计算“新增工具/新增数据源/新增写权限/新增外发渠道”并触发审查。
• 阻断规则：新增高风险能力（例如外发、批量导出、执行代码）必须通过红队回归集与审批流程。
• 节奏：季度更新模型与威胁库；重大变更走 Shadow/Canary。

社区也在探索自动化的“Threat In / Threat Out”式工具化路径（例如以 TITO 为名的实践讨论，见参考资料），工程上可把它视作“辅助生成与 diff 的工具”，而不是替代人工建模。

延伸阅读：

• CSA MAESTRO（repo）：https://github.com/CloudSecurityAlliance/MAESTRO
• MAESTRO × TITO（社区实践示例）：https://kenhuangus.substack.com/p/applying-maestro-to-real-world-agentic

8. 保护数据：机密性、完整性、溯源与最小化

代理系统的数据风险不只在“泄露”，还在“被污染后引导错误行动”。

8.1 机密性（Confidentiality）

• 静态加密：数据库、对象存储、向量库按数据等级加密（算法不展开，关键是密钥管理与访问控制）。
• 传输加密：服务间 mTLS；对高敏链路使用双向认证与最小信任域。
• 数据最小化：不把不必要的敏感字段喂给模型；不把不必要的输出写入日志与记忆。
• 保留与删除：日志/记忆/缓存有明确 TTL 与销毁策略，避免“历史上下文变成永恒攻击面”。

8.2 完整性与溯源（Integrity & Provenance）

• 内容哈希与签名：关键文档、配置、提示模板、工具描述等都应具备可校验的完整性元数据。
• 不可变审计：关键动作写入仅追加日志，确保可取证与可追溯。
• 检索与向量库治理：对入库与更新设置门禁，避免被投毒；对检索结果保留来源与版本信息。

8.3 处理敏感数据（Policy）

• RBAC/ABAC：敏感字段按角色、租户、场景做最小披露。
• 日志净化：默认不记录明文 PII/密钥/内部提示；需要排障时走受控权限与审计。
• 跨代理共享协议：共享不是复制；共享应带来源、权限与用途限制。

9. 代理系统安全保障：外部威胁 + 内部故障

这一章把“防护措施”拆成两类：防外敌与防内伤。代理系统的事故里，两者往往同时存在。

9.1 保障措施（Guardrails）：让代理“可控、可审计、可回滚”

• 角色与权限：按代理职责分配最小权限，避免“一个代理拿全权限”。
• 行为约束：策略执行层对每个动作做校验，必要时审批。
• 环境隔离：沙箱/容器/网络分段限制爆炸半径。
• I/O 验证：输入与输出都要过验证与脱敏；写操作要可回滚。
• 异常检测：监控循环、重试风暴、异常外发、工具调用结构突变。
• 故障安全回退：遇到不确定、失败或风险高时，降级、停止或转人工。

9.2 外部威胁防护：网络、供应链与对抗输入

• 网络分段：面向公众的入口与内部数据/工具隔离，最小化横向移动路径。
• 防火墙/IDPS/WAF：针对外部交互面做流量治理与阻断。
• 供应链安全：SBOM/SCA、依赖签名校验、最小依赖面，避免“代理框架/插件”成为入口。
• 蜜罐令牌：在高风险数据流中布置可追踪的假敏感信息，用于发现外泄与越权访问。
• 事件响应：预先定义“隔离代理、吊销凭证、回滚版本、封禁工具”的流程。

9.3 内部故障防护：目标、状态与级联

内部故障的危险之处在于：它们可能绕过外部防线，并在多代理工作流中扩散。

关键机制：

• 目标一致性约束：把约束写成可执行策略，不靠“提示语气”。
• 错误处理：工具失败要有重试退避、断路器与降级路径。
• 状态一致性：幂等、事务、锁/租约，避免竞态导致的错误扩散。
• 依赖隔离：插件/第三方服务故障不能拖垮全局。
• 法定人数决策：关键决策由多代理/多策略投票或双人审批，减少单点失误。
• 混沌工程：在类生产环境注入延迟、错误、漂移与权限变更，验证恢复与回滚能力。

9.4 身份为中心治理：把代理视为“一流身份”

代理本质上是“会行动的数字实体”。把它当作脚本或匿名服务账号，会直接放大 Identity & Privilege Abuse 风险。业界提出“Agentic Identity”的策略组合，核心思想是：为每个代理建立可追溯的身份生命周期、最小权限与委托链路（见参考资料中的 Strata 系列文章）。

延伸阅读：Strata Agentic Identity（8 strategies）：https://www.strata.io/blog/agentic-identity/8-strategies-for-ai-agent-security-in-2025/

可落地的实践方向：

• 临时身份与短期凭证：按任务发放、到期即失效。
• 运行时动态授权：每次动作都基于上下文评估（目的、工具、数据等级、风险分级）。
• 委托可追溯：谁委托了代理、代理又委托给谁、做了哪些动作，全链路可审计。
• 跨环境一致策略：混合/离线/跨云环境中保持同一套策略语义。

10. 结论与展望

代理型系统的安全目标不是“消灭所有不确定性”，而是把不确定性关进笼子里：让自治有边界、让行动可验证、让风险可观测、让事故可回滚、让组织能持续学习。

2026 年的可执行共识可以浓缩为三条主线：

1. 分层防御：输入、检索、规划、执行、输出、观测、数据与身份都要有控制点。
2. 持续红队 + 持续建模：把威胁建模与红队产出变成回归集与发布门禁。
3. 身份为中心治理：代理是新型数字劳动力，必须拥有一流身份与授权体系。

附录 A：术语表（快速对齐）

附录 B：落地 Checklist（从最小可行到生产级）

• 设计期
  • 定义工作流成功判据与高风险动作清单
  • 明确信任边界：哪些数据不可信、哪些动作需要审批
  • 设计有界自治：预算/阈值/断路器/降级路径
• 构建期
  • 工具分级：只读/受限写/高风险写
  • 策略执行层落地：RBAC/ABAC、审计、回滚
  • 威胁建模与红队用例纳入 PR 流程（Threat Diff + 回归门禁）
• 运行期
  • 观测与审计：版本维度可追溯（prompt/model/tool）
  • 异常检测：循环、重试风暴、外发、权限异常
  • 事件响应：隔离代理、吊销凭证、回滚版本、封禁工具

B.1 最小指标集（MVI）与告警/门禁动作（可直接落地）

这张表的目的不是提供“拍脑袋阈值”，而是提供一套最小闭环：你能采集、能归因、能触发动作，并能在发布时做门禁对比。阈值建议优先采用“相对基线（baseline）变化”与“分级响应”，避免因业务差异导致不可用。

附录 C：常见坑与反模式

• 只做 prompt 工程、不做执行层权限：注入一旦成功就能直接“行动”。
• 给代理发长期 API Key：一旦泄露，等价于永久后门。
• 把外部检索内容当作可信指令：间接注入几乎必然命中。
• 让代理写入记忆不设门槛：把一次攻击变成持久控制。
• 没有回滚与断路器：小故障会被多代理链路放大成事故。
• 日志不脱敏：为了排障把敏感信息写进观测系统，最后变合规事故。

参考资料

• OWASP Agentic Top 10
  • OWASP Top 10 for Agentic Applications for 2026
  • OWASP Top 10 for Agentic Applications: The Benchmark for Agentic Security
  • OWASP GenAI Security Project Releases Top 10 Risks
• MAESTRO
  • CSA MAESTRO Framework (GitHub)
  • Applying MAESTRO to Real World Agentic (Community Practice)
• NIST/CAISI
  • NIST/CAISI AI Agent Security RFI
• Academic Research
  • SecAlign: Prompt Injection Defense (arXiv)
  • CaMeL: Capability/Information Flow Control (arXiv)
  • Promptware Kill Chain (arXiv)
• Industry Frameworks
  • MITRE ATLAS
  • Strata Agentic Identity Strategies