在上一章中，我们探讨了 LLM 应用特有的 OWASP Top 10 风险，以及用于评估、排序和审视这些风险的相关框架。本章将重点讨论：如何把 OWASP Top 10 框架 适配并应用到多种多样的 LLM 用例与部署场景中。我们将引导你根据不同 LLM 应用的具体技术与运营背景——例如聊天机器人、内容生成器与决策支持系统——来定制风险评估与缓解策略。
在本章中，我们将讨论以下主题：
- 识别不同类型 LLM 应用的风险画像
- 将 Top 10 适配到聊天机器人与对话式 AI 系统
- 将 Top 10 应用于内容生成与创意型 AI 应用
- 为决策支持与推荐系统定制 Top 10
- 在企业范围内部署与治理 LLM 时扩展 Top 10 的应用
识别不同类型 LLM 应用的风险画像
除了 软件即服务（SaaS） 这种部署策略之外，在考虑 LLM 应用的部署方式时，通常有两种主要策略可供选择：
基于云的部署（公有云、私有云或混合云） ：这种策略指的是利用外部云服务，通过 API 访问并集成 LLM。它依赖于云服务提供商的基础设施，而这些基础设施通常具备良好的可扩展性、易集成性，并能够持续提供最新更新与新特性。
这种方式最适合那些需要高度灵活性、快速扩展能力，并且希望尽量减少维护负担的应用场景。对于不希望在基础设施上进行大量前期投入、同时又追求成本效率的企业来说，它是一个理想选择。
它尤其适用于初创公司、科技公司，以及那些需求变化快、能够从持续更新与技术迭代中受益的组织。对于数据隐私与合规要求相对没有那么严格的场景，它也非常合适。
本地部署（On-premises deployment） ：这种方式是在你自己的基础设施中部署 LLM，从而获得对数据与定制能力的更高控制权。但这也意味着，你需要在自己的环境里负责安装、维护、扩展等技术工作。
这种方式最适用于那些有严格数据安全、合规或监管要求的应用。它很适合那些拥有足够资源来管理与维护自身基础设施的组织，以及那些需要特定模型定制或专门化能力的场景。
它尤其适用于金融、医疗等受监管行业中的大型企业，或者那些对数据敏感性极为重视的组织。同时，如果企业本身已经拥有成熟的基础设施，并且能够真正受益于本地部署所带来的控制力与可定制性，那么本地部署也具有明显优势。
每一种部署方式都有其独特优点，并且各自适配不同的组织需求与策略，因此企业可以根据自身的具体约束与目标，选择最符合要求的方案。若想更详细地理解云端合同中“客户与云提供商之间的责任划分”，可以参考英国国家网络安全中心（NCSC）发布的共享责任矩阵说明。尽管这一模型超出了本书范围，但它清晰划出了双方责任边界，并指出了云部署与本地部署在基本风险和缺陷上的不同。
为了更直观地总结部署类型（云端 vs. 自托管）的主要差异，以及各自的优缺点，我们来看下面这张对比表：
| 部署类型 | 优点 | 缺点 |
|---|---|---|
| 云端（托管式 LLM API） | 即时接入前沿模型；可对波动性的推理负载进行弹性扩展；无需 GPU 基础设施投入；通常自带 RAG / 向量数据库集成；内置安全护栏与监控能力 | 数据 / 提示会发送给第三方（存在隐私风险）；按 token 计费，成本难以预测；存在厂商锁定；模型可定制能力有限；可能存在延迟与 API 限流问题 |
| 本地部署（自托管） | 完整的数据主权；完全控制模型权重、微调方式与版本；无 API 调用限制；高吞吐场景成本更可预测；更容易满足受监管数据的合规要求 | 需要巨额 GPU 硬件投资；要求深厚的 ML Ops 能力；模型服务基础设施复杂（如 vLLM、TensorRT-LLM）；扩展需要人工处理；安全与更新完全由自己负责 |
表 9.1——LLM 应用部署选项的优缺点
在今天的实际世界中，LLM 最主要的使用方式，是把它们嵌入到新的或现有的应用中，以提升这些应用的生产力与表现。为了确保真正落地成功，必须关注若干关键因素，它们共同决定了用户体验是否正向、业务收益是否真实可见：
- 数据覆盖率（Data coverage） ：模型是否拿得到足够的数据来回答我的问题？
- 检索质量（Search quality） ：模型是否真的成功检索到了回答我问题所需的数据？
- 模型质量（Model quality） ：在成功取回正确数据的前提下，模型是否真的给出了正确答案？
- 优雅失败（Failing gracefully） ：如果 LLM 应用失败了，我是否能够轻松接管流程并继续完成我的目标？
- 时延（Latency） ：使用这个 LLM 应用，是否真的比我不用它、自己去完成任务更快？
- 界面覆盖（Interface coverage） ：我是否能在自己需要的入口（Web、移动端等）使用这个 LLM 应用？
这些基础支柱一旦被整合进系统，就会隐含地继承各种独特风险与脆弱性，并使部署策略的复杂度迅速上升。因为风险会取决于你引入了什么组件、以及这些组件落在什么位置上。对此不存在一个通用万能解，所有方案都必须结合你的实际需求来定制。话虽如此，可以说，保护 LLM 应用利益相关方的最简单、也通常最有效的方法，就是把 human-in-the-loop（人类在环） 机制纳入系统中。
总体而言，通过透明性实现安全，如果实施得当并且策略清晰，会是一种非常有效的方法。举例来说，如果某个聊天机器人存在提示注入脆弱性，并且它还拥有可以隐式调用工具的权限，而这些工具又能对第三方 API 执行创建、读取、更新、删除（CRUD）这类资源操作；如果系统要求在多工具链调用的第二步引入人工审批，那么提示注入攻击通常就会在这里失效，因为这个人工审核步骤本身就是一个关键的安全失效保护机制。需要注意的是，这种控制手段往往会牺牲一部分用户体验，因此它也是一个典型的产品权衡决策。
当你在云部署与本地部署之间做选择时，需要同时从开发、安全和产品三个角度综合考虑。最终决策通常取决于多个因素，例如数据敏感性、成本、扩展性、合规要求，以及具体业务场景。下面列举一些在安全层面经常发挥决定作用的因素：
数据敏感性与隐私
本地部署：如果处理的是高度敏感数据，例如个人可识别信息（PII）、医疗记录、金融数据或知识产权数据，那么通常应优先选择本地部署。本地部署可以提供更强的数据控制能力，并最大限度降低把数据暴露给第三方的风险。
云部署：更适合用于敏感度相对较低的数据，或者云服务商本身能够提供足够强的安全措施（例如加密、安全访问控制）以及相关合规认证（如 HIPAA、GDPR）时。此时必须重点评估云服务商在数据驻留与安全保证上的承诺。
合规与监管要求
本地部署：对于那些必须满足严格监管要求的行业（例如医疗、金融、政府机构），本地部署通常更有优势，因为它可以被更精细地定制，以满足具体合规要求。
云部署：很多云服务商本身已经满足了多种监管标准，但企业仍然必须确认这些标准是否真的符合本组织所在地区和行业的具体要求。
基础设施与资源管理
本地部署：本地部署意味着你完全掌控自己的数据湖与存储体系，同时也可以避免把数据处理交给第三方供应商。此外，你还可以构建气隙（air-gapped）架构，将网络段彻底隔离。不过，这种方式的前提是：软件层完全由客户自己管理，因此补丁管理与漏洞治理就变得极其重要。在某些业务或客户依赖于特定硬件时，本地部署甚至可能是唯一可行选项。
云部署：云服务商会处理绝大部分基础设施管理工作，从而减轻内部 IT 团队负担。云平台还能通过 VPC、防火墙与云层抽象等机制原生提供隔离能力，降低对手建立 foothold（立足点）或横向移动的风险。
灵活性与控制权
本地部署：这种方式提供了对环境的完全控制，可以做高度定制化的配置、优化以及与现有系统的深度集成，因此很适合那些有特殊需求或定制化流程的组织。
云部署：云平台虽然在服务选择与资源调度方面也具备灵活性，但整体环境更标准化，可定制的范围通常受限于平台所提供的能力。
灾难恢复与业务连续性
本地部署：企业必须自行建设灾难恢复方案与基础设施，这通常既复杂又昂贵。
云部署：云服务商通常能够提供多区域冗余与成熟的灾难恢复方案，这对生产环境中的 LLM 应用高可用性保障非常有利。
场景与负载特征
本地部署：适合那些要求性能稳定、安全级别高、或者本身就高度受监管的工作负载，也适合那些已经在本地基础设施上投入较多的组织。
云部署：更适合变化型负载、开发测试环境，以及那些受益于云端灵活性与可扩展性的场景。
因此，选择云端还是本地部署 LLM 应用，必须建立在对上述标准进行谨慎评估的基础上。很多组织最终会采用一种混合式方案：根据具体工作负载的需求，同时使用云资源与本地资源——尤其是在从 brownfield（已有遗留系统与应用） 生态迁移，或者从 greenfield（全新部署） 开始建设时，这种混合策略尤其常见。
截至目前，LLM 应用之所以主要被部署在云环境中，主要原因有以下几点：
- GPU / TPU 资源可用性：LLM，尤其是先进模型，在训练与推理阶段都需要强大的 GPU，甚至更专用的 TPU。这些硬件非常昂贵，且本地维护成本高。
- 获取前沿硬件：AWS、Google Cloud、Azure 等云厂商可以直接提供最新 GPU（如 NVIDIA A100、V100）与 TPU，而组织无需自行采购硬件。它们还会持续升级基础设施，这对于性能与成本优化都非常关键。
- 动态资源分配：云环境能够按需提供算力资源，让组织根据实际负载随时扩容或缩容。对于训练阶段计算需求波动极大的 LLM 来说，这种灵活性尤为宝贵。
- 成本效率：相比本地部署容易出现“过度配置造成浪费”或“资源不足导致瓶颈”，云的按需计费模式更适合短时间内爆发式需要大量并行算力的 LLM 任务。
- 高存储需求：LLM 的训练与微调通常需要大量数据，云平台能够提供高性能、可扩展存储，并配套优化的大数据处理能力。
- 与数据流水线的易集成性：云平台通常更容易和现有数据管线集成，方便把数据吸入、转换并投入训练流程。
- 避免前期资本支出：本地部署 LLM 的资本投入很大，不仅是 GPU / TPU 硬件本身，还有供电、散热、网络等配套基础设施。云部署则可以避免这一笔前期投入。
- 更低的维护负担：云服务商负责底层硬件、软件更新、扩展与维护，组织可以把重心放在模型开发与部署本身，而不需要组建专门的基础设施运维团队。
- 可直接利用托管服务：例如 Amazon SageMaker、Google AI Platform、Azure Machine Learning 这类托管式 ML 服务，为 LLM 开发提供了大量工具、库与预配置环境，能显著缩短开发周期。
- 协作与版本管理便利：云环境天然利于数据科学家与开发者共享资源、集中管理版本、快速部署，适合迭代式开发。
- 内建冗余能力：云厂商通常原生提供跨多地理区域的冗余与故障切换能力，对生产环境下 LLM 应用的高可用非常重要。
- 灾难恢复更成熟：云端托管的灾备方案能显著降低企业在数据完整性与业务连续性方面的复杂度与成本。
- 更强安全能力：云厂商通常在安全上投入巨大，提供端到端加密、IAM、DDoS 防护、监控工具等能力，用于保护 LLM 模型与数据。
- 合规认证丰富：云环境往往已经满足多种行业标准与监管要求（如 GDPR、HIPAA、SOC 2），从而降低企业部署 LLM 时的合规成本。
- 生态与社区支持：云厂商通常拥有成熟生态，能与 PyTorch、TensorFlow 等主流框架深度整合，简化接入与维护。
- 规模经济：云厂商能够通过规模效应，在计算与存储成本上提供比多数企业自建更低的价格。
综合来看，云的这些优势——尤其是在面对像 LLM 这样动态、算力密集型任务时——使它成为目前市场上几乎所有主流 LLM 应用的主导部署方式。当然，必须明确的是：数据隐私与安全 仍然是生成式 AI 领域反复被讨论的核心话题。近年来，一个显著趋势是：原本以云端 SaaS 服务形式提供基础模型的格局，正在被开源模型甚至更小型的模型（例如 Mistral、Meta 的 Llama）所补充乃至部分替代；再加上 Ollama 这类允许用户在本地或私有生态中运行模型的服务，越来越多组织开始选择把数据留在本地，以避免云存储、第三方处理和日志记录所带来的风险。
将 Top 10 适配到聊天机器人与对话式 AI 系统
近年来，聊天机器人与对话式 AI 系统已经成为客户互动中的核心组件，它们能够提供即时支持与个性化体验。然而，现实世界中的数据泄露事件已经暴露出这些系统所面临的关键脆弱性。2025 年，麦当劳的 AI 招聘聊天机器人 就因为研究人员使用简单密码（如 123456）访问了 Paradox.ai 的后端，导致 6400 万求职者记录 泄露，暴露的信息包括姓名、电子邮件和电话号码，而且整个系统甚至没有启用多因素认证。类似地，OmniGPT 也发生了安全事件，影响约 3 万名用户的个人数据，以及 3400 万行会话内容，其中还包括凭证与 API key。
这些事件都清楚说明：聊天机器人交互已经成为数据外流攻击的重点目标。因此，本节会把 OWASP Top 10 专门映射到对话式 AI 场景中，帮助你理解这些新型威胁，并据此进行防护。
在第 8 章中，我们已经为每一类脆弱性建立了风险画像。在本节中，我们会进一步深入，把与聊天机器人和对话式 AI agent 特别相关的 OWASP Top 10 脆弱性 逐项映射出来，并讨论：为什么某些脆弱性在这一类应用里会表现得更突出、风险更高。这里的重点不是做一份完整威胁建模，而是帮助你识别：在不同架构方式下，哪些脆弱性才是真正需要重点关注的。
一个典型的“风险会随着部署方式而变化”的例子，是近期安全研究人员发现的 token-length 侧信道攻击。这类攻击利用了两个基本事实：
一是 tokenization 会把文本转换为模型可理解的单位；
二是很多 API 端点支持 流式生成（streaming） ，即模型逐词输出，而不是一次返回整个结果。
攻击者甚至可能通过逆向工程，对已经加密的载荷做出准确推断，从而恢复客户端与模型之间的对话内容。
如果我们要为客户构建自己的 SaaS 或云端部署模型，这种风险就可能足够高，需要采用像“对 API 响应加入随机 padding”这样的缓解策略。但如果是封闭式本地部署，由于通常不会暴露在公网环境中，这一风险就可能非常低，甚至可忽略。
不过，如果一个应用虽然托管在本地环境中，但同时又暴露在公网，那么它同样会面临相同的风险关联性。
同样值得注意的是，在封闭的本地部署策略中，针对目标客户利益相关方的风险通常会低于云部署。这是因为系统处于一个更受控的环境里，通常只面向特定客户，不会暴露给更广泛的公共网络。然而，无论部署方式如何，用户输入始终都应被视为天然不可信。例如，在微调阶段，训练数据投毒依然是一个现实问题——如果机密或专有数据在进入模型前没有得到充分清洗，那么这些内容就可能在未来输出中意外显现出来，并带来严重后果。
当大多数本地部署的聊天机器人或对话式 agent 真正交付给客户时，模型和应用通常会以 容器 的形式被交付到对方基础设施中。即便这是一个本地环境，也仍然必须遵守沙箱、分段隔离，或者气隙控制，以确保应用只获取其运行所必需的最小权限。这本质上就是 零信任网络架构 与 最小权限原则（PoLP） 的体现，也是一个高度 DevSecOps 化的最佳安全实践。网络层与应用层是最关键的控制落点——无论是通过网络防火墙白名单限制数据库访问以支持 RAG 检索，还是通过精细化 token 作用域控制，让应用连接 Slack 或其他生产力工具，这些都属于核心安全控制。
从 LLM 应用提供商的角度来看，面向客户通常有三种常见部署选项。下面我们逐一展开。
SaaS
从 LLM 应用提供商视角看，SaaS 可以部署在云端，也可以部署在本地环境中。它为客户提供了一个高效、快速的接入方式，使其能够迅速开始使用 LLM。通过 SaaS 平台，用户无需自行管理后端基础设施，就能直接访问和部署 LLM 能力。这种模式把技术复杂性交给 SaaS 提供商处理，让组织可以专注于利用技术完成自身业务目标，从而实现更快速、也更有效的落地。
此外，由于目前市场上绝大多数应用本身就是以 SaaS 方式存在的，因此这些应用通过引入 LLM 来拥抱生成式 AI，也变得非常普遍。下面是一些成功集成 LLM 的典型 SaaS 应用：
- Grammarly：这款写作增强平台利用 LLM 提供上下文感知的语法与风格建议，其语气检测功能还能识别文本情绪色彩，帮助用户更精准传递想表达的语气。
- Amazon Alexa：这个虚拟助手通过定制 LLM 获得增强，大幅提升了对话能力和整体功能，使交互更加自然、上下文更贴合。
- StarCoder：由 Hugging Face 与 ServiceNow 共同开发的 LLM，它能够理解并生成代码片段，从而简化开发者在自动补全和多语言编程中的工作。
SaaS 特别适用于以下几类场景：
- 中小型企业
- 正在尝试生成式 AI 的团队
- 处理非敏感数据的场景
云 AI 平台
LLM 应用提供商也可以利用各类云平台，把 LLM 更轻松地集成进现有应用中。这些平台通常提供良好的集成能力与扩展性，使企业无需建设复杂的本地基础设施，也能完成模型部署与运维。
云平台尤其适合以下场景：
- 数据科学团队需要高强度算力负载
- 企业希望便捷地与现有云服务集成，并借助云原生能力提升安全性与开发效率
- 组织正在托管多租户 LLM 应用，例如 SaaS 产品
下面这张表更细致地展示了 OWASP Top 10 脆弱性 与 基于云部署的对话式 agent / 聊天机器人 之间的关联性：
| 脆弱性 | 与云端 LLM 应用的关联性 | 云环境下在防御上的优势 | 劣势 | 示例 |
|---|---|---|---|---|
| Prompt Injection | 云部署中的 LLM 往往通过 API 暴露，因此很容易遭受用户构造恶意输入 | 托管服务通常具备内置验证层，可在数据进入模型前执行输入清洗与校验 | 相比自建工具链，开发者通常缺乏足够可见性和控制力 | AWS 内容过滤器（提示注入过滤器） |
| Insecure Output Handling | 云端输出流必须严格过滤，因为其中可能包含敏感信息 | 云环境可提供自动化过滤机制，对输出中的敏感信息或有害内容进行筛查 | 相比自定义方案，控制能力与透明度可能受限 | Google Cloud Vision API 内容过滤器 |
| Training Data Poisoning | 云模型常使用公开数据训练，这些数据可能包含被投毒样本 | 云端可接入大规模多样数据，并可通过流水线预处理与验证建立清晰数据血缘 | 一旦数据被污染，可能直接导致模型行为偏斜甚至在推理阶段生成对抗性输出 | Google Cloud Vertex AI |
| Model Denial of Service | 云端 LLM 易受到 DDoS 或高频请求冲击，导致服务容量饱和 | 云服务商通常拥有很强的弹性扩容与流量缓冲能力，可提高可用性 | 应用提供方必须依赖云厂商的可用性；若云厂商本身因其他客户被攻击，也可能连带影响你的平台 | Google Cloud Armor |
| Supply Chain Vulnerabilities | 云部署通常集成大量第三方库与服务，一旦某个依赖被攻破，系统就会面临风险 | 云环境使第三方工具接入更快更便捷 | 被利用的依赖可能导致对用户数据的未授权访问 | Google Cloud Artifact Registry（支持 SBOM） |
| Sensitive Information Disclosure | 多用户并发访问会提高数据暴露风险，使敏感输出控制更困难 | 云服务通常提供静态与传输加密，可满足数据保护法规要求 | 应用数据存储在第三方基础设施中，受到其可用性、主权与传输 / 存储安全约束 | 对话过程中泄露专有算法 |
| Insecure Plugin Design | 云端 LLM 常允许第三方插件，若这些插件缺乏足够安全措施，就可能引入攻击面 | 云平台可通过严格权限与经过审查的插件市场降低风险 | 多租户环境下，应用提供方仍需依赖云厂商的隔离能力 | AWS Lambda 无服务器函数 |
| Excessive Agency | 云端环境中，LLM 可能在缺乏人工监督的情况下执行命令或给出“权威性”过高的输出 | 响应速度更快，用户体验更好 | 缺乏人工干预可能让模型作出有害或错误决策 | 模型基于模糊请求自动修改用户设置，导致非预期后果 |
| Overreliance | 云部署因易访问性增强，用户更容易无批判地接受模型输出 | 云平台通常提供可解释性与透明性工具，帮助组织提醒用户核验关键信息 | 用户可能忽略批判性思考和验证流程，基于错误输出作出错误决策 | 用户直接依据 LLM 建议作出关键商业决策 |
| Model Theft | 在 API 安全薄弱时，云环境可能使攻击者更容易提取模型权重或数据 | 通过加密、访问控制与监控，安全云环境能降低模型窃取概率并保护知识产权 | 与 DoS 类似，最终仍受制于云厂商面对威胁的能力 | Google Cloud Storage 的加密与传输机制 |
表 9.2——OWASP Top 10 脆弱性在云端 LLM 应用中的相关性
可以看出，在云环境中，每一种脆弱性都会以不同方式影响 LLM 应用提供商。云部署带来了快速接入、扩展性和第三方集成等优势，但也可能无意间引入新的风险。对这些脆弱性的深入理解，可以帮助提供商构建更稳健的安全措施，在享受云方案优势的同时，把应用保持在更强的防护状态中。
不过，选择云厂商基础设施来承载 LLM 应用，对于开发者而言往往是有明显优势的。除了效率与成本收益之外，从安全角度来看，云服务商提供的某些服务本身也能帮助构建更安全的 LLM 应用。举个例子：如果我们要托管一个集成代码解释器的聊天机器人，让用户能一边聊天一边执行代码，这在第 8 章中已经说明过，是一个非常典型的攻击入口。攻击者可能借此 foothold（建立立足点）、pivot（跳板渗透）、横向移动，并在系统中保持持久驻留。这样的功能集成，会映射到多个 OWASP Top 10 脆弱性，但其中最突出的，就是 不安全插件设计。
下面来看：为什么云端部署对聊天机器人与对话式 agent 会有一些明显的安全优势。
云端聊天机器人 / 对话式 agent 的优势
隔离与安全内建（Isolation and security by design）
- 无服务器架构：如果利用 AWS Lambda、Google Cloud Functions、Azure Functions 这类无服务器服务，那么每一次代码执行请求都会运行在一个无状态且天然隔离的环境里。
这种隔离意味着：如果攻击者试图通过嵌入式代码解释器利用某个漏洞，那么他们的访问能力将被限制在该次执行上下文中，从而显著降低攻击半径。
例如，如果恶意代码通过解释器被执行，它也无法影响到底层基础设施或其他正在运行的应用，因为每一次函数执行都被封装在独立环境中。
自动安全更新与合规保障
- 托管安全：云服务商会定期更新其无服务器平台，修复漏洞并强化安全协议。这意味着开发者不需要手动维护这些底层安全更新，从而减少因补丁不及时而被利用的风险。
例如，云厂商会自动确保代码执行环境始终具备最新安全特性与合规标准，从而为 LLM 应用挡住新暴露出的威胁。
细粒度权限与访问控制
- 细粒度权限控制：云厂商允许开发者建立精细权限策略，确保嵌入式代码解释器只具备完成任务所必需的最小权限，而不会暴露敏感数据或系统功能。
例如，可以把某个 LLM 应用中的代码解释器限制为只访问特定 API 和特定资源，从而尽量减少越权访问风险。
内建监控与日志能力
- 更强可见性：无服务器函数通常会自带监控和日志能力，使开发者可以跟踪使用模式，并实时发现异常。
例如，如果突然出现异常的代码执行请求激增，系统就能触发告警，从而让团队在安全事件真正扩大前快速介入调查。
通过在云厂商的无服务器架构中托管嵌入式代码解释器，组织能够获得一种更安全的部署方式。这种方法不仅缩小了攻击面，也充分利用了云厂商提供的安全能力、自动更新与访问控制机制，从而构建出更具韧性的环境。无服务器函数天然的隔离性会显著降低潜在安全事件的影响面，使组织能够在维持强安全姿态的同时，把更多精力放在提供创新 LLM 能力上。
近期还有一位安全研究者发现了一个与 ChatGPT 记忆机制 有关的脆弱性：某些 LLM 在交互中可以保留信息，而这种机制可能被攻击者利用，从而提取敏感数据。这里有几个关键点值得注意：
- 记忆机制：部分 LLM 会保留交互中的信息，而攻击者可以利用这一点，从模型“记忆”中提取敏感数据。这对处理机密信息或 PII 的应用来说尤其危险。
- 潜在攻击向量：攻击者可以构造特定查询，诱导模型吐露其“记忆”中保存的敏感信息，从而导致数据泄露。
因此，云部署下聊天机器人与对话式 agent 的风险画像大致可以总结为：
- 数据暴露风险高：一旦敏感信息泄露，可能带来法律责任、客户信任流失与财务损失
- 声誉损害：公司可能因对敏感数据处理不当而遭受重大声誉打击
- 合规违规：未能保护敏感信息，可能违反 GDPR、HIPAA 等法规
- 运营影响：一旦被利用，企业运营可能受到干扰，并且需要投入高昂的事件响应成本
而采用像 AWS Lambda 这样的云基础设施，则可以在很大程度上缓解这些风险，主要体现在：
- 隔离性：Lambda 默认运行在彼此隔离的环境中，极大降低了跨应用数据泄露的可能性。每个函数在自己的执行环境中运行，攻击者很难访问其他实例的内存。
- 短暂计算环境（Ephemeral compute） ：Lambda 是无状态且短生命周期的，不会在调用之间保留内存，这天然降低了后续请求读取前一次敏感信息的风险。
- 细粒度权限控制：AWS IAM 策略允许极细粒度地限制 Lambda 能访问的资源，进一步提升安全性。
- 自动安全更新：云厂商会自动处理安全更新与补丁，降低组织自己维护漏洞的负担。
- 监控与审计：例如 AWS CloudTrail 和 CloudWatch 这类工具，可帮助组织实时检测和响应潜在安全事件。
Lambda 的这种隔离性与无状态特征，能够显著削弱记忆相关脆弱性带来的风险，为处理敏感数据提供一个更安全的运行环境。
在讨论完公有云部署之后，我们接着来看私有部署策略。
私有部署
LLM 应用提供商也可以把 LLM 部署在本地基础设施中，以获得最大程度的定制能力与控制权。通过把模型集成进组织自己的环境中，企业能够完整掌控安全协议、数据驻留以及配置细节。这种方式使组织可以构建一个更安全、也更符合监管要求的框架，因为他们可以实施专门针对自身运营要求的安全措施，并确保满足相关法规。
将模型托管在本地，还有一个明显优势：敏感数据始终保留在自己的司法辖区之内，因此更容易满足 GDPR、HIPAA、PCI DSS 等严格标准。虽然这种策略会带来更高的维护与管理负担，但它也让组织能够获得一个真正“按自己需求精细调优”的部署体系。
对于聊天机器人与对话式 agent 来说，本地部署尤其适合以下场景：
- 具有严格数据驻留与合规要求的组织（例如政府机构）
- 需要最大化安全性与定制能力的公司
- 处理敏感数据或客户专属数据的组织
这种拆分有助于说明：LLM 部署本身是很灵活的——企业既可以只做轻量实验，也可以构建高安全、高合规的重型方案。
下面这张表更进一步展示了 OWASP Top 10 脆弱性 在本地部署的对话式 agent / 聊天机器人 中的关联性：
| 脆弱性 | 与本地 LLM 应用的关联性 | 优势（本地语境） | 劣势（本地语境） | 示例 |
|---|---|---|---|---|
| Prompt Injection | 本地 LLM 往往与内部业务系统深度集成，因此内部用户、脚本或遗留系统提供的非可信输入会使提示注入成为典型的内部人 / 邻接系统风险 | 可完全掌控预处理、内部过滤器和策略执行 | 容易因“内部用户天然可信”的错觉而低估对 prompt 校验与内容过滤的投入 | 内部员工构造提示，使 LLM 泄露受限的人力资源流程 |
| Insecure Output Handling | 本地部署通常直接连接敏感内部数据，因此任何未经过滤的输出都可能意外泄露高价值信息 | 可以使用内部 DLP、日志和脱敏机制，不依赖云能力 | 输出清洗必须自行设计；消费 LLM 输出的内部旧系统往往没有足够安全控制 | LLM 在内部医疗记录系统检索后，输出了未脱敏的 PHI |
| Training Data Poisoning | 本地数据通常来自多种内部系统，而这些系统的数据治理水位并不一致；内部人员操作失误或过时数据源都可能污染训练集 | 可完整掌控数据血缘与来源，包括私有存储与受限仓库 | 内部数据治理未必比云托管流水线更强；陈旧、带偏或被篡改的数据风险更高 | 某员工修改了自动进入夜间微调流程的知识库 |
| Model DoS | 本地硬件容量固定，本地用户、批处理任务或自动化系统都可能耗尽 GPU / CPU | 可对资源调度与 QoS 做更细控制 | 没有自动扩缩容能力，硬件饱和就会造成宕机；多数 DoS 来源反而是内部“噪声流量” | 内部自动化系统高频请求，导致 GPU 枯竭 |
| Supply Chain Vulnerabilities | 本地 LLM 栈往往要自行安装驱动、运行时、操作系统补丁、CUDA、模型加载器、tokenizer 库等，内部补丁节奏慢会放大暴露面 | 可强制使用内部制品仓库、SBOM 策略与严格审核包 | 运维负担很重，IT 团队必须手动审计每个依赖并跟踪 CVE | 未打补丁的本地推理引擎泄露 GPU buffer 中的模型内存 |
| Sensitive Information Disclosure | 本地系统通常与更敏感的数据更近，例如 HR、财务、研发、运营数据，LLM 与这些系统集成后更容易在输出或日志中泄露内容 | 本地网络分段与物理安全可显著降低外部外流路径 | 内部泄露仍然是高风险；围绕模型、日志、提示与输出建立 RBAC 很复杂 | LLM 因向量数据库中摄入了内部设计文档，而在回答中吐露这些内容 |
| Insecure Plugin / Tool Design | 本地部署常使用自定义连接器访问内部数据库、文件服务器、运维系统或脚本，不安全工具会打开危险内网通路 | 可把工具能力严格限制在内部批准系统之内 | 内部插件往往缺少严格安全审查，容易引发权限提升 | 一个“执行内部脚本”的插件允许在共享服务器上执行管理员 shell 命令 |
| Excessive Agency | 本地 LLM agent 往往被赋予较高运维权限（重启服务、改内部记录、改文件、触发工作流） | 能支持高信任的内部自动化流程 | 过度授权可能直接造成运营事故；缺少 human-in-the-loop 时更危险 | 一个接入工单系统的 agent 错误关闭或重新分配真实事故单 |
| Overreliance | 因为系统是“内部可信”的，员工更容易在采购、合规、工程等敏感决策上过度依赖它 | 如果有恰当监管，LLM 能极大提升内部效率 | 因为是本地部署，团队可能误以为“既然在内网就天然安全”，从而降低批判性审查 | 财务人员直接使用 LLM 汇总结果，而不校验底层数字，最终导致报告错误 |
| Model Theft | 本地系统更容易受到内部访问、共享服务器、备份、NFS 挂载以及物理访问带来的威胁 | 强物理安全、隔离网络与离线集群能降低外部攻击面 | 内部人可能复制模型权重、训练数据或 checkpoint，一旦复制出去，损失不可逆 | 管理员从共享文件系统拷走模型权重并保存到可移动介质上 |
表 9.3——OWASP Top 10 脆弱性在本地部署 LLM 应用中的相关性
对于本地部署的对话式 agent 而言，上述每一项脆弱性都具有自身独特的表现方式与治理难点。虽然本地环境在数据控制与基础设施掌控上具备优势，但它同样要求更严格的内部安全实践与更全面的持续监控，才能真正降低风险。企业必须在“定制能力与控制权”带来的好处，与“基础设施和依赖项都要自己负责”带来的脆弱性之间做好平衡。通过实施更严格的安全措施、定期审计，以及营造强安全意识文化，组织就能在最大化 LLM 价值的同时，大幅降低其暴露面。
将 Top 10 应用于内容生成与创意型 AI 应用
随着技术不断进化，针对对话式 AI 系统的威胁也在不断变化。你不妨思考一下：量子计算 或 深度伪造（deepfake） 技术，未来会如何影响多模态 LLM，而这些多模态模型正是驱动内容生成与创意型 AI 应用的核心动力。内容生成和创意型 AI 应用所带来的巨大机会，也使 LLM 不再只是生成 NLP 文本，而是进一步扩展到图像、音频、视频等更广泛的媒体内容生成。
虽然这类复杂 LLM 应用在底层仍然遵循 OWASP 面向 LLM 应用的 Top 10 中定义的脆弱性，但因为其生态结构与部署方式在根本上并没有发生完全不同的变化，所以从“系统内部工作机制”来看，它与普通对话式 agent 并没有本质差异。真正需要企业重点关注的，反而更多是伦理与法律后果——也就是当模型生成结果不符合服务条款、使用约定或社会规范时，企业可能面临什么样的后果。
几乎无需赘述的是：由于此类应用具备强大的生成能力，它们天然会被高级攻击者、APT 组织以及国家级背景对手用于对抗性用途，例如制造深度伪造媒体，并进一步发动多种攻击，包括诈骗式身份冒充、钓鱼 / 针对高管的鲸钓攻击、利用宣传与虚假信息传播来制造社会伤害，等等。
这类威胁有一部分可以通过应用层控制进行缓解，例如 NLP 层面的 prompt filter，但这绝不是一种完全稳健的方案。更根本的防护，仍然要依赖模型级安全控制（model safety controls） 。下面是现实世界中的一些典型案例：
近年来，深度伪造 已经成为制造虚假信息的重要工具。俄罗斯国家支持的行为者就曾使用这一技术生成逼真的虚假视频。在乌克兰战争期间，攻击者使用 deepfake 视频伪造乌克兰总理的讲话，试图削弱公众信任、制造混乱，并在国内外层面操纵舆论。
另一个极具冲击力的案例，是一张“白宫起火”的高仿真图片在 Twitter 上传播，并迅速引发市场恐慌。该 deepfake 图片快速走红，直接影响了股价并引发市场波动，展示了合成媒体如何被用来扰乱经济秩序。
当我们把 Top 10 应用于内容生成与创意型 AI 时，必须考虑到：模型从客户端接收输入的方式已经不再局限于文本。例如，用户可以上传一张图片，请模型识别其中斯洛文尼亚语菜单的高亮内容，并翻译成英文。与纯文本对话式 agent 相比，这种应用在脆弱性层面的重点会有所偏移，其中最值得注意的是：
LLM01：提示注入
无论是直接还是间接提示注入，在多模态场景中都可能发生，因为进入系统的并不仅是文本，而可能是图像、音频等媒体内容。一个典型例子就是所谓 glitch token。
所谓 glitch token（异常 token），是指某些出乎模型预期的输入，它们会利用机器学习模型在理解数据时的薄弱点，从而让模型输出错误或不可预测的结果。最容易理解的一类 glitch token，是对 GPT 类模型输入一串罕见且不常见的字符或符号序列，使模型因缺乏相应训练数据而表现异常。例如，插入一串极不常见的符号（如 ▓▓▓▓），就可能让模型给出毫无意义或奇怪的输出。
此外，攻击者还可能对图像做一些人类无法察觉的微扰修改，但这些细微变化却会让模型在后续流程中采取完全出乎意料的动作。一个很典型的例子是自动驾驶系统，它们往往使用 LLM 与计算机视觉模型共同进行决策。如果攻击者对路牌做出极其轻微、人眼看不出的扰动，就可能让模型把“停车”标志误判成“让行”标志，进而导致车辆在路口没有停车，造成事故。这类攻击被称为 adversarial perturbation（对抗扰动） ，它利用的正是模型对输入微小变化的高度敏感性。
LLM03：训练数据投毒
与提示注入类似，我们还必须确保：这些来自客户端的多模态 prompt，不会进入微调过程与训练流水线。无论是用户无意上传的 PII，还是攻击者故意投放的恶意工件，如果进入训练或微调流程，就都可能带来严重后果。
当你构建一个 LLM 应用并开发模型时，必须把媒体类内容数据源纳入与自然语言文本同等严格的管理范畴。这些数据同样需要被充分验证、审查和核验其质量与来源合法性。下面这两种场景都同时存在于文本与图像内容中（下图是为了便于理解，以图像形式呈现），它们来源于一项出色的安全研究论文 Poisoning Web-Scale Training Datasets is Practical。
- Split-view data poisoning（分视图数据投毒） ：指攻击者向不同模型或系统提供不同版本的数据集，通过破坏训练数据的一致性，让每个模型看到的都只是被篡改后的局部信息，最终导致模型得出错误结论。这种投毒方式还可以扩展为控制互联网中的公共内容源，从而污染训练热门 LLM 时常用的数据来源。
图 9.1——分视图数据投毒
- Frontrunning data poisoning（抢跑式数据投毒） ：指攻击者通过在某些信息公开前先获取它，再利用这些信息采取有利行动，例如抢先交易。它同样可以体现在对公共互联网工件进行“路过式污染”，而这些工件恰恰又是很多热门 LLM 在训练阶段会摄取的内容源。
图 9.2——抢跑式数据投毒
在内容生成与创意型 AI 应用中，提示注入与训练数据投毒是两类尤其关键的脆弱性，它们往往会导致非预期输出以及模型完整性被破坏。通过借助 OWASP 面向 LLM 应用 Top 10 的原则，开发者可以更好地保护这些系统，从而让创意流程在面对对抗性操纵时，仍然保持相对安全与可靠。
在企业范围部署与治理中扩展 Top 10 的应用
随着企业越来越广泛地在客户支持、内容生成等各类场景中采用 LLM，建立稳健的治理框架变得至关重要。举个例子：某企业曾经使用 LLM 生成营销文案，但模型无意间输出了不恰当语言，这一事故就突显了在缺乏治理约束时，AI 系统会带来多大风险。本节将探讨：如何在整个组织范围内扩展 OWASP Top 10 脆弱性治理，从而确保 LLM 的部署既安全又合规。
企业治理框架
一个企业级治理框架的关键组成部分包括：
- 政策与流程（Policies and procedures） ：制定清晰政策，约束各部门如何使用 LLM，并覆盖安全、合规与伦理要求。
- 利益相关方参与（Stakeholder involvement） ：让法务、IT、业务部门等跨职能团队参与治理讨论。
在 LLM 应用提供商组织内部，一个很常见的做法，是建立跨职能小组（通常包括安全工程师、模型工程师、开发者、安全与对齐实践人员，以及法务代表），这样的团队通常被称为 AI 伦理委员会 或 负责任机器学习工作组。他们会在不同工作流中审查 LLM 的部署情况，确保其与公司价值观和法规要求一致。类似团队还会负责识别并决定：企业应该采用哪些分类体系、框架、政策或外部合作关系，以匹配自身产品特点。
安全最佳实践的落地
把 OWASP Top 10 扩展到企业范围的 LLM 部署，并不只是“修漏洞”这么简单，它更意味着：要在整个组织内部建立一种安全与合规文化。只有围绕治理框架、持续教育等关键方面同步推进，企业才能在享受 LLM 带来能力提升的同时，把风险控制住。
以下是一些关键实践：
- 集中式策略（Centralized policies） ：制定企业级统一安全策略，确保 LLM 应用的安全控制方式一致。
- 自动化监控工具（Automated monitoring tools） ：使用自动化工具持续监控并报告 LLM 交互行为及相关脆弱性。
- 持续教育（Continuous education） ：对不同层级员工开展持续培训，增强他们对 LLM 安全风险与治理要求的认知。
- 事件响应计划（Incident response plan） ：建立专门覆盖 LLM 脆弱性的响应计划，确保在发生问题时可以快速而有效地采取行动。
- 审查周期（Review cycle） ：定期审计与评估治理框架和安全实践的有效性，并根据结果进行调整。
- 指标与 KPI（Metrics and KPIs） ：建立 KPI 来度量治理框架的效果，例如事件数量、响应时长，以及用户对 LLM 交互的反馈。
随着 LLM 在越来越多行业中被广泛采用，确保其安全与治理的重要性也越来越高。这些模型正在从内容生成一路走向高后果环境中的决策支持，因此像提示注入、数据投毒这类对抗性攻击与脆弱性，根本不容忽视。正因如此，我们才会看到 负责任 AI 治理 越来越受到强调，组织也在持续对齐最佳实践与不断出现的新法规。
例如，最新立法动向中，美国提出的 AI Incident Reporting and Security Enhancement Act 就体现出一个明确趋势：必须建立更强健的框架，用于追踪与缓解 AI 特有脆弱性。与此同时，像欧盟的 AI Act 这样的国际法规，也正在尝试确保 AI 解决方案，尤其是那些被界定为高风险的系统，在部署时具备透明性与问责机制。对于大规模部署 LLM 的企业来说，这些动向都在不断提醒我们：治理结构必须既能满足监管要求，也必须主动应对 AI 系统所带来的独特安全挑战。
总结
本章重点强调了：必须根据不同 LLM 应用的具体需求，对 OWASP Top 10 框架 进行有针对性的适配。通过识别不同场景下的独特风险画像，并采用定制化缓解策略，组织可以显著增强聊天机器人、内容生成系统以及决策支持应用的安全性。这种适应性方法不仅能够帮助系统抵御新出现的威胁，也能在 LLM 部署中逐步建立韧性与信任。
通过本章内容，我们可以清楚看到：如果要把这些做法真正扩展到企业范围，一个全面的治理策略是不可或缺的。只有具备这样的治理能力，组织才能更有信心地驾驭 LLM 技术所带来的复杂性。通过把这些洞见真正融入运营框架中，你的组织才能在不断变化的环境中，既利用 LLM 的变革潜力，又保持稳健的安全姿态。
在下一章 《Designing LLM Systems for Security》 中，我们将进一步给出一个构建韧性 AI 系统的完整蓝图。我们会从理论走向实践，详细介绍构建“安全内建（secure-by-design） ”环境所需的架构原则、具体控制措施以及行业最佳实践。你将学习如何落地诸如 纵深防御 与 零信任 这样的基础概念，以及如何从客户端接口一直到模型服务层设计出一个安全系统，从而让你的 LLM 真正能够抵御前面刚刚讨论过的那些威胁。
