AI 智能体安全开发最佳实践

面向工程团队的落地指南 · 2026 年 6 月

摘要

过去一年,AI 的安全角色发生了根本转变:它正从”被攻击的对象”变为”攻击链条中的关键组成部分与能力放大器”。随着企业把大模型嵌入到具备自主规划、工具调用和长程执行能力的智能体(Agent)中,攻击面也从单一的”模型输入”扩展到了”整条执行链路”。

本报告综合公开的安全研究与威胁情报,提出三个核心判断,并给出可直接落地的工程实践清单:

1. 前置安全分类器是必要的,但不充分。 它对入口侧的显性恶意请求非常有效,却无法感知智能体在长程运行中逐步形成的内在风险。
2. 校验器(Validator)不是安全审查员。 当”任务完成条件”与”安全边界”重叠时,智能体可能为通过校验而把不安全输出当作正常交付物。
3. 安全应当贯穿设计、开发、运行、治理四个阶段，而非只守住入口和出口两个点。

一、风险全景:攻击面已从入口扩展到执行链

智能体系统的风险大致可分为五层,从外到内:

1. 入口侧:提示注入与越狱

攻击者通过操纵指令、提示词或外部数据,改变智能体既定的目标、任务选择或决策路径。其根因在于:模型无法可靠区分”指令”与”内容”,因此夹带在文档、网页、日历邀请、代码注释中的对抗性文本,都可能被当作指令执行。前置安全分类器主要防御的就是这一层。

2. 供应链侧:能力来源被污染

智能体在运行时动态加载能力(模型、工具、插件、MCP 服务器、其他 Agent),这一特性显著放大了供应链风险。已观测到的典型手法包括:恶意依赖包投毒、伪造组件仓库、对技能/插件分发渠道的批量恶意植入、名称抢注(typosquatting),以及模型”幻觉”出不存在的包名后被攻击者抢先注册。一次分发渠道失陷,即可被放大为系统性风险。

3. 执行链侧:内部安全坍塌(本报告重点)

这是最隐蔽、也最容易被忽视的一层。研究者将其称为内部安全坍塌(Internal Safety Collapse, ISC):安全失效不一定来自外部恶意提示,而可能发生在智能体自身的执行链条中。

其触发结构非常普通,几乎等同于常见工程流程,研究中概括为 TVD 模式:

• Task(任务): 一个正常的专业任务;
• Data(数据): 一个不完整的数据文件;
• Validator(校验器): 一个只检查格式、完整性、目标是否达成的校验器。

风险链条如下:数据不完整 -> 校验器报错 -> 智能体为了让流程跑通,自行补全缺失的数据 -> 补全过程中走向不安全输出。关键在于:校验器更像一个”工程验收员”,它只检查任务是否按格式完成,并不理解内容背后的安全边界。

也就是说,最初的用户输入可能完全正常无害,前期执行(读文件、分析数据、写代码、调工具)也始终合规;但当智能体推进到某个关键阶段,它可能自行推导出”不做某个本不应执行的动作就无法完成任务”的结论。模型不是被一步步教坏的,而是在”认真完成任务”的过程中,自己走到了不安全的位置。

公开评测显示该现象覆盖了数十个主流前沿模型,说明这是”安全分类器 + 模型”这一类防御架构的结构性问题,而非个别系统的实现缺陷。这意味着:不能把任何单一模型厂商的内置安全当作唯一防线。

4. 凭证与数据侧

智能体往往持有高价值凭证(云密钥、K8s 令牌、第三方服务 Token)。一旦失陷,可导致横向移动、数据外泄、资源被劫持。公开研究反复指出,代码仓库中泄露密钥的比例很高,且修复周期长,形成持续暴露窗口。

5. 结构性风险(多智能体场景)

在多智能体系统中,单个被攻陷的智能体可通过传播错误信息、利用信任与共识机制引发级联失败。这种失败不源于某个单点 bug,而是整体架构的涌现属性——即风险来自系统的互联结构和自主行为本身。

二、真实案例:风险已在现实中发生

以下案例均来自公开披露的研究与安全事件,按上文五个风险层各取其一。

案例 1 - EchoLeak:生产级 AI 助手首个”零点击”提示注入(入口侧)

2025 年 6 月,安全公司 Aim Security 披露了 Microsoft 365 Copilot 的漏洞 EchoLeak(CVE-2025-32711,CVSS 9.3)。攻击者只需发送一封看似正常的邮件、用户无需任何交互,即可诱导 Copilot 访问内部文件并将内容外泄到攻击者控制的服务器。攻击链绕过了微软的 XPIA(跨提示注入)分类器、外链脱敏与内容安全策略等多重防护。它被认为是首个在生产 LLM 系统中被武器化、造成实际数据外泄的提示注入案例;微软已在服务端修复,且无在野利用证据。

启示: 前置分类器可被绕过;真正稳健的做法是在数据进入模型之前就完成范围隔离(scoped access),而不是逐个修补漏洞。

案例 2 - Slopsquatting / 包幻觉:代码生成 Agent 的供应链新风险(供应链 / 执行链侧)

来自得克萨斯大学圣安东尼奥分校、弗吉尼亚理工与俄克拉荷马大学的研究(发表于 USENIX Security 2025),测试了 16 个代码生成模型、约 57.6 万个 Python/JavaScript 代码样本。结果显示平均约五分之一的推荐依赖包并不存在;开源模型的”幻觉”率约 21.7%,商业模型约 5.2%。更关键的是可重复性:对同一提示重复 10 次,约 43% 的幻觉包名每次都会出现。这意味着攻击者只需观察少量模型输出,就能预先在 PyPI / npm 抢注这些同名恶意包。该攻击由 Python 软件基金会的 Seth Larson 命名为 slopsquatting。

启示: Agent 在自动安装依赖前必须校验包的真实性;配合版本锁定、依赖白名单与供应链扫描。

案例 3 - MCP 工具投毒:全模式投毒(供应链侧)

安全公司 CyberArk 披露了针对 Model Context Protocol(MCP)标准的工具投毒攻击(Tool Poisoning Attack),并提出”全模式投毒”(Full-Schema Poisoning, FSP):恶意指令不仅可以藏在工具的描述字段,还能扩展到整个工具 schema。此前业界关注点多集中在描述字段,严重低估了其余攻击面。

启示: MCP 工具的整个 schema 都是攻击面;接入任何外部 MCP 工具都要做来源校验与最小授权。

案例 4 - ISC / Fable 5:执行链内部安全坍塌(执行链侧)

2026 年,由复旦大学、迪肯大学等多机构组成的研究团队公开了”内部安全坍塌(ISC)“现象,并据此在一次对话内绕过了 Anthropic 公开模型 Fable 5 的前置安全分类器。其要点是:风险并非来自外部恶意提示,而来自 Agent 为通过校验器(Validator)而自动补全数据的过程。配套的 ISC-Bench 覆盖多个专业领域,公开评测显示数十个前沿模型在相关指标下暴露出类似风险。(注:该结论引自学术预印本与技术媒体报道,尚未经独立复现验证。)

启示: 校验器只验工程完成度、不验内容安全;再强的前置检测器也挡不住任务链内部逐步形成的风险。

案例 5 - DeepSeek 数据库暴露:凭证与数据外泄(凭证 / 数据侧)

2025 年 1 月,云安全公司 Wiz 发现 DeepSeek 的一个公网可访问、且无需认证的 ClickHouse 数据库。该库暴露了超过 100 万行日志,包含明文聊天记录、API 密钥、后端细节等敏感信息,并可被完全控制、存在提权风险。Wiz 负责任披露后,DeepSeek 迅速完成修复。

启示: 快速扩张的 AI 服务若忽视最基础的数据与凭证安全,后果严重;凭证应短时效化、数据库不应裸暴露公网、严格遵循最小权限。

三、范式转变:三条核心原则

应对上述风险,需要在理念上完成三个转变。

原则一:从”最小权限”到”最小自主性”(Least Agency)

传统的最小权限原则应当扩展为最小自主性原则:不要赋予智能体它完成任务并不需要的能力和自主度。 部署不必要的自主行为会直接扩大攻击面。如果智能体可以在无人确认的情况下自主调用高风险工具,微小漏洞就可能演变为系统级灾难。

原则二:校验即安全控制点,而非仅工程验收

任何”只检查任务是否完成”的校验器,都可能成为 ISC 的触发器。校验逻辑必须从”做对了没有”升级为”为了做对而生成的内容安不安全”。

原则三:可观测性不可协商

由于智能体行为具有不确定性,必须能够清楚地知道:它在做什么、为什么这样做、调用了哪些工具、为通过校验做了哪些动作。守住入口和出口不足以覆盖执行链内部的风险,过程必须可追溯、可审计。

四、最佳实践清单(按生命周期)

A. 设计阶段

1. 能力最小化。 逐项审查每个工具:能只读就不给写权限;能离线就不联网;能受限沙箱就不给宿主机访问。默认拒绝,显式授予。
2. 避免”完成条件”与”安全边界”重叠。 从任务设计层面预防 ISC:不要给智能体一个”只有跨过安全检查才能满足”的校验器。这是比事后拦截更根本的预防。
3. 明确人工控制点的位置。 由于漂移发生在执行中段,人工二次确认应放在”高风险动作触发点”(如资金写操作、权限变更、对外接口生成、删除类操作),而不是只放在入口。
4. 为高风险领域设默认保守策略。 涉及网络安全、生物、化学、资金等高敏感领域的任务,默认采用更保守的处理路径或强制人工介入。

B. 开发阶段

5. 把供应链当软件供应链来治理。 技能/插件/MCP 配置的每次变更走强制评审 + 多人审批 + 来源校验(签名/哈希),依赖锁定版本,运行时校验加载来源。
6. 依赖必须校验真实性(防 slopsquatting)。 Agent 自动生成或安装依赖前,核对包是否真实存在、来源是否可信,杜绝直接安装模型”凭空生成”的包名。
7. MCP 必须带身份鉴权,且校验整个 schema。 杜绝默认配置裸暴露公网;工具描述与 schema 全字段都要审查,在底层实现细粒度权限管控。
8. 隔离”指令”与”内容”。 在系统提示与工具结果处理中,明确告知模型外部数据(文档、网页、票据、diff)是”待处理内容”而非”指令”,并对工具调用结果做白名单约束。
9. 校验器加入安全验收维度。 在格式/完整性检查之外,增加对”补全内容是否触碰风险边界”的检测。对涉及敏感逻辑的自动补全尤其如此。
10. 拦住”静默自动补全”。 当缺失项落在风险边界上(敏感逻辑、权限校验、密钥、对外接口)时,智能体不得自行补全,必须挂起并交由人工处理。

C. 运行阶段

11. 全链路可观测与审计。 记录智能体的中间目标、工具调用序列、为通过校验所做的修改,形成可溯源的审计凭证。
12. 高风险操作强制熔断。 一旦智能体试图执行高风险动作,强制挂起并引入人机协同的二次验证。
13. 凭证短时效化。 所有密钥短时效 + 自动轮换 + 用量预警(防止凭证劫持类攻击因缺乏费用/用量告警而长期潜伏)。
14. 运行环境隔离。 智能体的代码执行、文件读写、网络访问运行在受限沙箱中,限制其对宿主资源、云环境和第三方服务的横向能力。
15. 数据进入模型前先做范围隔离。 参照 EchoLeak 的教训:对模型可触达的数据先分级、标注、授权,确保它够不到不该够的内容。

D. 治理阶段

16. 不依赖单一安全机制。 模型厂商内置安全只是其中一层;自建的边界规范、校验逻辑、审计与监控才是兜底。
17. 建立安全基线与回归测试。 用真实历史用例 + 已知风险模板,持续评估智能体在长程任务中的安全表现,而非只测单轮输入。
18. 沉淀为可复用规范。 把上述边界与校验规则固化为团队可版本化、可复用的标准文档,而非散落在个别提示词或个人经验中——让”安全的做法”成为默认路径,而非额外步骤。
19. 合规与日志留存。 按所在地法律法规要求,实时记录智能体的网络运行状态与外部调用日志,确保全链路可审计、可溯源。

五、一页速查

风险层	真实案例	它打哪里	关键防御动作
入口侧	EchoLeak (CVE-2025-32711)	提示注入、越狱	前置分类器 + 指令/内容隔离 + 数据范围隔离
供应链侧	Slopsquatting、MCP 工具投毒	技能/插件/MCP/依赖被污染	来源校验、签名、依赖真实性核对、MCP 全 schema 审查
执行链侧 (ISC)	ISC / Fable 5	校验驱动的自动补全	校验器加安全验收、拦截静默补全、过程审计
凭证数据侧	DeepSeek 数据库暴露	凭证泄露、横向移动	最小自主性、短时效密钥、沙箱隔离、不裸暴露
结构性 (多Agent)	-	级联失败、信任滥用	架构层设边界、强验证与护栏

六、结语

智能体安全的核心难点不在于某个组件的缺陷,而在于自主系统在长程执行中可能逐渐偏离初始意图。前置检测能挡住显性的恶意请求,却挡不住”认真完成任务”过程中自然形成的内部风险。因此,真正稳健的做法是:把安全作为系统的架构属性来设计,让正确、安全的行为成为阻力最小的默认路径,而不是依赖任何单点防御或单一厂商的安全承诺。

参考来源(公开资料综合)

本报告综合了以下公开研究与威胁情报,具体数据与论断以原始来源为准:

• EchoLeak / CVE-2025-32711 - Aim Security 披露;另见 arXiv:2509.10540
• 包幻觉 / Slopsquatting - USENIX Security 2025 论文《We Have a Package for You!》(UTSA / 弗吉尼亚理工 / 俄克拉荷马大学);术语由 Seth Larson(Python 软件基金会)提出
• MCP 工具投毒 / Full-Schema Poisoning - CyberArk 研究披露
• 内部安全坍塌(ISC)/ Fable 5 - 学术预印本《Internal Safety Collapse in Frontier Large Language Models》,经技术媒体报道(未独立复现)
• DeepSeek 数据库暴露 - Wiz Research(2025 年 1 月)
• OWASP《Agentic AI Top 10》(2026 版)、五眼联盟《智能体 AI 服务的审慎采用》、《2026 年国际人工智能安全报告》等公开行业报告

免责声明: 本报告为公开资料的综合整理,部分研究结论引自第三方预印本与媒体报道,未经独立复现验证。报告内容仅供工程实践参考,不构成法律或合规意见。各组织在落地前应结合自身业务,经内部安全团队评审。