评测
LiteLLM 被攻破后：AI Gateway 为什么必须按 Tier-0 保护
微软安全研究团队在 2026 年 8 月 26 日披露了三类真实 AI 基础设施入侵案例：LiteLLM Gateway、RAGFlow 和 Kestra。攻击链不同，但目标高度一致——拿模型供应商 API Key、数据库连接串、代理签发的虚拟 Key、租户配置和工作流执行权限，再建立持久化或直接把算力拿去挖矿。最值得企业警惕的是：AI Gateway 已经不再只是一个“模型转发层”，而是同时靠近模型、数据库、Secret、预算和执行环境的高价值控制面。微软因此明确建议把 LiteLLM 一类网关按 Tier-0 secrets store 保护。本文不讨论攻击复现，而是给出生产环境应该如何重构 AI Gateway 的权限、Secret、网络和监控边界。
# LiteLLM 被攻破后：AI Gateway 为什么必须按 Tier-0 保护
## 文章摘要
微软安全研究团队在 2026 年 8 月 26 日披露了三类真实 AI 基础设施入侵案例：LiteLLM Gateway、RAGFlow 和 Kestra。攻击链不同，但目标高度一致——拿模型供应商 API Key、数据库连接串、代理签发的虚拟 Key、租户配置和工作流执行权限，再建立持久化或直接把算力拿去挖矿。最值得企业警惕的是：AI Gateway 已经不再只是一个“模型转发层”，而是同时靠近模型、数据库、Secret、预算和执行环境的高价值控制面。微软因此明确建议把 LiteLLM 一类网关按 Tier-0 secrets store 保护。本文不讨论攻击复现，而是给出生产环境应该如何重构 AI Gateway 的权限、Secret、网络和监控边界。
---
很多企业现在的 AI 架构已经变成：
```text
业务系统
↓
AI Gateway
↓
OpenAI / Claude / Gemini / 开源模型
```
网关负责模型路由、API Key、Virtual Key、限流、成本、Tenant、Retry、Fallback 和日志。从工程角度看很合理，但安全上的副作用是：权限和 Secret 越来越集中。
## 为什么 AI Gateway 比普通 API Proxy 更敏感
普通 API Gateway 主要处理认证、路由和限流；AI Gateway 往往还会持有模型供应商 Key、LiteLLM Master Key、数据库连接串、Virtual Key、Tenant Policy、Budget 和 Provider Endpoint。某些部署甚至还带 MCP 测试、Tool 执行或工作流能力。
一旦进程被攻破，攻击者拿到的就不是“一台普通 Web Server”，而是 AI 控制面的钥匙串。
微软在 LiteLLM 事件中观察到的第一阶段，就是从 Gateway 运行时读取环境变量，筛选 master、api key、token、password 等字段，然后外传。
## `/proc/1/environ` 为什么危险
容器里常见配置：
```bash
OPENAI_API_KEY=...
ANTHROPIC_API_KEY=...
DATABASE_URL=...
LITELLM_MASTER_KEY=...
```
如果 LiteLLM 作为 PID 1 运行，而攻击者已经获得命令执行能力，那么 `/proc/1/environ` 可能暴露整个进程环境。
这说明环境变量只解决“配置怎么注入”，不解决“进程被拿下后 Secret 怎么隔离”。
## 为什么要按 Tier-0 管
传统 Tier-0 包括身份系统、Domain Controller、Root CA 等，因为一旦被攻破，影响会向大量下游扩散。
AI Gateway 也正在形成相同特征：
```text
模型权限
+
数据库权限
+
租户权限
+
预算权限
+
Tool 权限
```
微软明确建议把 LiteLLM 等 AI Gateway 当成 Tier-0 secrets store 管理。这个判断背后的核心不是产品名，而是爆炸半径。
## 第一条改造：不要共享 Provider Master Key
不要让所有系统共享一个 OpenAI、Claude 或 Gemini 主 Key。更合理的方式是：
```text
Team A → Virtual Key A
Team B → Virtual Key B
Team C → Virtual Key C
```
每个 Key 都应该有模型范围、预算、有效期、可撤销性和 Owner。即使某个应用泄露，影响范围也被限制在对应 Team 或 Application。
## 第二条改造：Provider Key 进入 Secret Store
尽量不要把所有上游 Key 长期放在普通环境变量中。更合理的结构是：
```text
Gateway
↓
Managed Secret Store
↓
短时读取 / 受控注入
```
并具备 Rotation、Audit 和 Access Policy。
## 第三条改造：管理面不要直暴公网
错误结构：
```text
Internet
↓
LiteLLM Admin UI
```
更合理：
```text
Internet
↓
Public Inference API
Admin
↓
VPN / Private Network / Bastion
↓
Management UI
```
管理面和业务调用面应该分开，管理 API 和 UI 都需要强认证。
## 第四条改造：数据库走 Private Endpoint
AI Gateway 数据库经常保存 Virtual Key、Model Config、User、Usage、Routing 等信息。数据库不应该直接暴露公网，Gateway 的数据库账号也不应该拿 SUPERUSER。
推荐：
```text
Gateway VPC
↓
Private Endpoint
↓
PostgreSQL
```
并仅授予需要的对象权限。
## 第五条改造：Egress 默认拒绝
很多 AI 平台默认允许容器访问整个互联网。攻击者一旦进入，就能下载 Payload、外传 Secret、接 C2、连矿池。
更合理的是 Deny-by-default Egress，仅允许明确的模型 Provider、内部数据库和 Observability 端点。Raw IP、非标准端口和未知域名应该默认阻断。
对于模型网关，FQDN Filtering 很实用，因为正常访问目标通常比较确定。
## 不要把 Docker Socket 直接挂给 Gateway
`/var/run/docker.sock` 对很多动态执行场景很方便，但基本等价于给容器极高宿主控制能力。生产中应拆成：
```text
AI Gateway
↓
Task Queue
↓
Isolated Sandbox Runtime
```
模型路由层不要直接拥有容器管理能力。
## RAGFlow 说明“RAG 也不是只做向量检索”
RAG 平台往往还包含 Provider Credential、Parser、Workflow、Tenant、Upload、Model Config，甚至 Code Execution。微软观察到的 RAGFlow 活动最终关注新配置的 LLM Provider Credential 和模型元数据，说明攻击者已经把 AI 平台的 Credential Flow 当成资产。
## Kestra 说明编排器同样是控制面
如果 Workflow 平台能执行 Shell，攻击者就可能从工作流进入容器、Secret 和 Compute。Agent Orchestrator、Workflow Engine、RAG 平台和 Gateway 都应该按“它持有什么权限”分类，而不是按“它叫什么产品”分类。
## 监控不要只看登录失败
AI 运行时需要更有针对性的高信号检测，例如：
```text
LiteLLM Process
→ spawn bash / sh / python / curl / wget
```
以及：
- 访问 `/proc/1/environ`；
- 搜索 `DATABASE_URL`、Master Key、VerificationToken；
- 从 `/tmp` 执行文件；
- 异常 DNS Callback；
- Raw-IP Outbound；
- cron / SSH authorized_keys 变化。
这些往往比普通 Web Access Log 更接近真实入侵行为。
## 推荐的 AI Control Plane Detection
至少监控四类事件：
### Secret Access
进程环境、Secret Store、数据库凭据。
### Child Process
Gateway 启动 Shell、Python、curl、wget 等异常子进程。
### Unexpected Egress
新域名、Raw IP、非标准端口、异常 DNS。
### Persistence
cron、SSH Key、服务配置、异常文件权限。
## Gateway Runtime 必须用专用 Service Account
不要用 default、cluster-admin 或共享 platform-admin。应该创建专用身份，只允许读取必要 Secret、访问必要数据库和写必要日志。
## 如果网关被攻破，先轮换什么
建议顺序：
```text
Provider Master Key
→ Virtual Key
→ Database Credential
→ UI / Admin Credential
→ Service Account Token
→ Webhook / Integration Token
```
仅重启容器没有意义，因为 Secret 可能已经外传。
## 最小生产检查清单
- Gateway 是否直接暴露公网？
- Admin UI 是否直接暴露公网？
- Provider Key 是否仅存在于环境变量？
- 是否使用 Virtual Key 和独立预算？
- DB 是否 Private Endpoint？
- Gateway DB 账号是否最小权限？
- Egress 是否默认拒绝？
- 是否监控 `/proc/1/environ`？
- 是否监控 Gateway Spawn Shell？
- 是否有 Key Rotation 和 Incident Playbook？
如果这些问题有一半答不上来，AI Gateway 还不适合被视为成熟生产控制面。
## 最终判断
微软这次披露真正重要的不是某一个 LiteLLM CVE，而是攻击者已经开始把 AI 中间件当成高价值基础设施。
LiteLLM、RAGFlow、Kestra 看起来分别是 Gateway、RAG 和 Workflow，但攻击者看到的是：
```text
Credential
+
Data
+
Execution
+
Compute
```
未来企业评估 AI Gateway 安全时，最关键的问题不应该是“它只是一个 Python 服务吗”，而应该是：
> **如果这个 Runtime 被拿下，攻击者下一步能去哪里？**
这才是 AI 控制面需要的威胁模型。
想继续了解 AI Gateway、Agent Security 和企业 AI 基础设施，可以访问 **智元选**：https://www.zyentorpicks.com/。