8.2 大语言模型安全架构模式
本节介绍经过验证的 LLM 安全架构模式，为企业级系统设计提供基础与参考。首先，我们将完整描绘一个典型的“参考架构图”与各组件的安全责任边界。
8.2.1 企业级 LLM 安全参考架构与责任边界
在构建复杂的大模型应用（特别是 Agent 和 RAG 系统）时，安全控制不应集中在单一部件，而必须按层解耦。以下是标准的“五层安全参考架构”及各层严格的安全责任边界：
参考架构图
组件责任边界定义
网关层
拒绝未授权访问与资源耗尽攻击。负责完成身份认证、令牌校验（JWT）、并发/Token 配额控制，统一打点并生成带有 request_id 的基础审计日志。
Kong, API7, Cloudflare AI Gateway
策略层
阻断恶意载荷与违规行为意图。负责对 Prompt 进行注入检测分类、敏感信息（PII）双向脱敏与过滤，核验所请求的工具是否在允许的白名单内。
NeMo Guardrails, LLM Guard
模型层
保障推理过程的安全对齐隔离。负责基于策略层指令，对高低安全需求会话进行路由隔离；不把所有鸡蛋放在一个模型篮子里，主模型专司生成，轻量安全模型专司审核。
Llama Guard, vLLM, LiteLLM
检索层
收敛间接注入与越权数据暴露风险。文档入库前必须验签与净化（防隐藏指令）；多租户检索时强制附加身份 Token，实现向量数据的行级（Row-level）隔离。
Milvus/Pinecone (配合 RBAC), LlamaIndex
执行层
防御最终的系统级破坏。不信任 LLM 的任何编排结果。代码必须在瞬态沙箱中运行；非只读的破坏性 API 操作必须由最小权限凭证执行，并在关键节点拉起审批流（HITL）。
E2B Sandbox, Docker, LangChain Tools
明确上述责任边界后，组织可以根据自身应用的复杂度，选择下文所述的各种简化或专门化的网络架构模式。
8.2.2 网关模式
所有与 LLM 的交互都经过安全网关，实现集中的安全控制。
架构图
图 8-5：网关模式架构图
优势
集中控制
统一的安全策略管理
简化运维
安全组件独立部署
易于扩展
可添加新的安全组件
完整日志
所有请求都有记录
适用场景
API 服务形式提供 LLM 能力
多个应用共享 LLM 服务
需要统一的安全策略
[!TIP] 开源工具参考：NeMo Guardrails 和 LLM Guard 均可作为网关安全组件集成，前者提供可编程对话护栏，后者提供即插即用的输入输出扫描器。
8.2.3 三明治模式
在输入和输出两端都部署安全层，形成“三明治”结构。
架构图
图 8-6：三明治模式架构图
设计要点
8.2.4 代理模式
在用户和 LLM 之间引入代理层，处理所有直接交互。
架构图
图 8-7：代理模式架构图
优势
解耦用户与 LLM 的直接交互
可以实现复杂的业务逻辑
支持多 LLM 后端
便于实施精细权限控制
8.2.5 隔离模式
将高风险操作隔离到独立的安全域中执行。
架构图
图 8-8：隔离模式架构图
隔离机制
进程隔离
独立进程运行
容器隔离
Docker/K8 s 容器
网络隔离
限制网络访问
资源隔离
限制 CPU/内存
8.2.6 零信任模式
采用零信任原则，不预设信任任何组件。
核心原则
图 8-9：零信任模式思维导图
实施要点
8.2.7 多模型检查模式
使用多个模型相互验证，提高安全性。
架构图
图 8-10：多模型检查模式架构图
应用示例
使用独立 LLM 检查输入是否安全
使用独立 LLM 验证输出是否合规
多个 LLM 投票决定行动
[!TIP] 开源工具参考：Llama Guard 本身就是一个安全分类模型，非常适合作为“安全检查 LLM”角色部署在多模型检查架构中。
8.2.8 架构选型建议
根据场景选择合适的架构模式：
API 服务
网关模式
通用应用
三明治模式
复杂系统
代理模式
高安全需求
隔离模式 + 零信任
内容审核严格
多模型检查模式
实际系统通常需要组合多种模式。
8.2.9 最小可行安全集
对于资源有限的团队，以下是分阶段实施安全防护的建议路线图：
第一阶段：基础防护（1-2 周内完成，适用于所有 LLM 应用）
第二阶段：标准防护（1-2 月内完成，适用于面向用户的应用）
第三阶段：增强防护（3-6 月内完成，适用于高风险/大规模应用）
优先级原则：先实施成本低、效果明确的基础措施，再逐步引入高级防护。安全投入应与业务风险等级匹配——面向内部用户的工具可以采用较轻量的防护，而面向公众的高风险应用则需要全面防护。
最后更新于