【学习笔记】探讨大模型应用安全建设系列1——顶层规划：如何推动公司级大模型安全建设

xian_wwq

412人浏览 · 2026-05-16 21:36:43

xian_wwq · 2026-05-16 21:36:43 发布

客服机器人、知识库问答、代码助手、Agent 自动化——不管哪个场景，大模型正在从"试试看"变成"真的在用"。但大多数团队的安全建设还没有跟上。模型上线了，护栏没装；Agent 能调工具了，权限没控；数据进上下文了，分级没做。

不是安全团队不重视，而是大模型安全跟传统安全确实不一样——攻击面变了，合规要求变了，甚至连"该谁来管"都还没理清楚。

这篇文章想回答一个很实际的问题：作为甲方安全负责人，怎么推动公司在大模型安全上真正投入资源、建立体系、拿到结果？

一、先厘清边界

大模型应用安全只是 AI 安全的一环。在正式谈建设路线之前，必须先把边界说清楚：大模型应用安全不是 AI 安全的全部。

如果把 AI 安全工程看成一套完整体系，至少会覆盖八类能力：数据安全、模型安全、大模型应用安全、Agent 与工具安全、AI 基础设施安全、内容与合规安全、安全评测与红队、安全运营与治理。大模型应用安全只是其中一块，重点解决的是“模型接入业务系统之后，输入、上下文、工具调用、输出、日志和责任链怎么可控”的问题。

这件事很重要。因为甲方安全负责人很容易遇到两种误区：

第一种误区，是把大模型应用安全当成传统 Web 安全的一个补丁，以为加一个 WAF、写几条提示词规则、做一点内容审核就够了。这样会漏掉 RAG 越权、间接提示注入、Agent 工具滥用、上下文泄露、模型输出责任等新问题。

第二种误区，是把大模型应用安全当成 AI 安全的全部，以为做了护栏、评测和备案，就等于公司 AI 安全体系已经建成。这样会漏掉训练数据安全、模型供应链、模型后门、基础设施隔离、算力平台安全、AI 研发治理等更底层的问题。

更准确的定位是：大模型应用安全是企业当前最容易落地、也最容易出事故的连接层。 它连接业务、数据、模型、用户、工具和日志，所以应该优先建设；但它不能替代完整的 AI 安全工程。

所以这篇文章讨论的是“公司级大模型安全建设怎么启动”，不是宣称“做完大模型应用安全就完成了 AI 安全”。后续所有建设建议，都应该放在这个边界里理解：先把应用侧高风险链路管住，再逐步扩展到数据、模型、基础设施、合规和运营的完整 AI 安全体系。

二、为什么不能只按传统安全附属项来管

等保 2.0 能覆盖大模型安全吗？覆盖不了。

这不是否定等保的价值，而是大模型带来了一类全新的风险——等保的框架里根本没有对应项。

这个差距不是"加强一下"就能补的。等保的假设是：系统行为可预测、输入可控、权限边界清晰。但大模型系统不是这样工作的——自然语言同时承载了数据和指令，模型输出有不确定性，Agent 还能调用外部工具。

正确的认知是：等保是必要条件，不是充分条件。

大模型安全需要自己的建设立项、自己的评估标准、自己的运营流程。如果只把它当作传统安全的附属项来处理，大概率会变成"出了事再补"。

三、如何向管理层论证投入

安全团队最常见的困境是：大家都知道安全重要，但没人愿意先掏钱。大模型安全尤其如此——因为它还没有出过"让全公司停摆"的大事故，管理层很难感受到紧迫性。

三个角度可以用来论证：

3.1角度一：合规倒逼

不是"要不要做"，是"不做过不了关"。

中国大模型监管已经进入实操阶段：

截至 2025 年底，累计已有 600+ 款大模型完成备案。备案的前提是通过安全评估，而安全评估的标准在 2025 年集中落地了一批：
- GB/T 45654-2025《生成式人工智能服务安全基本要求》（2025.4 发布，11 月实施）
- GB/T 45652-2025《生成式 AI 预训练和优化训练数据安全规范》
- GB 45438-2025《网络安全技术人工智能生成合成内容标识方法》强制性国标（2025.2 发布，9 月实施）
- 《政务大模型应用安全规范》（TC260-004，2025.9，全国网安标委技术文件）
公安部第三研究所于 2025 年 8 月首次颁发大模型安全评估系统认证证书，意味着安全评估已经开始有官方认可的资质要求。

这些不是征求意见稿，是已经实施的国标和已经启动的认证。如果你的公司面向政企客户、涉及政务场景、或者需要做大模型备案，安全建设就不是"锦上添花"，而是"准入门槛"。

3.2 角度二：风险量化

算一算出事的成本，不需要假设最坏情况，看看已经发生的真实事件就够了。

DeepSeek 数据库泄露（2025 年 1 月）

以色列安全公司 Wiz 发现 DeepSeek 的 ClickHouse 数据库存在未授权访问漏洞，超过 100 万行日志暴露，包括 API 密钥、用户聊天记录和后端架构细节。事件发生在 DeepSeek 爆火当周，全球关注度极高。随后黑产团伙利用泄露的 API 密钥以 30 美元/月的价格对外售卖，形成黑色产业链。

来源：Reuters、The Hacker News

三星源代码泄露（2023 年 4 月）

三星工程师在 20 天内发生三起独立事件，将机密源代码和内部会议记录粘贴到公开版 ChatGPT 中。三星随后紧急禁止员工使用 ChatGPT，并投入资源开发内部安全 AI 工具。

来源：Forbes、Dark Reading

Air Canada 聊天机器人赔偿案（2024 年 2 月判决）

加航的聊天机器人错误告知乘客可以申请丧亲优惠退款，乘客据此购买了全价票。法院裁定加航未采取合理措施确保聊天机器人准确性，判决赔偿 812.02 加元。这是全球首批企业因 AI 聊天机器人虚假信息被判赔偿的案件。

来源：澎湃新闻

这些事件的共同特点是：不是模型本身出了 bug，而是安全设计缺失导致的系统性风险。数据库没做访问控制、员工使用外部工具没有管控、聊天机器人没有输出验证——每一项都是"如果在设计阶段就考虑到，完全可以避免"的问题。

3.3 角度三趋势预判

不做的机会成本分析：

Gartner 在 2026 年初做出了两个预测，一是到 2028 年，50% 的企业网络安全事件响应将聚焦于 AI 应用安全事件；二是到 2029 年，70% 的中国企业将实施 AI 安全测试。

IDC 的数据也显示：42% 的中国企业已开始大模型初步测试，17% 已引入实际业务。

这意味着什么？三年后，AI 安全会成为安全团队的主要工作之一。现在不建体系，到时候就是救火。

向管理层汇报时，建议用这个框架：

四、组织角色分工

大模型安全不是安全团队一家的事。三个角色必须明确分工：

4.1 安全团队：守住底线

定义安全标准和评估流程
建设护栏、监控、审计等安全基础设施
组织红队测试和安全评测
对接合规和监管要求

4.2 AI/算法团队：安全内建

在模型选型和训练阶段考虑安全因素
实现输入验证、输出过滤等应用层防护
配合安全团队完成模型安全评估
将安全要求写入 Agent 和工具调用的设计文档

4.3 业务团队：场景把控

明确每个 AI 应用场景的风险等级
参与定义"什么是可接受的输出"
在高风险场景设置人工审核环节
及时反馈线上异常

4.4 关键原则：安全团队定标准和底线，AI 团队负责技术实现，业务团队定义场景边界。三方缺一不可。

五、建设路线图：三阶段、各有交付物

Google 在 2025 年提出的 AI 安全治理"三步走"方法论，提供了一个清晰的落地路径。结合中国企业的实际情况，我调整为以下路线图：

5.1 第一阶段（1-3 个月）：看见资产，抓住高风险

目标：知道自己有什么、差在哪里、什么最优先。

Google 把这一步叫"发现 AI 资产"（Discover AI Inventory）。他们甚至专门做了敏感数据保护方案（DSP），内置 200+ 种敏感数据检测器，用来扫描 AI 相关的数据资产。

对于中国企业来说，这一步的最低成本做法是：先列一张表，把公司所有用到大模型的地方列出来——包括正式产品和员工自用的外部工具。这张表本身就是安全建设的起点。

阶段验收：不能只写"完成安全摸底"，要写清楚纳管比例、发现的高风险应用数量、下一步需要资源。

5.2 第二阶段（3-6 个月）：控制落地，门禁上线

目标：对最高优先级的应用完成安全加固，建立上线门禁。

这一阶段的核心是：不求全面，但求关键路径上的防护到位。优先解决提示注入、数据泄露、权限过大三个最高频风险。

阶段验收：写清楚控制覆盖率（RAG 检索前鉴权覆盖率、Agent 高风险工具人工确认覆盖率）、门禁执行率、评测基线通过率。

5.3 第三阶段（6-12 个月）：持续运营，形成闭环

目标：安全能力常态化运营，形成发现→修复→验证的闭环。

阶段验收：写清楚纳管比例、控制覆盖率、评测通过率、问题闭环率、合规材料完成度、下一阶段预算需求。这些指标越清楚，安全建设越容易获得持续资源。

六、一个可用的框架：从模型到生态

如果管理层问"我们的安全框架是什么"，可以参考 CSA（云安全联盟）在 2025 年发布的 MAESTRO 七层安全框架。它提供了一种较完整的 Agentic AI 安全分层视角，从底层模型到顶层生态系统，每一层都有明确的安全关注点：

不需要一次性覆盖全部七层，但可以用它来评估：你的公司现在在哪几层有防护，哪几层是空白的？

七、把路线图变成管理层能看懂的版本

向管理层汇报时，安全路线图不要讲技术细节。用"三句话"结构。

1. 现状：我们目前有 X 个大模型应用，其中 Y 个没有安全防护，存在 Z 类合规风险

2. 计划：分三阶段建设，第一阶段花 N 个月覆盖最高优先级应用，投入约 M 万元

3. 预期效果：完成第一阶段后，关键应用的提示注入防御率达到 A%，数据泄露风险降低 B%，满足备案要求中的 C 项

每一阶段结束后做一次汇报，用数据说话：

护栏拦截了多少次攻击
红队测试发现了什么、修了什么
合规达标率从多少提升到多少

安全建设的价值不是"没出事"，而是"可以证明为什么没出事"。

八、系列导读

这篇文章是「大模型应用安全实践指南」系列的第一篇，定位是帮你把大模型安全从一个模糊的想法，变成一个可以推进的项目。

接下来的 7 篇，我们会从规划走到落地：

附录一、AI时代的威胁建模框架：MAESTRO

1、前言

威胁建模是安全设计中最重要的环节，只有准确识别、评估威胁，才能正确建立消减手段，这需要一个好的方法论。传统程序开发中已经有许多威胁建模方法，象微软的STRIDE方法等，这些方法在应对生成式AI的应用，显得不适应。

CSA推出了MAESTRO（Multi-Agent Environment, Security, Threat, Risk, and Outcome,多智能体环境、安全、威胁风险和结果），这是一个专为 Agentic AI 独特挑战而设计的全新威胁建模框架。如果您是安全工程师、AI 研究员或使用这些先进系统的开发者，MAESTRO 正是为您量身打造的。您可以使用它来主动识别、评估和降低整个 AI 生命周期中的风险，从而构建稳健、安全且值得信赖的系统。

该框架超越了传统方法，不再仅仅捕捉 AI 代理的复杂性，而是提供了一种结构化的、逐层的方法。它强调理解代理架构中每一层的漏洞、这些层之间的交互方式以及 AI 威胁的不断演变。使用 MAESTRO，您将能够以负责任且有效的方式部署 AI 代理。

2、MAESTRO 的原则

扩展安全类别
我们正在扩展 STRIDE、PASTA 和 LINDDUN 等传统类别，并融入 AI 专属考量。例如：多智能体与环境聚焦：明确考虑智能体与其环境之间的交互。自动驾驶汽车必须感知其他车辆、物体以及天气状况。
分层安全
安全不是单一的层，而是必须构建到代理架构的每一层中的属性。
人工智能特定威胁
应对人工智能带来的威胁，尤其是对抗性机器学习和自主性相关风险。
基于风险的方法
根据代理环境中的可能性和影响对威胁进行优先排序。
持续监控和适应
持续监控、威胁情报和模型更新，以应对人工智能和威胁的不断发展。

3、MAESTRO 的元素

MAESTRO 是围绕 Ken Huang 描述的七层参考架构构建的，使我们能够在细粒度级别上理解和解决风险。

图1给出了参考架构的思维导图。

图 1：Agentic AI 的 7 层参考架构

这种分层方法将复杂的AI代理生态系统分解为不同的功能层：

从提供核心AI功能的基础模型，到管理信息和开发工具的数据操作和代理框架，再到确保可靠安全运行的部署基础设施和安全层，最终形成代理生态系统，业务应用程序可在此为最终用户创造价值。每一层都服务于特定的目的，同时抽象出上层的复杂性，从而实现模块化开发、清晰的关注点分离以及跨组织系统化地实施AI代理系统。

4、特定层威胁建模

我们将对这七个层中的每一层进行威胁建模练习，重点关注与该层相关的特定威胁。

第七层：代理生态系统

描述：
生态系统层代表着人工智能代理与现实世界应用程序和用户交互的市场。它涵盖了各种各样的商业应用，从智能客户服务平台到复杂的企业自动化解决方案。
威胁形势：
- 受损代理：
  旨在执行有害操作的恶意 AI 代理，通过伪装成合法服务渗透到生态系统中。
- 代理模仿：
  恶意行为者通过模仿生态系统内的合法人工智能代理来欺骗用户或其他代理。
- 代理身份攻击：
  破坏生态系统中人工智能代理的身份和授权机制的攻击，导致对代理的未经授权的访问和控制。
- 代理工具滥用：
  人工智能代理被操纵以非预期的方式使用其工具，导致系统内出现不可预见的、潜在的有害行为。
- 代理目标操纵：
  攻击者操纵人工智能代理的预期目标，使其追求不同于其原始目的的目标或对环境造成损害。
- 市场操纵：
  旨在推广恶意人工智能代理或破坏合法代理声誉的虚假评级、评论或推荐。
- 集成风险：
  用于将 AI 代理与其他系统集成的 API 或 SDK 中存在漏洞或弱点，导致交互受损和更广泛的安全问题。
- 水平/垂直解决方案漏洞：
  利用特定于行业或特定功能的 AI 代理解决方案的弱点，利用垂直解决方案的独特设计。
- 否认：
  人工智能代理否认其执行的操作，由于难以将操作追溯到人工智能代理，因此在系统中产生了问责问题。
- 受损代理注册表：
  列出代理的代理注册表被操纵，以注入恶意代理列表或修改合法代理的详细信息，从而欺骗生态系统的用户。
- 恶意代理发现：
  代理发现机制被操纵，以推广恶意 AI 代理或隐藏合法代理，从而影响生态系统中代理的可见性。
- 代理定价模型操纵：
  攻击者利用或操纵AI代理定价模型造成财务损失或获得不公平优势，操纵AI代理的经济体系。
- 不准确的代理能力描述：
  对人工智能代理的能力描述具有误导性或不准确性，导致误用、过度依赖或因对人工智能的错误理解而导致意外和潜在的有害后果。

第六层：安全性和合规性（垂直层）

描述：
这一垂直层贯穿所有其他层级，确保将安全性和合规性控制集成到所有AI代理操作中。该层假设AI代理也用作安全工具。
威胁形势：
- 安全代理数据中毒：
  攻击者操纵人工智能安全代理使用的训练或操作数据，导致其错误识别威胁或产生误报，从而影响人工智能安全流程。
- 逃避安全 AI 代理：
  恶意行为者使用对抗技术绕过安全 AI 代理，导致它们无法检测或正确应对威胁。
- 受损的安全 AI 代理：
  攻击者控制 AI 安全代理，利用它们执行恶意任务或禁用安全系统，直接影响 AI 安全流程。
- 人工智能安全代理不遵守法规：
  由于配置错误或培训不当，人工智能安全代理的运行违反隐私法规或其他合规标准，从而产生法律风险。
- 安全人工智能代理中的偏见：
  人工智能安全代理中的偏见会导致不公平或歧视性的安全实践，某些系统没有得到充分保护。
- 安全AI代理缺乏可解释性：
  安全AI代理的决策缺乏透明度，导致审计行动或识别安全故障的根本原因变得困难。
- 人工智能安全代理的模型提取：
  攻击者提取人工智能安全代理的底层模型，通过了解系统的工作原理来创建绕过安全系统的方法。

第五层：评估和可观察性

描述：
这一层重点关注如何评估和监控人工智能代理，包括跟踪性能和检测异常的工具和流程。
威胁形势：
- 操纵评估指标：
  对手通过毒害数据集或有偏见的测试用例来影响基准以支持他们的人工智能代理，从而导致不准确的性能数据。
- 受损的可观察性工具：
  攻击者将恶意代码注入监控系统，窃取系统数据或隐藏恶意行为，从而损害人工智能监控过程的完整性和安全性。
- 评估基础设施拒绝服务：
  破坏人工智能评估过程，以防止进行适当的测试和检测受损行为，导致人工智能代理性能缺乏可见性。
- 逃避检测：
  人工智能代理旨在避免触发警报或被可观察性系统标记，使用先进技术掩盖其真实行为并避免安全警报。
- 通过可观察性泄露数据：
  由于配置错误，敏感的人工智能信息会通过日志或监控仪表板无意中泄露，从而造成隐私和机密性风险。
- 毒害可观察性数据：
  操纵输入人工智能系统可观察性系统的数据，向安全团队隐藏事件并掩盖恶意活动。

第4 层：部署和基础设施

描述：
此层涉及 AI 代理运行的基础设施（例如，云、本地）。
威胁形势：
- 受损的容器镜像：
  注入 AI 代理容器的恶意代码可能会感染生产系统，从而危及 AI 部署环境。
- 编排攻击：
  利用 Kubernetes 等系统中的漏洞获取对 AI 部署系统的未经授权的访问和控制，从而破坏 AI 代理的功能。
- 基础设施即代码 (IaC) 操纵：
  篡改 Terraform 或 CloudFormation 脚本以提供受损的 AI 资源，从而为 AI 代理创建不安全的部署基础设施。
- 拒绝服务 (DoS) 攻击：
  压倒支持 AI 代理的基础设施资源，导致合法用户无法使用 AI 系统。
- 资源劫持：
  攻击者利用受损的人工智能基础设施进行加密挖掘或其他非法目的，导致人工智能代理的性能下降。
- 横向移动：
  攻击者获得对 AI 基础设施一部分的访问权限，然后利用该访问权限破坏其他敏感的 AI 区域，从而危及 AI 生态系统中的其他系统和数据。

第 3 层：代理框架

描述：
此层包含用于构建 AI 代理的框架，例如用于对话式 AI 的工具包或集成数据的框架。
威胁形势：
- 受损的框架组件：
  AI 框架使用的库或模块中的恶意代码，会危及框架的功能并导致意外结果。
  *后门攻击： AI 框架中隐藏的漏洞或功能，攻击者可利用这些漏洞或功能获取对 AI 代理的未授权访问和控制权。*输入验证攻击：利用 AI 框架处理用户输入方式的弱点，允许代码注入并可能危及 AI 代理系统。*供应链攻击：针对 AI 框架的依赖项，在交付和分发之前危害软件，导致 AI 代理软件受损。*框架 API 拒绝服务：破坏 AI 框架的运行能力，使服务过载并阻止 AI 代理正常运行。*框架规避：专门设计用于绕过框架内的安全控制的 AI 代理，使用高级技术执行未经授权的操作。

第 2 层：数据操作

描述：
这是为 AI 代理处理、准备和存储数据的地方，包括数据库、向量存储、RAG（检索增强生成）管道等。
威胁形势：
- 数据中毒：
  操纵训练数据以损害人工智能代理的行为，导致人工智能决策出现偏差结果或意外后果。
- 数据泄露：
  窃取存储在数据库或数据存储中的敏感 AI 数据，泄露与 AI 系统相关的私人和机密信息。
- 模型反转/提取：
  通过API查询重建训练数据或窃取AI模型，导致与AI模型特别相关的IP盗窃和数据泄露。
- 数据基础设施拒绝服务：
  破坏 AI 代理所需数据的访问，阻止代理功能并中断 AI 系统的正常运行。
- 数据篡改：
  修改传输中或静止的人工智能数据，导致人工智能系统内的代理行为不正确或结果不准确。
- 受损的 RAG 管道：
  将恶意代码或数据注入 AI 数据处理工作流，导致错误结果或恶意 AI 代理行为。

第 1 层：基础模型

描述：
构建代理的核心 AI 模型。可以是大型语言模型 (LLM) 或其他形式的 AI 模型。
威胁形势：
- 对抗性示例：
  专门设计的输入，用于欺骗人工智能模型，使其做出错误的预测或以意想不到的方式行事，从而导致人工智能不稳定或做出错误的反应。
- 模型窃取：
  攻击者通过 API 查询提取 AI 模型的副本以用于不同的应用程序，从而导致与 AI 相关的 IP 盗窃或竞争劣势。
- 后门攻击：
  人工智能模型中的隐藏触发器，导致其在激活时以特定方式运行，通常是恶意的，从而导致人工智能模型出现不可预测且具有潜在危害的行为。
- 会员推断攻击：
  确定特定数据点是否用于训练人工智能模型，可能会泄露私人信息或违反训练数据的机密性。
- 数据中毒（训练阶段）：
  将恶意数据注入AI模型的训练集以危害其行为，导致AI系统中的模型行为出现偏差或偏见。
- 重新编程攻击：
  将人工智能模型重新用于不同于其初衷的恶意任务，操纵模型用于意想不到的有害用途。

5、跨层威胁

这些威胁跨越多个层级，利用层与层之间的交互。例如，攻击者可能利用容器基础设施（第 4 层）中的漏洞，获取正在运行的 AI 代理实例的访问权限。之后，他们可以利用此访问权限将恶意数据注入代理的数据存储（第 2 层），进而毒害下一次模型更新，最终危及基础模型（第 1 层）。

供应链攻击：
破坏某一层中的组件（例如，第 3 层中的库）以影响其他层（例如，代理生态系统）。
横向移动：
攻击者获得某一层（例如第 4 层）的访问权限，然后使用该访问权限破坏其他层（例如数据操作）。
权限提升：
代理或攻击者在某一层获得未经授权的权限，并使用它来访问或操纵其他权限。
数据泄漏：
某一层的敏感数据通过另一层暴露。
目标错位级联：
一个代理中的目标错位（例如，由于第 2 层中的数据中毒）可以通过代理生态系统中的交互传播到其他代理。

6、缓解策略

特定层的缓解措施：
针对每层的特定威胁实施定制的控制（如上所列）。
跨层缓解措施：
- 纵深防御：
  实施多层安全保护。
- 安全的层间通信：
  使用安全协议进行层间通信。
- 系统范围监控：
  监控所有层的异常行为。
- 事件响应计划：
  制定跨多层级的安全事件应对计划。
特定于 AI 的缓解措施：
- 对抗性训练：
  训练代理对对抗性示例具有鲁棒性。
- 形式验证：
  使用形式方法和规范验证代理行为并确保目标一致。
- 可解释的人工智能 (XAI)：
  提高代理决策透明度以允许审计。
- 红队：
  模拟攻击以发现漏洞。
- 安全监控：
  实施运行时监控以检测不安全的代理行为。