一、AI 业务正在改变 Web 防护的精度边界随着大模型对话、AI 编程助手、AI 客服、AI 搜索等应用大规模上线用户与系统之间的交互内容越来越接近代码——一句正常的请求可能包含 SQL 语法、HTML 片段、命令行结构。传统 Web 防护引擎在面对这类请求时很容易误判为攻击载荷。两个真实场景场景一AI 对话接口的误拦某 AI 大模型平台的对话窗口里终端用户输入了一段 SQL语句希望 AI 帮忙优化查询性能。这段请求在到达 AI 推理服务之前先经过了部署在业务入口的 Web 防护引擎—从语法层面看输入框里的内容确实是一段可执行的 SQL命中了规则引擎里的 SQL 注入特征请求被直接拦截。AI 后端从未收到这条对话用户在前端看到的是一次失败的请求。Web 防护并没有判断错它只是无法判断这句 SQL 在当前业务上下文中究竟是用户想让 AI 帮忙优化的素材还是针对该 AI 平台自身数据库的注入攻击。场景二零售采购订单的误拦一家服装零售企业的供应商在采购系统中提交订单字段中含 “order by 5-12”——表达5月12日交货。这段文本同时匹配 SQL 注入的特征模式ORDER BY 后跟算术表达式被规则引擎判定为攻击。这类误判不是 Bug是 Web 防护行业当前架构下的结构性代价为了拦住越来越复杂的攻击变体安全引擎引入了语义分析能力。语义引擎泛化能力的提升伴随着误报率的同步上升。业内对这套架构的实测显示部分场景下误报率可逼近甚至超过 25%——意味着每四个正常请求中就有一个被误拦。二、EdgeOne 的做法让 AI 在两个层面同时参与EdgeOne 的方案是三层架构规则引擎 自研语义引擎 旁路 AI 分析引擎。第一层规则引擎独立运行——已知攻击的精准消化规则引擎是基础层。对已知 CVE 和固定特征攻击正则匹配是最快最准的手段。为什么不能跟语义引擎合并把规则匹配和语义分析放在一个模型里同时学结果是规则匹配的精准度被语义引擎的泛化能力拉低。规则引擎独立运行的工程价值是把绝大多数已知攻击在第一层就消化掉让进入语义引擎的流量是必须靠理解才能判断的部分——语义引擎在更小的样本空间里工作精度才能拉满。第二层自研语义引擎按攻击类型独立建模EdgeOne 采用自研语法级安全检测引擎核心由 Bison/Flex 语法分析器与自定义语义评分函数组成。Hyperscan 做入口预过滤Bison/Flex 按攻击类型独立语法文法做解析SQLi 基于 MySQL 方言子集XSS 围绕浏览器执行上下文多层解析。不构建完整 AST边解析边在 semantic action 中累计安全信号输出结构化 RiskScore。对 SQL 注入、XSS、命令注入分别独立建模——不用一个通用模型一锅端。为什么必须独立建模 SQL 注入和 XSS 在语法层面本质不同●SQL 注入关注的是数据库语句的可执行性——引号闭合、UNION 拼接、注释截断、ORDER BY 后的算术结构等●XSS 关注的是脚本在浏览器的执行链条——标签嵌套、属性注入、事件触发、编码绕过等●命令注入又有自己的特征空间——管道、反引号、子shell用同一个模型同时学这三件事结果就是三件事都学得不够透。通用模型必然在每一类上做妥协每一类攻击的判别精度都做不到极致。EdgeOne 选择对每一类攻击单独建模、单独训练、单独调优——工程更重但每一类的精度都能拉到上限。测评数据内部测评集●单独语义引擎拦截率超过 80%误报率不到 0.1%旁路 AI 分析引擎上线后目标将线上误拦截率压至 0.01% 以下●规则 语义 少量加白的综合方案召回率超过 95%●语义引擎能识别规则引擎覆盖不到的48种攻击变体——MSSQL 方言、PG_SLEEP、UNION 变形等。当前进度●SQL 注入已上线运行●XSS 跨站脚本Q3 内上线●命令注入Q3 内上线●三大主流 Web 攻击类型全覆盖Q3 内上线第三层旁路 AI 分析引擎——误报纠错与策略自生成模型再准也覆盖不了所有客户的业务上下文。语义引擎在训练阶段没见过 “order by 5-12 表达 5月12日交货” 这种业务表达也没见过用户在 AI 对话接口里随口让 AI 写 SQL 的语境——这些看起来像攻击但意图完全正常的请求会一直留在残留误报里。EdgeOne 的解法是在前两层引擎之外加一层旁路 AI 分析引擎——不直接拦截流量对线上实时请求做聚合分析自动识别两类异常●**大范围误拦多个正常请求被语义引擎误判为攻击●定向攻击透传**某种特定攻击手法绕过了语义引擎发现异常后AI 分析引擎自动生成修正策略下发回前两层引擎。这一层的每一个设计都对应一个具体的工程约束●旁路而不是串行运行——如果 AI 分析串行在请求链路上每个请求都要等推理结束才能响应业务延迟会无法接受。旁路意味着 AI 分析跟实时拦截是两条独立路径互不阻塞。●聚合分析而不是单点判断——单条请求看不出是误拦还是攻击。order by 5-12 这条字符串孤立来看像 SQL 注入只有把同业务接口、同时间窗口下的请求一起看才能从单条像攻击变成一群正常用户的相似行为。●路径级而不是全局加白——给某个业务接口加白等于全局放行攻击者会立刻找到这个口子去打。把策略限定在具体接口下这个加白只对该接口的语境生效其他接口的防护一点不动。●即生即消而不是永久策略——业务场景在变。一周前正常的某个用户行为可能因为业务调整就消失了固化的策略会变成新的误拦源甚至可能被攻击者反向利用。AI 分析引擎只在异常场景持续期间维持策略场景一消失策略立刻撤回。举个反例某接口因为一次产品功能上线临时加白三个月后产品下线了加白策略却还在。攻击者通过历史接口探测发现这个口子从这条僵尸通道打进来。即生即消意味着策略和业务场景绑定场景消失策略 24 小时内自动撤回不留尾巴。这一层解决的是模型能力之外的问题——模型在训练阶段无法穷举所有客户的真实业务上下文但聚合后的线上流量里有上下文可读。过去依赖客户安全团队人工处理的误报运维被自动化了。该能力全量上线后目标将线上实际误报率压至万分位以下。三、回到开头那两个场景**AI 对话接口**接入后AI 分析引擎从聚合的请求里识别出该接口的语义模式属于正常对话——前后没有引号闭合、没有恶意载荷拼接自动生成针对该接口的加白策略。其他业务接口的 SQL 注入防护完全不受影响。**零售采购订单**语义引擎结合上下文判断 “order by 5-12” 是日期表达而非 SQL 注入语法直接放过。**这类场景的共同点**用户输入里含可执行语句的结构但意图完全正常——是面向 C 端用户、用户输入不可预测的业务最常见的误报场景。四、谁最需要这次升级AI 对话与 AI 助手平台——用户与 AI 交互时大量包含可执行语句结构是最容易触发语义引擎误报的场景。AI 分析引擎根据聚合上下文自动修正。即时零售 / 电商平台——每个误拦都是一个真实用户无法下单。路径级加白让业务关键路径的误拦自动消除。Web3 / 区块链平台——用户交互频繁且不可预测传统全局加白风险高。AI 分析引擎的策略精确到路径和场景。游戏官网 / 社区——用户在论坛、评论区输入大量含 SQL 关键字、HTML 标签的内容。AI 分析引擎自动处理不需要人工维护加白规则。五、下一步想了解 Web 防护 AI 能力是否适合你的场景→ 和方案专家聊聊