AI平台安全架构实战：从后量子加密到Agent防护

当大多数团队还在把安全当成上线前的一次性检查时，TozheBot CTO 已经把安全视为贯穿每一层的"织物"。在这篇基于真实平台建设经验的技术复盘中，作者详细拆解了从密码学基座到 AI Agent 防护的完整架构决策，其中不少思路值得国内 AI 平台开发者借鉴。

密码学基座：后量子准备与密钥版本管理

构建加密体系时，团队面临一个经典抉择：使用经过验证的标准算法（如 AES-256-GCM），还是冒险引入具备后量子抗性的混合方案。

作者将"先存储、后解密"（store now, decrypt later）视为已经存在的现实威胁——攻击者今天截获密文，等待量子计算机成熟后再解密。基于此前自研的 QuarkDash 协议经验（该协议结合 Ring-LWE 的后量子安全性与 ChaCha20、Gimli 对称加密的性能），团队将其引入平台。基准测试显示，即便在 TypeScript 实现下，吞吐量仍可达 2.8 GB/s，会话建立时间低于 10 ms。

QuarkDash 的一个关键特性是支持确定性密钥派生：从主密钥、盐值和版本号推导密钥，数据库只需存储盐值、版本和 KDF 参数等元数据。这意味着即使长期密钥被攻破，历史会话也不会暴露——即密码学中的完美前向保密。

在 KeyManager 中，这一机制通过 deriveKeys 函数实现：在盐值后追加 4 字节版本号，从而支持多版本密钥共存。

密钥轮换：安全合规与性能的平衡

密钥轮换是合规硬性要求，但在多租户环境下对数百万文档直接重新加密会导致服务中断。团队采用惰性迁移加后台重加密策略：密钥按计划轮换，但数据以每批 100 条的粒度渐进重加密，过程可暂停可恢复，进度保存在 keyring 文档中。

一个容易被忽视的细节是与平台核心的交互。由于 API 默认在 afterRead 钩子中自动解密字段，正常读取时看到的是明文而非密文，但迁移需要密文来判定密钥版本。解决方案是通过请求上下文传递 skipDecryption: true，让 decryptHook 原样返回数据。更新文档时不传该上下文，encryptHook 便会用当前活跃密钥重新加密明文。

完美前向保密（Perfect Forward Secrecy, PFS） 是密码学协议的一项重要属性：即使长期主密钥在未来某刻泄露，攻击者也无法解密此前已经完成的会话密文。传统上 PFS 依赖每次会话协商临时密钥（如 TLS 的 ECDHE），会话结束后临时密钥即被销毁。但这一机制在“静态数据”场景（数据库里长期存放的字段密文）中很难直接套用，因为解密时需要持久化的密钥材料。文章中的做法把 PFS 的思想迁移到确定性密钥派生上：每次密钥轮换时引入新的盐值和版本号，派生出的密钥与旧版本相互独立，旧版本被销毁后其对应的历史密文便无法再被解开。这种“版本化派生”在工程上等价于给每一代数据配一把互不相关的钥匙，从而在存储场景近似实现了前向保密，代价是必须同时保留多版本密钥元数据并协调迁移进度。

版本漂移防护：为什么轮换锁不是偏执

在多租户系统中，密钥版本很容易比迁移速度积累得更快。如果每次新用户会话都触发轮换，一周内可能积累 50 个密钥版本，其中 49 个包含待迁移数据。

KeyManager 内置三层保护：会话绑定的轮换有 5 分钟冷却期；存在未完成后台迁移任务时阻止轮换；版本数量超过 KEY_MAX_VERSION_DRIFT（默认 50）时，轮换切换为只读模式，必须先完成迁移。这不是纯粹的技术预防，更是合规要求——监管方需要系统能解释密钥为何未轮换，并提供审计追踪。

“先存储、后解密”（Store Now, Decrypt Later） 是后量子密码学领域常用的威胁模型描述。其核心假设是：攻击者今天并不需要立刻解密截获的密文，而是先大规模囤积加密流量或数据库转储，等待量子计算机成熟（或密码分析取得突破）后再统一破解。这对长期敏感数据尤其致命——医疗记录、身份信息、商业机密的保密周期往往长达十年以上，而 RSA 与椭圆曲线密码在足够强的量子计算机面前会被 Shor 算法多项式时间攻破。因此 NIST 从 2016 年起推进后量子密码标准化，并于 2024 年正式发布 ML-KEM（CRYSTALS-Kyber）、ML-DSA（CRYSTALS-Dilithium）等标准。业界应对策略通常分两类：一是直接迁移到标准化的格密码算法，二是采用“混合模式”同时叠加经典算法与后量子算法，保证即使其中一方被攻破仍有余量。文章中的 QuarkDash 属于后一路线，把 Ring-LWE 的量子抗性与成熟的对称原语组合使用。

多租户隔离：SQL 过滤不等于安全边界

多租户系统中最常见的错误是依赖开发者记得在每个请求里加上 WHERE tenant_id = ?。只要漏掉一次过滤，一个客户的数据就会泄露给另一个。

团队的做法是上下文隔离。每个数据库操作都在租户上下文中执行，且该上下文从 HTTP 请求一直传递到 AI Agent 端点的工具调用。agentRunner.ts 从对话中显式提取 tenantId 并传入工具执行上下文。所有工具（无论是自定义 webhook 还是内置工具）都接收这个上下文，即使工具试图访问未显式过滤的集合，系统也能在工作层强制隔离。

另一个重要的架构选择是：每个租户拥有独立的加密密钥集。管理成本更高（需为每个租户存储元数据），但对合规至关重要。如果某租户要求删除数据（GDPR 或俄罗斯联邦第 152-FZ 号法律），只需销毁其密钥即可使数据不可读，无需重新加密整个数据库。同时这也缩小了泄漏半径——攻破一个租户的 keyring 无法解密其他租户的数据。

AI Agent 安全：经典方法失效的地方

提示词注入的防御远不止正则匹配。"忽略之前所有指令"这类明显措辞容易被检测，但现代攻击早已绕过这些模式。OWASP LLM Top 10 明确指出防御必须多层化：从隔离不可信内容到语义过滤。

团队构建了三阶段互补的防护体系。第一阶段是基于正则的启发式规则，响应时间约 0.1 ms，可捕获约 30%-40% 的攻击。这不需要加载 ML 模型，在资源受限的条件下也能工作，是无需付出模型加载代价的第一道防线。

为什么选择本地 ONNX 模型而非外部 API

第二阶段是团队重新训练的 OGL-Mini ONNX 模型，基于 TF-IDF 10 万特征和逻辑回归，在低端硬件上延迟仅 3-7 ms。为什么不直接调用 OpenAI Moderation 这类外部 API？

作者给出的答案很清晰：循环隔离。如果每个用户请求都要送到外部 API 验证，就违背了"数据不出环"的原则。此外外部 API 会因网络请求增加 100-300 ms 延迟，对聊天机器人而言这不可接受。OGL-Mini 在 CPU 上运行，延迟低于 10 ms，比外部 API 快 10-30 倍。更重要的是无条件控制权：可以用自己监控中观察到的数据继续训练模型，添加新的攻击类别而无需等待外部供应商更新，并保证即使外部 API 不可用模型仍然可用。

模型加载采用惰性策略：首次请求时后台加载，期间系统继续用正则处理。模型就绪后纳入处理流程。即使模型加载失败，底层防护仍在运行。

循环隔离（Loop Isolation 或 Data Loop Isolation） 在此处指数据不离开自有系统和信任边界。对于许多行业（金融、医疗、政务以及俄罗斯 152-FZ 等强监管场景），把用户输入原样发往第三方 API 本身就构成数据跨境或数据出域风险，即使供应商承诺不留存也无法通过审计。把内容检测模型部署在本地还有一层隐性收益：模型的输入分布与平台实际流量完全对齐，可以持续用自己观察到的真实攻击样本增量训练，形成“检测—收集—再训练”的闭环，而外部 API 的更新节奏与攻击面演化往往不同步。当然本地部署也有取舍，比如模型体积、推理资源、版本分发与完整性保护（文章中用哈希校验应对）都需要自建，这正是 ONNX 这类可跨平台部署的运行时受到青睐的原因。

PII 掩码：为什么是 Token 替换而非删除

第三阶段是个人数据泄漏防护。团队并不直接删除 PII，而是替换为 Token。原因很实际：如果对话中所有姓名和电话都被移除，模型会失去上下文。客户写"我叫 Elijah，电话是 +7 999 123-45-67"，删掉这些数据后模型就无法创建 lead 了。

团队使用稳定 Token：同一会话中相同姓名始终替换为相同 Token，既保留上下文又保护数据。收到 LLM 响应后再恢复原始值。所有内容在对话中以加密形式存储，即使数据库泄漏，攻击者看到的也只是类似 v5:3JIjNcvJf0XIqLKT348/eP83VZBD53U00bAsPnHryHx... 的密文。

幻觉检测：当 LLM 假装调用了工具

LLM 最阴险的问题之一是幻觉。模型可能"以为"它调用了工具，在回复文本中写"正在为您转接人工客服"，但实际上并没有调用任何工具。用户等待客服，却无人响应。

团队通过两种方式解决。首先是检测文本中的 JSON 式工具调用——如果模型写了 {"name": "escalate_to_human"}，系统能识别并手动执行调用。其次是检测未实际调用工具的升级承诺——如果模型说"正在为您转接"但没调用 escalate_to_human，系统强制触发升级。这确保用户不会陷入悬空状态。

合规作为架构需求

团队在设计时始终对照 NIST AI 风险管理框架的四大功能：Govern（治理）、Map（映射）、Measure（度量）、Manage（管理）。

治理层面体现在 KeyManager 的功能——系统随时可以说明"轮换被阻止因为迁移正在进行"。映射层面由 EncryptedFieldsRegistry 自动从数据库模型配置中收集加密字段列表，无需单独维护注册表。度量层面包括已迁移文档数、活跃密钥版本数、被阻止的攻击数等指标，全部记录并通过管理端点可访问。管理层面则是自动动作：轮换、重加密、检测到注入时升级。

针对欧盟 AI 法案第 15 条对高风险 AI 系统"准确、可靠、网络安全"的要求，团队的安全护栏正是防止 Agent 行为被操纵的保护机制。所有安全事件记录到 security-events 集合，为第 73 条要求的报告提供基础。

在多租户环境中，审计不是"最佳实践"而是必须。团队不能只告诉客户"我们在保护你"，必须证明保护有效。logSecurityEvent 不仅记录事件类型，还记录上下文：哪个租户、哪个用户、哪个字段、攻击概率是多少。

NIST AI 风险管理框架（AI RMF 1.0） 于 2023 年发布，把 AI 风险管理划分为四个互相迭代的功能：Govern 建立组织层面的政策、角色与问责；Map 明确 AI 系统的用途、边界、利益相关方与潜在影响；Measure 通过指标、测试与监控量化风险；Manage 根据度量结果分配资源、采取措施并持续跟踪。它并不规定具体技术，而是要求“可解释、可追溯、可改进”。文章把 KeyManager 的状态输出、加密字段注册表、安全事件日志分别映射到治理、映射与度量三个层次，正是这一框架的典型落地方式。与欧盟 AI 法案第 15 条（准确、稳健、网络安全）和第 73 条（严重事件报告）配合时，审计日志与可复现的决策记录便成为硬性交付物，而不只是宣传材料，这也是作者强调“审计不是最佳实践而是必须”的制度背景。

面向未来威胁的前瞻设计

作者在结尾列出了一些尚未完全成熟但已经在架构中预留空间的威胁场景：

自动化 LLM 攻击——今天的提示词注入由人类编写，明天将由另一个 LLM 生成，每秒数千个变体，每个都有独特混淆。OGL-Mini 在包括 base64、同形字和零宽字符在内的混淆样本上训练，架构支持在新样本上重新训练而无需重建整个系统。

RAG 知识库投毒——间接提示词注入被 OWASP 列为独立威胁（LLM01）。团队已在将 RAG 内容纳入上下文前检查注入模式，并计划将检查扩展到索引阶段。

ML 模型供应链攻击——ONNX 模型是二进制文件，可能被篡改。modelDownloader 实现首次信任原则：首次加载时保存模型哈希，每次启动时验证。哈希不匹配则重新加载。即使是从 CDN 下载的自有模型也不例外。

密钥管理攻击——如果攻击者获取了 ENCRYPTION_MASTER_SECRET，可以解密所有数据。版本化盐值降低了这个风险，但团队已在考虑下一步：用 HSM 或 KMS 存储主密钥。KeyManager 的架构允许替换密钥源而不改变密钥派生逻辑。

作者的结论不回避现实：系统并非无懈可击。但设计目标是为适应性而生——每一层都知道其他层的存在，每个决策都有文档记录，每个威胁（哪怕是尚不存在的）都留有回旋空间。这才是整体安全：不是组件的集合，而是比攻击者学习更快的活系统。