第 10 章 — 设计安全的 LLM 架构

《LLM Primer VII: AI Security》章节走读的第十篇。这一章把架构当作首要安全学科来处理 —— 因为一个概率组件最安全的配置,是那种爆炸半径由结构、而不是由组件自己的克制来限定的配置。

这一章为什么存在

第 I–III 部分的章节命名了威胁和模型侧的防御。第 10 章走一遍模型周围的架构 —— 隔离边界、验证层、策略引擎、API 契约,以及给系统赋予结构性性质的 zero-trust 原则。前提沿用早期安全工程:假定被攻陷、遏制损伤、让被攻陷这件事看得见。新东西是:要遏制的组件是一个由自然语言驱动的编排器,指令可以从任何输入通道进来。架构模式从前几个时代迁移过来;它们如何具体应用到 LLM 上,就是这一章要下功夫的地方。

一句话:一个被攻击者通过注入输入下指令的模型,会尝试用周围系统暴露的一切能力去执行那些指令 —— 所以决定任何一次成功妥协的天花板的,是架构,而不是模型。

10.1 隔离限定爆炸半径

一条隔离边界是一道有意的接缝,一侧的组件不能直接影响另一侧的组件,除非经过一个受控接口。做隔离的安全理由是:被攻陷的损伤,受限于被攻陷组件通过其合法接口能够到的东西。对 LLM 系统来说,最重要的隔离问题是模型和系统能访问的一切之间。一个模型跑在文件系统不受限、网络不受限、shell 执行工具无 allow-list 的进程里,爆炸半径很大。一个模型的进程跑在有定义好 syscall 集的沙箱里,网络访问走一个按域做 allow-list 的 egress 代理,工具通过周围代码按请求签发的能力 token 调用,爆炸半径就小得多。这个模式延伸到代码执行 —— OpenAI 和 Anthropic 用于其代码解释器环境的那种沙箱工具,把生成代码跑在临时的 gVisor 或 Firecracker VM 里 —— 也延伸到浏览,headless 浏览器跑在隔离的网络命名空间里,不能访问内部端点。隔离是一个在任何具体攻击发生之前就做出的设计决定,是这个领域里"每单位爆炸半径缩减的最便宜安全投入"。

10.2 验证是分层的,策略是声明式的

一个单点验证就是一个单点故障。生产 LLM 端点通常在客户端请求和响应之间组合五层。认证验证主体的凭据。请求验证按 API 的 schema 检查请求 —— 类型、范围、长度、字符集。策略评估问:认证过的主体、验证过的请求、以及当前系统状态,允不允许这个动作。模型调用带着 system prompt、验证过的用户输入、按策略作用域裁过的工具列表、输出约束跑起来。输出过滤在返回之前,检查响应里有没有不该返回的内容 —— 泄露的机密、被禁的内容、不安全的工具调用。策略逻辑随时间生长,如果散落在应用代码里,就变成很多条件的并集,难以审视、测试或演进。领域内已经收敛到把策略从代码里分出去。Open Policy Agent(OPA)是 CNCF 项目,评估用 Rego 写的策略。AWS Cedar 2023 年发布,是一门更聚焦、带形式化验证性质的授权语言。两者都是生产就绪的;选哪个,通常取决于组织契合度。策略变成有版本、可评审的 artefact,系统的有效安全策略在一处总能被读到。

10.3 把 zero-trust 应用到模型调用上

API 是 LLM 系统和它的调用者之间的契约。安全的 API 设计,是把契约塑形成:即使面对对抗性调用者,其不变式也不垮。显式的输入 schema —— 严格类型、范围、allow-listed 枚举 —— 成本不高,却能限定 API 隐含赋予调用者的信任。不泄露内部状态的结构化错误响应,避免了模糊错误信息带来的情报收集。幂等键、请求 ID、版本控制给系统对调用者行为的可观测,而不用额外状态。zero-trust 模型 —— Google 2014 年 BeyondCorp 那篇论文提出,2020 年 NIST SP 800-207 正式化 —— 延伸这一原则:没有哪个调用者因所在网络位置而受信任。每个请求都做认证、都对照明确策略做授权、都对照设备和上下文评估、都被记录。应用到 LLM 系统上,模型调用自身就成为一个主体 —— 模型对下游工具的一次请求,以模型的身份进行认证,携带模型代表其行事的那位人类的身份,并对照同时知道这两个身份的策略做授权。作用域窄、TTL 短的能力 token,是让这一切组合起来的关键。结果是:一个被攻陷的 prompt 不能升级为完整的系统攻陷,因为模型自己的能力被周围代码为这一具体请求签发的 token 所限定。

值得记住:不要让模型自己给自己当警察。每一个模型能调用的能力,都应该由模型之外的代码去按策略核查这次调用,而策略应该以声明式的方式表达,让它的演进可评审。模型的配合,不属于安全周界。

第 10 章为下面铺了什么

没有可见度的结构,失败起来看不见。第 11 章考察那层把架构性防御变成可运行系统的可观测性 —— LLM 在链路里的时候该记什么、如何组织遥测数据以让同一份记录同时服务于实时告警、事后调查、容量规划、合规、以及持续评估。2024 年开始给 LLM 相关 span 和属性做标准化的 OpenTelemetry GenAI 语义约定,提供了厂商中立的地基。具体实现 —— Langfuse、Helicone、Arize Phoenix、Datadog LLM Observability —— 坐在上面,各有取舍。第 12 章接着处理身份和访问这一维 —— OAuth、mTLS、RBAC 对 ABAC、多租户隔离、速率限制,以及让系统在受监管环境里用得起来的企业治理控制。

下一章 — 第 11 章:可观测性、日志与事件响应。按 OpenTelemetry GenAI 约定该记什么、怎么检测滥用模式,以及对一个失败是概率性的系统怎么跑 NIST 形状的事件响应。

想看完整的?书里的章节包含可跑的 OPA 工具授权策略、能力 token 签发模式、把 BeyondCorp 到 NIST 800-207 的 zero-trust 完整适配到 LLM 调用,以及本文只做摘要的 In Plain English 边栏。在 Amazon 上查看 LLM Primer VII →