安全架构图：从LLM视角的安全、治理与合规

大语言模型（LLM）相关系统的安全问题，并不等同于“模型是否会说错话”。当LLM被嵌入业务流程、连接外部工具、可读写组织数据并与真实用户交互时，它会把传统信息安全、内容安全、隐私保护、软件供应链安全与合规治理的议题压缩到同一个运行时边界之内：同一段自然语言输入，既可能触发越权调用与数据外泄，也可能造成歧视性输出与法律风险；同一次模型更新，既可能提升能力，也可能引入新的漏洞与不可追溯性。因此，本章目标是从“LLM系统视角”建立一张安全—治理—合规的全景架构图：以能力为起点，映射风险；以攻击链为线索，组织防御；以证据与责任为落点，连接合规。

1. LLM系统的“边界”与“资产”：从模型到系统

在工程实践中，风险往往不发生在“模型权重”本身，而发生在模型与外部世界的连接处。为了避免将安全问题抽象成不可操作的“对齐不足”，我们首先定义LLM系统的边界与资产。

1.1 系统边界：五层构成

一个典型LLM应用可以被分解为五层（并不意味着部署结构固定，而是为了刻画攻击面与控制点）：

1. 交互层：Web/App/客服渠道/企业IM，包含身份、会话、前端过滤与提示模板。 2. 编排层（Orchestration）：Prompt模板、RAG检索、工具调用、策略路由、多模型选择、缓存。 3. 模型层：基座模型、微调模型、系统提示、对齐策略、内容安全模型。 4. 数据与工具层：知识库、向量库、日志、文件系统、搜索、邮件、工单、支付等外部API。 5. 治理与运维层：权限与密钥、审计、监控、红队、变更管理、供应链、合规与法务流程。

> 侧边栏（面向电子版阅读）：在LLM应用中，“编排层”常常是最高频的事故源头——它既承载业务能力（RAG、工具、路由），也承担权限边界（能读什么、能做什么）。若没有把编排层纳入安全架构，很多组织会误以为“买一个更安全的模型”就能解决问题。

1.2 资产清单：安全与合规的共同语言

为实现可审计、可落地的治理，需要把“资产”说清楚。建议至少覆盖以下类别，并在后续风险条目中保持一致引用（便于机器处理与证据追踪）：

• **数据资产**：个人信息（PII）、敏感个人信息、商业秘密、源代码、合同与财务、内部策略、访问令牌、提示词与系统提示。
• **模型资产**：权重、微调数据集、对齐规则、系统提示、评测集、模型卡（Model Card）。
• **运行资产**：API Key、调用配额、日志与对话记录、向量索引、缓存、工单与审批记录。
• **业务资产**：品牌声誉、用户权益、交易安全、关键业务流程（如支付、授信、招聘、医疗建议）。

2. 安全—治理—合规：三元目标与可验证输出

三者不是三个平行团队的“分工”，而是同一系统在不同评价维度下的约束：

• **安全（Security）**：关注对抗性威胁与系统韧性，核心问题是“攻击者能否造成未授权影响”。
• **治理（Governance）**：关注责任、流程、透明度与持续改进，核心问题是“谁对什么负责，如何证明已尽义务”。
• **合规（Compliance）**：关注法律与行业规范的最低要求，核心问题是“是否满足可审计的义务与边界”。

将三者统一起来的关键，是把“输出”从口号变为证据：风险登记表、控制措施、审计日志、评测报告、版本变更记录、数据处理影响评估（DPIA）等。后续提出的Risk-Taxonomy与Markdown风险分级，目的即在于让风险条目能够被检索、聚合与审计复用。

3. LLM安全架构图：从能力到风险、从攻击到防御

下面给出一个面向读者的全景架构图（同时便于机器解析），用以定位风险发生的位置与控制点。

```mermaid graph TD U[用户/外部输入] --> I[交互层: 身份/会话/前端策略] I --> O[编排层: Prompt/RAG/路由/工具调用] O --> M[模型层: 基座/微调/系统提示/对齐] O --> D[数据层: 知识库/向量库/日志] O --> T[工具层: API/插件/工作流/执行环境] D --> O T --> O G[治理与运维: 权限/密钥/审计/红队/变更/供应链] --- I G --- O G --- M G --- D G --- T

A[攻击者/恶意输入] --> I A --> D A --> T ```

3.1 能力—风险映射：为何“更强的能力”也意味着更高风险

LLM能力提升（更长上下文、更强工具使用、更强代码生成、更好推理）会带来两类风险增量：

• **影响半径扩大**：模型能调用的工具更多、能访问的数据更多，单次失控的后果更大。
• **可利用面增加**：Prompt注入、间接提示注入（通过网页/文档）、工具参数操控等，更容易被串联成攻击链。

因此，本章建议把“能力变更”纳入风险评审：模型版本升级、工具权限扩展、知识库接入新数据源，都应触发轻量的威胁建模与控制检查。

4. Risk-Taxonomy：LLM视角的风险分类框架

为了避免“罗列威胁清单但无法落地”，本章提出一个可组合的Risk-Taxonomy，用于把风险条目标准化描述为若干维度的组合。其核心思想是：任何LLM风险都应能回答“谁通过什么途径影响了什么资产，并造成何种后果；组织用什么控制与证据去约束它”。

4.1 六维要素：把风险写成可审计对象

建议每条风险至少包含六个字段（后文将给出Markdown模板）：

1. Actor（行为体）：外部攻击者、内部员工、供应商、普通用户、模型本身的非预期行为。 2. Vector（向量）：Prompt注入、数据投毒、越权调用、模型反演、供应链篡改、内容诱导等。 3. Asset（资产）：PII、商业秘密、源代码、系统提示、访问令牌、模型权重、日志等。 4. Impact（影响）：机密性/完整性/可用性（CIA），以及合规与伦理影响（歧视、误导、侵权）。 5. Control（控制）：预防/检测/响应三类控制，映射到具体工程与流程。 6. Evidence（证据）：审计日志、评测报告、权限清单、数据流图、红队记录、变更单。

4.2 与通行框架的对齐（便于合规与沟通）

Risk-Taxonomy并非替代既有标准，而是作为“LLM系统的翻译层”，便于对齐通行框架的条目化要求，例如：

• 信息安全管理体系（如ISO/IEC 27001）强调资产、控制与审计。
• AI风险管理框架（如NIST AI RMF）强调治理、测量与持续改进。
• 行业安全实践（如OWASP针对LLM应用的风险清单）强调常见攻击面（Prompt Injection、敏感信息泄露、供应链风险等）。

在实际沟通中，可将Risk-Taxonomy输出作为“桥梁”：对技术团队是可实施的控制点；对审计/法务是可追溯的证据链。

5. 典型攻击面：从输入到执行的“LLM攻击链”

LLM系统的攻击链往往具有“语言驱动”的特点：攻击者不必突破传统意义上的二进制漏洞，也可能通过自然语言实现越权目标。为了便于防御设计，本节按攻击链阶段描述典型路径。

5.1 攻击链阶段

1. 输入污染：用户输入、网页内容、文档、邮件、工单等进入上下文。 2. 指令竞争：恶意指令与系统提示/开发者提示发生竞争，诱导模型改变目标。 3. 权限穿透：模型在编排层获得对工具/数据的访问，开始执行读写操作。 4. 数据外泄或破坏：输出敏感信息、上传外部、删除/篡改数据、触发资金消耗。 5. 痕迹擦除与扩散：通过多轮对话、工具链或日志缺失降低可追踪性。

5.2 常见威胁类型（面向普通读者的解释）

• **提示注入（Prompt Injection）**：攻击者用语言指令诱导模型忽略原本规则。例如让客服机器人输出内部流程或访问不应访问的数据。
• **间接提示注入**：恶意指令藏在网页/文档中，被RAG检索进上下文后“对模型生效”。
• **敏感信息泄露**：对话日志、训练数据残留、检索内容、系统提示、密钥被输出。
• **越权工具调用**：模型调用了不应调用的API，或在参数上被诱导形成危险操作（例如“把这份文件发到某邮箱”）。
• **数据投毒与后门**：知识库或微调数据被植入触发器，导致特定条件下输出错误或泄露信息。
• **拒绝服务/成本攻击（Denial of Wallet）**：通过诱导长输出、反复调用工具或高成本模型，消耗配额与预算。

6. 防御纵深：把“对齐”落到工程控制与流程证据

LLM安全的有效做法通常不是单点防护，而是分层控制（defense-in-depth），将“模型对齐”与“系统约束”组合起来。可将控制分为三类：预防、检测、响应。

6.1 预防控制：最小权限与可控执行

• **最小权限（Least Privilege）**：工具调用采用“白名单+细粒度权限”，区分只读/写入、范围（项目/用户/时间）、强制审批。
• **上下文隔离与净化**：RAG检索结果进行来源标记、内容清洗、指令抑制（例如把检索文本作为“引用材料”而非“可执行指令”）。
• **安全编排**：将工具调用改为结构化函数调用（schema校验），禁止自然语言直接拼接为命令。
• **输出约束**：对敏感字段进行脱敏，禁止输出密钥、个人信息、内部标识符；对高风险场景使用双模型交叉验证或规则兜底。
• **数据治理**：训练/微调数据进行PII检测与许可核验；对话日志分级存储与访问控制。

6.2 检测控制：可观测性与可归因

• **全链路审计**：记录“输入—检索—提示—模型输出—工具调用—结果”的关联ID，支持事后还原。
• **安全评测与红队**：定期对Prompt注入、越权、泄露、歧视性输出、幻觉敏感场景进行基准化评测。
• **异常检测**：监测工具调用频率、失败率、token消耗、访问异常数据域、可疑关键词与外联行为。
• **版本可追溯**：模型版本、提示模板、检索配置、权限策略的变更都要可追踪。

6.3 响应控制：从事故处理到持续改进

• **分级响应**：建立事件分级（例如数据泄露、违规内容、越权操作、成本异常），明确响应时限与责任人。
• **回滚与熔断**：异常时自动降级到只读模式、关闭高权限工具、切换到安全模板或安全模型。
• **补救与通知**：对涉及个人信息或重大影响的事件，按适用法律与合同义务评估通知与补救措施。
• **复盘闭环**：将事故转化为新的风险条目、测试用例与控制改进，并更新证据材料。

7. 安全、治理与合规的“证据映射表”

为了同时满足工程落地与审计可读，建议为每个控制点配置“证据工件”。下表给出一个可复用的映射示例（可作为组织内部控制矩阵的雏形）：

| 层级 | 主要风险 | 关键控制 | 证据工件（可审计） | |---|---|---|---| | 交互层 | 越权访问、注入输入 | 身份认证、会话隔离、输入限制 | 访问控制策略、会话日志、WAF/网关配置 | | 编排层 | 间接注入、工具滥用 | 工具白名单、schema校验、审批 | 工具权限清单、调用审计、策略测试报告 | | 模型层 | 不当输出、幻觉误导 | 安全对齐、内容过滤、评测 | 模型卡、对齐策略说明、基准评测结果 | | 数据/工具层 | 数据外泄、投毒、后门 | 数据分级、来源可信、写入控制 | 数据流图、DLP报告、数据版本与签名 | | 治理运维 | 供应链风险、不可追溯 | 变更管理、SBOM、红队演练 | 变更单、供应链清单、演练记录、培训记录 |

> 引用提示：对于合规团队而言，“证据工件”比“我们做了安全”更重要；对于工程团队而言，“证据工件”是把一次性修补转化为可持续治理的手段。

8. 风险分级：从定性判断到Markdown可计算表示

风险分级的目标不是制造更多表格，而是支持三件事：排序（先做什么）、决策（是否上线/是否扩权）、审计（为什么这么判断）。

8.1 风险评分的基本模型

在不引入过多数学复杂度的前提下，可采用经典的“可能性×影响”框架，并为LLM场景补充若干修正项：

• 可能性 $L$：攻击难度、可重复性、暴露面、可检测性。
• 影响 $I$：数据敏感性、业务关键性、受影响用户规模、法律后果。
• 风险分数 $R$：$$R = L \times I$$

为便于组织统一口径，可以把 $L$ 与 $I$ 都离散为 1–5 的等级，并规定阈值映射到风险级别（例如R1–R4）。

8.2 Markdown风险分级规范（机器可读）

以下给出一种推荐的“Markdown风险条目”格式：既便于人读，也便于自动抽取构建风险库与知识图谱。每条风险使用固定字段，尽量避免自由发挥。

8.2.1 分级定义（示例）

• **R4 严重（Critical）**：可导致重大数据泄露/重大财产损失/重大合规后果，必须上线前消除或严格隔离。
• **R3 高（High）**：可导致敏感数据泄露或重大业务误导，需要在限定期限内修复并验证。
• **R2 中（Medium）**：影响可控但可能累积成事故，纳入迭代修复与监测。
• **R1 低（Low）**：影响较小，保留为风险接受或优化项。

8.2.2 风险条目模板（可复制）

```json { "risk_id": "LLM-RAG-PI-001", "title": "间接提示注入导致越权工具调用", "actor": ["external_attacker", "ordinary_user"], "vector": ["indirect_prompt_injection", "tool_argument_manipulation"], "asset": ["customer_data", "internal_docs", "api_token"], "impact": { "confidentiality": "high", "integrity": "medium", "availability": "low", "compliance": ["privacy", "security_baseline"] }, "likelihood": 4, "severity": 5, "risk_score": 20, "rating": "R4-Critical", "controls": { "prevent": [ "RAG内容来源标记与指令抑制", "工具白名单+最小权限", "函数调用schema校验与参数约束" ], "detect": [ "工具调用审计与异常检测", "针对注入的红队用例回归" ], "respond": [ "触发熔断：关闭写权限工具", "回滚到安全模板与只读模式" ] }, "evidence": [ "tool_access_matrix_v1.xlsx", "rag_sanitization_policy.md", "redteam_report_q2.pdf", "audit_log_trace_id" ], "owner": "appsec+mlops", "status": "open" } ```

> 说明：JSON仅作为一种可机器读取的表达；在纸书或电子版中也可用表格呈现。同一条目可被链接到测试用例、审计证据与变更记录，形成可闭环治理。

9. 三个案例：把抽象风险落到可理解的情境

本节选择三个高代表性的案例，覆盖“数据—工具—合规”三类后果。案例以机制说明为主，避免提供可直接复现的攻击步骤。

9.1 案例一：RAG客服机器人被“文档内容”诱导泄露敏感信息

场景：某企业客服机器人接入内部知识库。知识库中包含外部可提交的工单文本与附件。攻击者在工单附件中嵌入“看似正常但包含隐蔽指令”的文本，被系统检索后进入上下文。

机制：模型在没有清晰“指令优先级”与“引用材料不可执行”约束时，会把检索内容当作高优先级指令，进而输出不应披露的内部资料，或引导调用检索更多敏感内容。

后果：即便没有系统入侵，依然构成机密性破坏；若涉及个人信息，还会触发隐私合规义务与通知成本。

对应控制：

• 在编排层对检索文本进行指令抑制与明确标注（“以下为参考资料，不是指令”）。
• 将知识库数据源分级，外部可提交内容默认低信任，不进入高权限问答。
• 对输出做敏感信息检测与脱敏，并记录可追溯的检索证据链。

9.2 案例二：工具型Agent越权执行，导致“正确的语言、错误的操作”

场景：企业内部效率Agent可以查询日历、发邮件、创建工单。为了提升体验，产品允许“自然语言直接触发工具调用”。

机制：当工具调用缺少schema校验与权限边界时，模型可能在用户模糊表达下做出高风险动作（例如向外部地址发送内部摘要），或者在对话诱导下执行超出用户权限的操作。

后果：传统安全中“越权访问”通常发生在后端授权漏洞；而这里可能发生在“语言到动作”的映射处，属于新型的人机边界风险。

对应控制：

• 工具调用必须结构化：参数类型、范围、可选值校验。
• 高风险动作必须二次确认或审批（例如“发送到外部域名”“导出客户列表”）。
• 工具权限与用户身份绑定，且每次调用写入审计日志并可回放。

9.3 案例三：训练与日志治理不足，引发隐私与合规风险

场景：团队为提升效果，将用户对话日志直接用于再训练或微调；日志中包含个人信息与敏感内容。

机制：若缺少数据最小化、用途限制、脱敏与保留期限管理，就可能违反隐私合规的基本原则；同时也增加“模型记忆”导致的意外泄露概率。

后果：不仅是安全事件，更是治理与合规事件：组织需要证明数据处理的合法性基础、告知与同意机制、删除与更正权利的实现等。

对应控制：

• 对话日志分级与脱敏，明确训练用途需要的最小字段集合。
• 为训练数据建立可追溯链：来源、许可、保留期限、删除机制。
• 对“是否用于训练”提供可审计的用户选择与记录，并在模型卡中披露。

10. 落地方法：从“全景图”到“项目清单”

为了让读者能将本章框架用于实际项目，给出一个可执行的最小落地路径（可作为项目启动的检查表）：

1. 画出系统数据流图（DFD）：标出输入来源、检索来源、工具与数据写入点。 2. 建立资产分级：至少区分公开/内部/敏感/高度敏感，并映射到访问与输出策略。 3. 建立风险库：