1. 背景

  2022年以来，AI 应用井喷式爆发，各种通用 AI 大模型和一众垂类 AI 应用相继出现，并迅速席卷各个行业。AI 的迅速推广、普及，为社会的各行各业带来强大助力，也为广大用户的学习生活提供诸多便利，但于此同时， AI 应用服务从用户接入、智能体处理、外部调用到模型训练的全生命周期，普遍缺乏透明度和内容安全监管，用户隐私泄露、模型内生安全、越狱攻击、意识渗透等安全威胁的危害越发突出，AI 内容缺乏有效、可靠的技术监管机制，AI 应用安全面临新一轮挑战。

AI应用井喷式增长

  尽管实现全周期的内容安全监管十分复杂，但仅仅在 AI 用户和 AI 应用之间，进行交互内容的监管、过滤却并非不可行，最直观的思路就是部署一个 AI 内容防火墙，也就引入本项目的需求，下文简记为 AI-CFW。

  简言之，本项目的目标即实现一个 AI-CFW 原型系统，该系统部署于 AI 应用和 AI 使用者之间，能够对使用者的提问以及 AI 应用的回复内容进行过滤。应用于实际，AI-CFW 需要满足以下要求：

实时发现恶意指令、越狱尝试、价值观异常的 AI 回复或违反内容合规、数据隐私要求的情况

进行格式回复、拒绝应答或会话阻断等操作

  此项目需求来源于UCAS课程，本鲤主笔。为方便管理，在此文作记录归档。

2. AI-CFW 设计难点与目标

   Agent（智能体） 是目前 AI 应用中比较热门的一个概念，用户通过向 Agent 智能体提出需求，Agent利用其工具、记忆以及规划能力，给出回复满足用户需求。“需求-回复”的交互看似简单，但在网络传输中，却是实实在在历经了比较“漫长”的传输过程（本鲤发现不了解网络的同学实际不知道自己和服务间的流量是怎么传输和处理的，本鲤后面单开一篇，埋坑…）。安全需求是需要场景的，而明确了需求角色之后，场景和目标自然明确，假定“本鲤是一名机构网络的网络管理员（真网管！）”，那么参考下图右边的结构进行分析，我们可以进一步明确 AI-CFW 设计与实现面临的挑战。

AI应用服务过程拓扑

  面对上述网络场景，AI-CFW 设计面临的主要挑战如下：

如何将对所有大模型的访问都纳入监管？

https应用普遍情况下如何获得交互内容？

如何判定大模型输出结果是否违规？

  在设计之初，我们将 AI-CFW 的预期目标设计如下：

  • 流量还原与 AI 机器人的对话内容（包括但不限于文本，图片，文档等）
    • ✓ 相关知识点：流量还原，应用识别，加密内容获取等
  • 研究审核 AI 聊天内容中的违规内容
    • ✓ 相关知识点：字符串匹配过滤，内容理解，虚假信息检测等

3. 已有解法分析：

  我们分析一下行业风口的巨头们都是怎么做的，他们的解法，可能对本项目有所启发。具体而言，目前已针对 AI 发布内容防火墙产品或网关的企业并不在少数，诸如火山引擎、启明星辰、Cloudflare、Kong、Gloo、 Higress、Portkey 和 OneAPI等，本鲤主要梳理了前三个厂商的产品和模式特点。（之后了解到 Portkey 、OneAPI 针对 AI 的原生特性更强，后续再作补充吧）

A. 火山引擎（供给侧 AI 保障）：大模型应用防火墙 —— WAF串接

  火山引擎是字节旗下的云服务综合平台，其推出的大模型应用防火墙（下简称LMs-WAF），主要提供算力消耗防护、提示词识别、优化内容生成和鉴权与用量配置等功能，它更加侧重于对服务侧 AI 业务的防护，力求保证 AI 应用平稳落地，提供可靠、安全、优化等服务。（关于WAF是什么，本鲤后面简单开一篇介绍）

  针对的目标群体是愿意为 AI 业务平稳运营，支付检测保障费用的 AI 企业。

  LMs-WAF 的防护结构如下图所示，包含四维防护优化：接入净化保护（可用性）、提示词注入检测、数据窃取识别、鉴权分析（外部调用、内部投毒）。

火山大模型WAF

  火山 LMs-WAF 提供两种接入方式：通过CNAME接入（试用于未基于火山部署AI业务的企业）、通过火山原生CLB开启TCP监听接入。CLB即负载均衡，实际上基于CLB监听接入的方式也主要是基于CNAME的，至于原因，后面会再解释。下面是两种接入方法的部署结构拓扑：

通过CNAME接入 通过火山原生CLB开启TCP监听接入

  考虑到不同背景的小伙伴，简单介绍一下CNAME（这是域名解析中比较常见的概念，对DNS有了解或者自己鼓捣过小网站的同学应该很熟悉），其余的内容图中很直观，具体不再赘述。

  【CNAME】是域名解析中的一个记录名称，也叫别名记录，这个别名的概念是相对 A(Address) 记录而言的。域名解析的一般过程便是访问A记录，将域名映射为对应的IP地址，而CNAME记录则能够将域名解析为另一个域名，这时你发现只要将原本用户访问的域名A通过CNAME解析到域名B，那么生效后，用户在进行DNS解析时，就会直接去访问B指向的服务器地址了，访问流量走的是另外一条路径（CLB业务基本是这个模式，比如CDN中的加速资源就基本与域名绑定。这里也解释了为何上面说第二种方法实质也是基于CNAME。【火山CLB中间用监听实现内容检测的这个结构很值得思考，或许可能为旁路部署提供经验。不过这里缺乏进一步信息，难成主线，咱有空再来填坑】

  上面说了很多，个人或者小团体实际上很难用火山的模式复刻一个 AI-CFW，因为 LMs-WAF 实际更侧重AI应用的全流程业务优化防护，需要供给侧服务商的加入，个体缺乏号召力，另外这种模式的运营也十分依赖火山云服务本身够硬的能力。

  但是退一步说，LMs-WAF 比较有借鉴意义的是他们在接入层和智能体中间进行的提示词注入检测，以及参照的内容合规标准。

  【提示词注入】是一种 AI 应用攻击方式，通过分工协作的“越狱 Prompt”+“恶意诱导 Prompt”，能够绕过平台和模型原生安全机制，诱导模型生成恶意内容。现实中需要考虑服务可用性和检测严格阈值的trade-off，因而这种攻击难以根除。针对这种安全威胁，火山 LMs-WAF 采用了意图识别、防提示词注入、动态对抗与价值观校准等防护机制，通过利用 AI 能力对抗 AI 攻击，提升大模型面对提示词注入的应对能力：

  • 通过深度上下文引擎，可识别97%隐式攻击

  • 基于千万级对抗样本训练，覆盖20+提示词攻击场景，检出率达99%+

  • 经某大模型服务平台实测，违规内容及价值观偏移回答均下降98%

  【内容合规标准】：《生成式人工智能服务暂行管理办法》中 5 大类 31 个小类规定

B. 启明星辰（用户侧数据脱敏）：大模型访问脱敏罩MADA Mask —— 网关串接

  启明星辰是一家主攻安全服务的综合提供商，目前由中国移动实际控股，专责网信安全，覆盖网络安全、数据安全、应用业务安全等多个领域。启明星辰发布的大模型访问脱敏罩MADA Mask（Model Application Desensitization Access Mask，下简称LMs-Mask），主要关注机构对外访问开放大模型时，在充分保障共有大模型效用的前提下，如何有效避免自身敏感数据泄露的问题，其核心是为用户侧访问提供专业可靠的数据脱敏服务。

  针对的目标群体是机构或企业单位，具体服务模式和接入方式，未得到其公开声明。

  LMs-Mask 的防护结构如下图所示，其核心是保障数据上传过程中的敏感内容识别和安全脱敏：LMs-Mask串接在机构用户访问各种公域或私域大模型的路径上，提供对机构用户的数据脱敏（智能围栏、全链审计），并能够对内容进行智能阻断（NLP识别、优化调整）。

启明星辰LM-Mask

  LMs-Mask 同样提供两种部署方式，实质都是网关串接：本地网关形态部署（串接于企业网络边界出口）、SAAS化代理网关形态（串接公有云，访问特定入口。考虑目前云化的趋势，这应该是目前主流的方式）。下图是SAAS化代理网关形态的结构：

SAAS代理网关接入启明星辰LM-Mask

  简单补充下SaaS的概念，**SaaS（软件即服务）**是一种基于云计算的软件交付模式，通过互联网提供应用程序，用户无需购买、安装和维护软件，只需通过网络浏览器或移动应用程序访问和使用软件。通过SaaS模式的特点，可以简单猜测LMs-Mask的拓扑结构：用户通过软件/浏览器接入启明星辰提供的代理节点，节点支持请求处理和回源转发，并最终返还交付回用户。  

  启明星辰对 LMs 的部署模式进行了分析，简要总结例举在下方：

  • 全私域部署：在机构内部部署满血DeepSeek或其他全功能大模型。这样机构内部使用大模型，数据泄露的直接风险相对不高（并非完全没有）；对应机构的投入成本相对较高。
  • 公共大模型访问开放部署：机构为内部员工提供自由访问的外部大模型。这样机构的投入最少、起步最快；数据泄露风险暴露面最大，最危险。
  • 公共大模型访问罩部署：机构为内部员工访问外部大模型提供一个访问代理，并同时安排数据安全和其他应用安全保护。这样可以在极少的投入下，让机构全员能够获得大模型应用的收益。该部署方式和前两种部署方式并不互斥。（也就是LM-Mask的解法）
  • 混合大模型访问体系化部署：基于AI-R-IAM身份管理、业务分割、网络分域、数据分域的复杂部署方式。这种部署模式适用于大型机构的深度应用环境。

  LMs-Mask的解法比较符合本项目的需求，思路比较值得借鉴。一方面对用户侧上传的数据进行脱敏处理，防止泄露风险同时保障隐私性，另一方面，网关串接的模式对于用户几乎无感，实施相对简单。但是这种方法，数据处理和安全脱敏都较高程度地依赖代理节点，对其性能要求和可靠性要求可能较高。

  由于其未公开产品接入具体方法，本鲤对其本地串接过程和云外接访问过程中数据流的处理还有些模糊，初步猜测应该是基于证书-密钥的还原形式。

  【内容合规标准】：《数据安全法》、《个人信息保护法》

C. Cloudflare：AI gateway —— 反向代理

  Cloudflare的大名无需多言（全球最大的CDN服务商），作为首款全球连通云，其产品线和服务囊括计算、存储、网络全栈，实力非常之雄厚（这里不得不赞，很多时候，CF很像个慈善家…… )。Cloudflare推出的基于其公有云Serverless的 Cloudflare AI Gateway（下简称 LMs-Gateway），是一个用于管理和扩展生成式 AI 工作负载的统一接口，用户可以通过它提高对 AI 应用程序的可见性和控制能力，它支持多方提供商，包括 OpenAI、Google Vertex AI、Azure OpenAI、HuggingFace、Amazon Bedrock 和 Anthropic（最近大火的MCP）等。

  具体而言，LMs-Gateway 的核心功能就是提供一个统一的接口，这个接口可以管理和扩展各种生成式 AI 的工作负载，包括各种访问流和 API 调用。无论模型在何处运行，只需通过将应用程序连接到 LMs-Gateway ，它就可以充当服务与具体服务提供商之间的代理，网关管理者因而可以监控用户交互的过程、进行日志记录，并利用缓存、速率限制、请求重试和模型回退等扩展功能。

  针对的目标群体相对广泛，包括个人和企业用户。

  LMs-Gateway 的结构如下，依赖其本身对多方提供商的支持能力，主要在服务和具体的服务承载工具之间充当 API 代理，整体的拓扑结构类似反向代理，就用户体验而言实际就等同于一个大模型API代理。

Cloudflare：LMs-Gateway

  借由上图中的结构，服务请求都被发送到 LMs-Gateway，网关再进行请求的转发，并从缓存读取响应回递传送给用户。这个过程中，流量进出都经过 Cloudflare ，流量的还原处理应当也是基于证书密钥。

  简言之，Cloudflare 的 AI Gateway 主要功能即一个反向代理，若用户原本直接经过 OpenAI 的 API 访问https://openai ，那么现在仅需把访问服务的 baseURL 换成https://gateway.ai.cloudflare.com/v1/${accountId}/${gatewayId}/openai 即可。

  这个方案有下面几个优点：

  • 只需修改 baseURL 即可接入，不改变 API 格式，接入相对简单
  • 服务是 Serverless 的，不需要用户额外管理任何服务器
  • 借助 Cloudflare 的全球网络可以实现一定的用户接入加速
  • 借助 Cloudflare 的全球网络可以一定程度隐藏掉源 IP，对于访问受限的区域可有奇效

  该方案对应的缺点如下：

  • 所有请求信息包括 API Key 都需经过 Cloudflare ，存在一定安全隐患
  • LMs-Gateway 扩展比较麻烦，目前提供的不支持内容检查过滤

  上面两个厂商的产品，个人很难进行 demo 演示，而 Cloudflare 的 LMs-Gateway 服务又对于个人用户十分友好，因此本鲤以 LMs-Gateway 监控 MCP Server-Time 任务流过程的例子为引，简单演示下这类网关能够达到的效果，主要包含5个步骤：

  1. 在 Cloudflare 平台创建 LMs-Gateway 实例，使用 API 作为 endpoint 连接到应用服务器，创建出口点，也即 baseURL

    LMs-Gateway-API-endpoint

  2. 在 vs code 中通过 cline 配置将大模型 API 站点都配置为从 API endpoint 访问

    LMs-Gateway-Clineconfig

  3. 在 cline 中调用一个 MCP Server：Time，简单执行一个任务，让流量流经 LMs-Gateway，下图以Time为例，简单查询了当前的北京时间

    Cline中调用TIME-MCP Server

  4. 在 LMs-Gateway 中 check 日志看看网关能捕获到什么内容。（通过请求响应的过程，其实可以对MCP请求响应的特点进行分析，这个内容本鲤目前在做，后面也要单开一篇讲）

LMs-Gateway捕获日志
D. 小结

  整体而言，各家厂商发布的 AI-CFW 都呈现出以下共性：

  • 基本都以串接模式（网关or服务代理）接入，确保用户或局域网的访问都可纳入监管
  • 内容合规的判断都借助 AI 赋能，参考某些内容审查标准实施
  • 防护整体要么侧重供给侧业务保障要么关注用户侧隐私保护，并无完全独立的安全第三方（当然了，这样两头不讨好，既引入信任问题，也比较难盈利

  串接尽管需要的条件强，但模式和管理都简单，优点明显，加密流量还原的难点可以一定程度绕过（真要旁路硬做加密解析，其实很头大…），还原基于证书密钥应该可以基本解决；当然如果考虑旁路监听（Note：火山CLB本质还是串接）的话，火山的模式需要再深入……

  通过上面的梳理，思路相对比较明确了：①串接部署：选择串接结构能够解决很多困难，包括覆盖度和流量还原问题，还原采取证书-密钥形式进行解决；管理形式最好是 Serverless，不需要对服务作过多管理。②内容合规审查：串接节点获取到还原的流量内容后，需要进一步关注流量的检查、处理和转发。重点是内容合规的标准和判断、优化方法，需要考虑多模态的复杂情况。

4. 初步计划与设计

  关于整体设计思路：

 ①串接部署：串接结构选择能够解决很多困难，包括覆盖度和流量还原问题，还原思考证书-密钥形式进行解决；管理形式最好是 Serverless，不需要对服务作过多管理。 

 ②内容合规审查：串接节点获取到还原的流量内容后，需要进一步关注流量的检查、处理和转发，重点是内容合规的标准和判断、优化方法，需要考虑多模态的复杂情况。

  关于具体实施落地：

 ①串接参考 Cloudflare 的 AI Gateway，基于证书-密钥进行流量还原。在转发和日志的基础上，需要增加检测、过滤或脱敏。（Cloudflare网关的实操上面已作示意，需要再调研如何基于证书-密钥进行流量还原（配置过程实际可以看出来了，本鲤后续跟进了Fiddler代理抓包的解密，这种形式应当可以借鉴），需要进一步调研跟进如何自建实现同类服务，以及在上面如何附加审查能力）

 ②内容合规审查目前考虑加入 AI （内容理解、虚假检测支持），但只能本地微调（否则会迭代引入泄露）；另外需要基本的关键词匹配、敏感词表作基础匹配过滤的支撑；最后要考虑多模态数据的转换和统一读取问题。（基本是以文字为主，进一步要考虑doc文档、pdf文件、图片等样式数据如何读取和理解的问题

  关于分工和对口：本鲤统筹、推进

 ①：全员（关键，决定思路能不能最终落地，注意这里是三个问题）

 ②：AI 支撑（俊）、关键词&敏感词匹配（博）、多模态读取（杰）

5. 具体设计方案介绍

  下面为最终设计方案：AI-CFW集成到现有防火墙，需要用户信任证书，内容检测模块化插入。

AI-CFW设计方案

  方案整体的设计思路是采用透明代理模式 -【基于证书密钥还原流量 + 模块化内容检测处理】，运行后流量加解密对用户无感，用户无序进行过多的修改（仅需信任根证书）。

  顶层设计：在网络防火墙处插入 AI-CFW，利用其网络边界防护天然优势，对网络进出流量集中监控过滤

  网络结构：目标网络采用接入-汇聚-核心的分层结构，理论可兼容大中小型组网

A. 流量还原：基于自签名证书or内部CA签发

  基于证书-密钥进行流量还原的思路包含自签名和内部自建CA签发两种具体实施方法，用自己颁发的证书密钥和用户建立加密连接可以避免流量还原的问题，并且用户只需要信任根证书，考虑性能、复杂性等因素，这种模式，相比直接利用代理工具构建中间代理有很大优势。

安装自签名证书或基于内部CA签发

  上图是两种实施的流程，它们的核心步骤是基本一致的。

自建证书管理-下发机制

  自签名证书：防火墙生成自签名证书并安装，分发给用户设备并配置信任。用户设备发起HTTPS请求时，防火墙返回证书，建立加密连接后解密流量进行审查，再重新加密转发内部CA签发证书：防火墙向内部CA提交CSR，安装签发的证书。推送内部CA根证书给用户设备并配置信任，后续流程同自签名证书

  内部CA签发证书：防火墙向内部CA提交CSR，安装签发的证书。推送内部CA根证书给用户设备并配置信任，后续流程同自签名证书

B. 内容处理：基于多模态处理+基础匹配+引入本地 AI 赋能

  AI-CFW 整体划分为五个功能模块，流量加解密实际就是A部分流量还原的功能，中间三个模块依次负责多模态数据读取、基础匹配和AI赋能检测的任务，最右侧的处理与告警模块则实际嵌入到中间内容检查的处理周期中，管理员可在防火墙通知中查看反馈。

AI-CFW 内容处理模块
  • 多模态数据读取：处理文本、图片、文档等多类型据，支撑全面内容监控
  • 关键词/敏感词匹配**（基础匹配）**：快速识别风险内容，为基础处理提供判断依据
  • AI-for 内容理解-恶意检测**（引入本地AI赋能）**：深度理解内容，检测复杂恶意信息，提升检测能力和过滤精准度

  参考内容合规标准：《生成式人工智能服务暂行管理办法》中 5 大类 31 个小类规定 & 人类经验

  按照上述 AI-CFW 设计方案，理论上，能够很好地满足需求，并且能够针对多模态数据、复杂内容检测需求进行适应和处理，方案是相对完备的（from teacher，至于具体实现能到达什么效果，就事在人为了！

  简单logging下分工：由于本鲤对网络相对熟悉，整体方案的设计和组织汇总由我完成和把关；多模态的部分由杰完成；基础规则匹配由博负责；AI-for检测部分交由俊处理，本次设计整体是符合预期的。

写在最后

  本组方案考虑基于已有防火墙进行功能集成，本鲤认为这种模式相比基于Mitproxy代理等中间代理的模式要更好一些，简单、易用，用户可接受，也便于管理。实际上要真正用的话，只能尽量考量串接对流直接作处理，旁路模式更类似操作日志，飞走这条路可以 follow 下火山CLB旁路监听的实现模式。

  整体来说最后给出的这个方案只是比较完整和系统，完成了部署网络结构和整体框架的界定，至于具体的检测需求和目标明确，需要在各个模块特定的问题中界定和解决，比如对敏感内容的修改、优化，最基础的对文本模特检测的支撑等等。

Refer：如有侵权，请联系删除

上面埋了几个坑，简单记个账，不能吃霸王餐：

  1. 关于WAF你需要知道什么？
  2. 火山CLB旁路监听实现内容检测
  3. 用户和web服务间的流量传输处理过程概览
  4. MCP请求-响应的特点