AI Gateway 被拿去挖矿：上线模型 API 网关前该检查什么

AI Gateway 的价值很直接：把 OpenAI、Claude、Gemini、Bedrock、开源模型和团队内部应用接到一个入口里，统一做鉴权、路由、日志、限流、预算和 fallback。问题也在这里。一旦这个入口被攻破，风险就不只是某台服务器跑了异常进程，而是模型访问、云身份、成本账单和业务数据一起暴露在攻击面上。

Darktrace 7 月披露的一起事件把这个问题讲得很具体：一个连接 Amazon Bedrock 服务的 AI Gateway 相关云实例被观察到和加密货币挖矿基础设施通信。外部报道提到，该实例名为 LiteLLM-Proxy，运行开源 LiteLLM 软件，并带有可访问 Amazon Bedrock 的实例配置文件。Darktrace 同时强调，没有证据把这次活动直接归因到已公开的 LiteLLM 漏洞；真正值得关注的是，这类网关天然处在云基础设施、身份权限和 AI 服务的交汇处。

对正在把模型调用统一到网关层的团队来说，这不是一个“某个工具是否安全”的简单问题，而是一个上线检查问题：你的 AI Gateway 到底能访问什么、能花多少钱、能替谁调用模型、出问题后能不能快速隔离？

这次事件暴露了什么

根据 Darktrace 的分析，6 月 12 日，一个看起来支撑 LiteLLM 活动的 AWS EC2 实例出现了与挖矿相关的行为。该实例关联的 instance profile 可以访问 Amazon Bedrock 资源，因此它不只是普通云主机，更像是一个模型 API 入口。

事件链路里有几个细节值得开发团队记住。

第一，实例曾把 SSH 22 端口暴露给 0.0.0.0/0，并出现大量来自外部地址的短连接尝试。Darktrace 没有确认 SSH 就是最终初始入口，但公开 SSH、暴力尝试和后续挖矿行为放在一起，已经足够说明网络暴露会把 AI 基础设施拉回传统云安全风险里。

第二，实例随后通过 HTTP 下载了疑似包含 XMRig 的压缩包，并连接到挖矿池域名。Darktrace 的判断是，这种连接模式符合被入侵主机参与挖矿的行为。换句话说，攻击者未必一上来就偷提示词或滥用模型 API，先消耗云算力也是常见收益路径。

第三，Darktrace 还观察到另一个 IAM 用户出现异常活动，包括此前不常见的 AWS CLI 行为、GetSendQuota、失败的 InvokeModel 和 ListFoundationModels 尝试，以及创建新用户的动作。Darktrace 没有把这些 IAM 事件和前一天的网关实例事件做确定关联，但这个细节说明：调查 AI Gateway 事故时，只看主机日志不够，还要看云控制面、身份、模型调用和权限变更。

为什么 AI Gateway 的风险更集中

传统 API 网关通常承接业务服务的流量。AI Gateway 还会承接更敏感的几类能力。

首先是模型访问权限。它可能持有 OpenAI API Key、Anthropic Key、Bedrock IAM 角色、Gemini 凭证或内部模型访问令牌。攻击者拿到网关运行时权限后，不一定需要直接窃取密钥，也可能通过网关本身发起调用。

其次是成本入口。模型调用可以按 token、上下文长度、推理时间或工具调用次数计费。OWASP GenAI Top 10 中的 Unbounded Consumption 指的正是这类资源被无边界消耗的风险。对团队来说，挖矿消耗的是云算力，模型滥用消耗的是 API 预算，两者都可能先表现为“账单不对劲”。

第三是敏感上下文。网关经常能看到模型、用户、应用、请求元数据、失败原因和 token 用量。如果团队为了排查问题把完整 prompt、文件片段或业务数据写进日志，攻击面就会继续扩大。

第四是自动化能力。Agent、MCP Server 和工具调用接入后，模型流量不只是问答，还可能读数据库、查工单、开 PR、改配置或触发部署。OWASP 对 Excessive Agency 和 Sensitive Information Disclosure 的提醒，放到 AI Gateway 场景里会变得更具体：权限边界和数据边界必须在网关、身份和工具层同时收紧。

上线前先做这 8 项检查

1. 不把 SSH 和管理面直接暴露到公网

公网 SSH、默认管理后台、未加鉴权的健康检查和调试端点，都会让 AI Gateway 变成普通互联网扫描目标。生产环境应优先使用私有网络、VPN、堡垒机、云厂商会话管理能力或严格 allowlist；确实需要外部访问时，也要把入口、身份、MFA、审计和过期策略放在一起设计。

2. 给网关单独的最小权限身份

AWS 文档把 Bedrock 的访问控制放在 IAM 下管理，IAM 决定谁可以被认证、谁可以被授权使用 Bedrock 资源。网关运行身份不应复用开发者长效访问密钥，也不应拥有宽泛的管理员权限。更稳妥的做法是按环境、应用或团队拆分角色，只允许访问被批准的模型、区域和必要动作，并避免在网关主机上留长期密钥。

3. 对模型、供应商和团队设置预算上限

AI Gateway 不应该只做转发。它需要按 key、团队、应用、模型和供应商设置限额：每日预算、每分钟请求数、最大上下文长度、最大输出 token、单次请求成本上限，以及异常突增时的自动降级或暂停策略。这样即使某个入口被滥用，损失也被限制在可接受范围内。

4. 默认拒绝未知模型和未知路由

多模型接入后，最容易出问题的是“临时开一个模型试试”。生产网关应该维护可调用模型清单，并把模型选择、fallback 顺序、数据驻留要求和成本策略显式化。未登记模型、未批准供应商、跨区域调用和高风险工具调用，都应默认拒绝或要求额外确认。

5. 同时监控数据面和控制面

只看 API 访问日志无法发现完整攻击链。需要把网关请求、模型调用、token 用量、云主机出站连接、IAM 行为、密钥使用位置、异常地理来源、InvokeModel 激增、模型枚举、创建用户、修改策略等信号关联起来。Darktrace 事件里，挖矿通信和可疑 IAM 活动就是两类不同层面的线索。

6. 记录可审计但不过度暴露的日志

建议记录请求 ID、应用、团队、调用模型、供应商、token 用量、估算成本、状态码、延迟、路由结果、fallback 原因和被拦截策略。prompt 和响应内容要谨慎处理，默认做脱敏、摘要化或按场景关闭全文记录。日志的目标是定位成本、稳定性和安全问题，不是把敏感数据复制到另一个系统。

7. 把应急动作提前写清楚

AI Gateway 出现异常时，团队需要知道先做什么：隔离实例或容器、禁用网关入口、停用相关 IAM 角色、轮换模型供应商密钥、暂停高风险模型、导出并保全日志、检查近期 prompt 和响应是否含敏感数据、核对云账单和模型账单，再用干净镜像恢复服务。没有预案时，事故处理很容易在“保服务”和“止损”之间摇摆。

8. 把网关当成生产控制点，而不是工具脚本

LiteLLM、OpenRouter、Vercel AI Gateway、Bedrock、Vertex AI、Azure AI 等选择越来越多，团队很容易先从“把 API 调通”开始。但一旦进入团队协作和生产流量，AI Gateway 就应承担统一鉴权、路由、预算、审计、fallback、密钥隔离和策略执行。使用 RouterHub 或自建网关时，关键不是把所有请求集中到一个 URL，而是让每次模型调用都能被看见、被限制、被追溯，并能在异常时快速切换。

一个实用判断

上线前可以问一个简单问题：如果这个网关今晚被攻破，攻击者最多能做什么？

如果答案是“能访问所有模型、拿到所有 key、消耗无限预算、看到完整 prompt、还能改云权限”，那它还不是一个合格的生产网关。如果答案变成“只能调用少数模型、预算有限、日志可追踪、权限可快速吊销、异常路由会被拦截”，团队才真正把 AI Gateway 从便利工具变成了可治理的基础设施。

AI Gateway 仍然值得建设。模型供应商越来越多，Agent 和 MCP 让调用链越来越长，靠每个业务服务各自管理 API Key、限流和日志只会越来越难。Darktrace 这次事件提醒我们：统一入口带来效率，也带来集中风险。把网络、身份、预算和审计一起设计，才是让模型 API 网关进入生产环境的前提。