LLM Gateway 与 DLP 拦截

一句话定位：数据安全治理最重要的工程落地点。核心原则一句话——禁止业务代码直连任何大模型 API，全部流量收敛到内部网关，在这一个点上集中实现管控、脱敏、审计。

1. 为什么必须有统一出口

若各业务各自直连：

• 无法统一实施脱敏与拦截策略（每个业务各写一套，必然有漏）；
• API Key 散落在各业务代码与配置中，泄漏风险高；
• 无法回答”哪些数据被发给了哪个厂商”——出事时无法定责与追溯。

网关是把分散的、不可控的出域行为收敛成单一可管控通道的唯一办法（架构上等价于把安全策略从 N 个点收敛到 1 个点）。

2. 网关核心能力

2.1 DLP 拦截（调用前）

• 对 prompt 做敏感特征扫描：正则（密钥、身份证、卡号）+ 关键词库（客户名、项目代号）+ 轻量分类器（识别源码片段、财务报表结构）；
• 命中后按级别执行动作：阻断 / 告警放行 / 降级路由（改送内网自部署模型，见 9.1 的分级路由）。
• 与 1.2.2 的规则过滤同源：规则负责确定性强的硬特征，模型负责模糊语义判断，两者组合。

2.2 脱敏与回填（见 9.3）

在网关内完成”出去前替换、回来后还原”，业务方无感知，厂商侧全程看不到真实值。

2.3 审计日志

记录谁、何时、把什么数据、发给了哪个模型、返回了什么，全量留痕：

• 金融/医疗等强合规场景必需，对应 7.7 Agent 可靠性中的可审计要求；
• 日志本身含敏感数据，需加密存储 + 严格访问控制 + 明确留存期限（否则审计日志自己成了泄漏源）。

2.4 密钥托管与鉴权配额

• 厂商 API Key 只存在网关（配合 KMS/Vault），不下发到业务侧；
• 业务用内部 token 调网关，网关做身份鉴权、按团队配额与限流、成本归集。

2.5 输出侧过滤

不只管入站：模型响应也要检查，防止越权数据经由 RAG 上下文被带回给无权用户（见 9.5），以及防注入攻击导出的内部信息。

3. 与 AI 平台架构的关系

网关本质是 8.2 模型托管中”推理网关统一鉴权与限流”的安全强化版——把安全策略执行点（PEP）与流量入口合并，是平台侧最自然的设计。生产上通常是：业务 → LLM Gateway →（内网模型集群 | 企业版公有 API）。

4. 常见落地陷阱

• 网关只做转发不做扫描 → 形同虚设；
• 只管 chat 接口，漏了 embedding 接口 → 向量化同样会把原文发给厂商，是最常被忽略的泄漏通道；
• 未做出口网络阻断 → 业务绕过网关直连（见 9.1）；
• 流式响应（SSE）场景未实现流式脱敏与过滤。

参考：OWASP Top 10 for LLM Applications；Cloud Security Alliance《AI Controls Matrix》