一、项目背景

我们接手网关治理时，发现一个普遍盲区：绝大多数 AI 网关只做"门口"的鉴权和限流，请求体进去就直接转发给模型。后果是恶意用户往请求里塞超长报文把显存打满、塞畸形 JSON 让解析崩溃、塞精心构造的 prompt 注入让模型绕过系统指令去执行不该做的事。更隐蔽的是越权——租户 A 的请求里带个 target_model 字段指向租户 B 的私有模型，网关没校验就放行。资源被滥用、安全留了大豁口。

二、落地场景

我们在网关接入层补上"请求体治理"：对进入的每条请求做 schema 校验（必填字段、类型、长度上限）、对 prompt 做注入扫描（识别常见的指令劫持、越权字段、敏感操作）、对超限报文直接拦截并告警、对可疑来源做频次约束。合法请求放行，非法请求在门口就被挡掉，不浪费下游算力。

三、关键技术挑战与解决思路

第一个挑战是 schema 校验的零侵入。我们用声明式 schema（JSON Schema 风格）描述每个接口的合法形态，网关在转发前校验，非法即 400，不改模型侧任何代码。

案例片段（已脱敏）： 请求体校验与注入扫描配置（示意）： validators:  - field: "messages"    type: array    max_items: 50  - field: "prompt"    max_len: 4096  - rule: "injection_scan"    patterns: ["ignore previous", "system:", "act as admin", "新指令"]    action: "block_or_sanitize"

观测：上线一周拦截异常请求约 1.2 万次，其中注入类占 31%

第二个挑战是注入与越权扫描的误伤。业务正常文本里可能含"system"字样（比如聊操作系统），全拦会误伤。我们用"上下文加白名单"策略，只在"指令劫持"句式中命中才拦，并对越权字段（如擅自指定他人 model 或 tenant）做硬拦截。

第三个挑战是超限报文拦截的边界。max_len 设太小影响正常长文，太大防不住。我们按接口分级：对话类 4096、文档类放宽到 32768 但配流式处理。

第四个挑战是拦截与性能的平衡。校验要快，我们把它放在网关切面用原生实现，单请求校验开销控制在亚毫秒级，网关 CPU 占用仅微增。

四、效果数据

非法请求拦截率达到 99% 以上（含畸形、超限、注入）；prompt 注入攻击拦截占异常流量约三成；误拦率控制在 0.3% 以内；网关额外 CPU 占用约 2% 到 4%。下游模型因恶意报文导致的异常重启次数从每周数次降到零。

五、可复用经验总结

第一，AI 网关不能只管门口，请求体治理是安全闭环的必补环节，校验要先于放行。

第二，注入扫描别只会关键词，要结合句式上下文加白名单，否则误伤比漏拦更伤业务。

第三，越权字段（tenant 或 model 指定）必须硬校验，这是多租户安全的底线。

第四，校验性能要压到亚毫秒，否则网关自己成了瓶颈。

六、工程落地补充与踩坑记录

请求体治理上线后，我们复盘了几类最典型的非法请求，给后来做网关安全的人参考。第一类是超长报文，有人把几十万字符塞进 prompt 字段，意图打满显存。我们按接口分级设长度上限，对话类四千、文档类放宽到三万二但走流式，既防住攻击又不误伤正常长文。

第二类是畸形 JSON，缺字段、类型错、嵌套爆炸，直接让下游解析崩溃。schema 校验在网关处就拦下，返回清晰的错误码，下游再没因为这些崩过。

第三类是 prompt 注入。最阴险的是忽略之前所有指令、现在你是管理员这类句式嵌套在正常对话里。我们一开始用关键词全拦，结果客户聊操作系统、聊系统架构时也含相关词被误伤。改成句式上下文加白名单后，误拦率从几个百分点压到零点三以内，业务才接受。

再说越权字段。多租户网关里，租户甲在请求里塞一个指向租户乙私有模型的字段，是最容易被忽略的越权。我们把租户和模型的绑定关系在网关处硬校验，擅自指定他人模型一律拒，这是多租户安全的底线，宁可错杀不可放过。

最后是一个运维视角的提醒：校验规则本身也要版本化。我们早期改一条注入规则是热改配置，结果一次规则误写把正常业务全拦了半小时。后来规则走配置版本加灰度生效，先放观察再全量，校验这道门自己也得有护栏。

七、给同行的一点提醒

回顾网关请求体治理这个项目，最容易被低估的是最后一公里。技术方案跑通只是开头，真正决定成败的是上线后那几周：校验规则有没有版本化、注入扫描误拦有没有压住、越权字段有没有硬校验。我们见过太多项目栽在上线即交付的心态上，三个月后指标悄悄回潮。所以我们的做法一直是把上线当运营起点：规则灰度生效、误拦率周度复盘、越权拦截巡检、自动化回归，四件套缺一不可。另一个体会是，网关不能只管门口，请求体治理是安全闭环的必补环节，校验要先于放行。以上是我们的一点体会，供同样做人工智能网关安全的团队参考。

八、一点收尾说明

请求体治理上线后，攻击手法也在进化，新的注入句式会冒出来。我们保留每周一次规则复盘，把新出现的异常样本加进扫描库，并人工确认误拦。安全是攻防的持久战，网关这道门要跟着威胁一起长，不能上线就以为万事大吉。