企业级 AI Agent 网关：从\”三层防御\”到\”可证明的安全\”
——一名架构师的工程实践与反思
时间：2026 年 7 月 背景：当 GPT-5 .5可以写代码、Copilot 能操作生产环境时，你的安全架构还停留在 API Key 层面吗？
写在前面
这篇文章不讲概念。它来自于我过去一年多以来在 AI Agent 安全网关上的工程实践——作为架构师，设计和构建了一个三层的 AI 智能体治理网关体系。
我说\”三层\”不是架构图上的漂亮分层，而是每一层都经历过真实压测、真实攻击样本、真实的\”这里设计错了，重来\”的循环。
到 2026 年 7 月，这套体系已经完成了：
- G0-G4 全门禁验收通过（项目立项、许可证审核、技术 Spike、证据链、发布门禁）
- Red Queen 验收委员会审查通过
- 全链路交付包自动化产出（含 release receipt、hash 验证、运行时溯源）
- Redis L2 多副本门禁通过 1/2/3 副本压测
- Mythos 红队样本库达到 5794 条，覆盖 OWASP LLM Top 10 全部 10 个轴
但更重要的是，这篇文章会坦诚地分享哪些走对了、哪些还不够，以及一个架构师独立完成这件事的真实边界。
如果你正在评估 AI Agent 安全方案，这篇文章希望能帮你省掉一些弯路。
一、问题空间：AI Agent 给安全带来了什么新东西？
2025 年到 2026 年，做 AI 安全的团队普遍在回答三个问题：
但 Agent 不再只是\”对话\”，它开始真正操作生产环境。
当一个 Agent 可以：
- 执行 SQL 查询
- 调用内部 API 修改配置
- 自动部署代码到生产环境
- 跨系统申请访问敏感数据
原本的三个问题就变成了一个新问题：
你怎么证明——不是因为相信模型不会犯错，而是因为架构上就不允许它越权？
这个问题的本质，是把安全从\”检测\”推向了\”证明\”。客户要的不是一个号称能防住的系统，而是一套可以复现、可以审计、可以验证的安全证据链。
二、架构决策：三层分离，而非一个大网关
2.1 为什么不是单一网关？
最常见的做法是一个统一的 API Gateway，把安全策略、路由、限流全部放在一层。Kong、APISIX、自定义 Envoy Filter 都是这个路线。
但我选择拆成三层。原因来自对实际攻击模式的观察：
单一网关的问题：
一次绕过 = 全盘突破
策略膨胀 = 性能退化
攻击面汇聚 = 单点失守连锁反应
这不是理论推演。在 Mythos 红队样本库（5794 条用例）中，我观察到针对单一网关的\”渐进式绕过\”攻击路径——攻击者先用低危请求探测策略边界，摸清规则后再构造绕过 payload。单一网关没有纵深，被摸清就等于被突破。
另一个更务实的理由是：三层可以独立演进，独立压测，独立失效。 这在后面压测数据中会被验证。
2.2 三层架构及各自的决策逻辑
第一层：协议网关（Shield）
职责：在协议层做准入控制。
端口：8804（gateway），8805（PMF seal）
设计原则很明确——不分析语义，不解析意图：
请求到达 → 检查 Inflight 水位 →
低于阈值 → 放行（签发
