Fastly AI Firewall 推出运行时控制，但边缘安全才是真正考验

Fastly 于 9 月 21 日推出三项相互关联的 AI 控制功能，包括 Fastly AI Firewall、AI Runtime Control，以及扩展后的 API Security。这一组合发布将模型路由、提示检查、支出上限和智能体限制纳入 Fastly 现有的边缘请求路径。

这一定位也带来了核心矛盾。Fastly 销售的并非又一个孤立的模型过滤器。它希望客户将其基础设施作为应用、AI 提供商、用户和企业 API 之间的控制点。

Cloudflare 和 Palo Alto Networks 已在争夺这一位置的部分市场。因此，Fastly 必须证明其边缘架构能够提供有价值的控制，同时不会带来不可接受的延迟、成本、隐私暴露或部署复杂性。

此次发布正值机器流量在 Fastly 网络中占据更大比重之际。Fastly 表示，2026 年 7 月和 8 月，机器生成的请求已超过网络流量的一半。该公司还称，1 月至 5 月期间，AI 流量的增长速度是人工流量的 6.5 倍。

这些数据来自 Fastly 对自身网络的观察，并非针对更广泛互联网的独立测量。不过，它们解释了为何一家边缘服务提供商会将 AI 治理视为基础设施机遇，而不是独立的安全类别。

Fastly AI Firewall 将边缘变为 AI 控制点

Fastly 的此次发布整合了三项控制能力，分别覆盖生产环境 AI 请求的不同环节。

AI Runtime Control 位于应用与模型提供商之间。应用只需通过一个 Fastly 端点发送模型请求，而不是直接调用每一家提供商。

Fastly 使用虚拟密钥来保护底层提供商凭证。管理员可以将这些密钥与模型、用户、预算和流量限制关联，同时仍可访问公共或自托管提供商。

这种架构让运营人员能够集中查看请求量、令牌消耗、提供商选择和模型响应。它还支持在已配置服务不可用时进行提供商故障切换。

Fastly AI Firewall 则为该控制平面增加了安全检查能力。它会在转发提示前进行检查，并在将符合条件的响应返回应用前加以审查。

该公司表示，防火墙会检测已知的提示注入和越狱模式。提示注入是指不受信任的输入试图替换或覆盖本应约束模型的指令。

客户可以让防火墙运行于记录模式或阻断模式。记录模式会保留请求并记录检测结果；阻断模式则会在匹配请求到达提供商之前将其拒绝。

第三项组件针对调用企业 API 的智能体。Fastly 扩展后的 API Security 可以将传入请求与已发布的 API 合约进行比对，后者定义了服务接受的操作和数据格式。

组织可以观察或阻断违反这些合约的请求。这项控制适用于传统应用、辅助式工作流和自主智能体。

这一区别很重要，因为智能体可能生成语法有效的网络流量，同时尝试执行不受支持的操作。传统的可用性检查无法判断所请求的动作是否属于智能体的权限范围。

Fastly 将这三项组件定位为一个请求路径系统：模型调用可以被路由和计量，提示可以被检查，智能体行为可以在 API 边界受到限制。

根据发布公告，Fastly 宣布时，这三项能力均已可用。此次发布并未将其描述为未来的预览功能或仅限受邀者参与的研究项目。

Fastly 还表示，这些控制能力运行在其现有的全球平台上。该公司称，截至 2026 年 6 月 30 日，该网络容量达到每秒 622 太比特。

Fastly 表示，截至 3 月 31 日，该平台每天处理超过五万亿次请求。这些数据说明了平台规模，但并不能证明新 AI 产品的性能表现。

但战略变化依然清晰。Fastly 已将其交付和应用安全能力扩展到模型请求路径，在这里可以同时执行 AI 支出和安全策略。

这形成了比独立提示过滤器更广泛的销售主张。但它也要求客户将敏感的模型交互置于另一层运营体系之中。

为何 AI Runtime Control 正成为一场基础设施竞争

企业 AI 同时带来了路由、成本和授权三方面的问题。

早期的 AI 应用往往使用一个凭证直接连接一家模型提供商。生产系统则复杂得多，因为团队会采用多个模型、账户、区域和故障切换路径。

智能体进一步放大了这种复杂性。它们能够选择工具、发送请求、检索数据并触发操作，而不需要人工逐一批准每次网络调用。

Fastly AI Runtime Control 试图在这些交互抵达提供商之前将其标准化。虚拟密钥识别调用方，而 Fastly 会在请求路径后续环节替换为实际的提供商凭证。

这可以减少提供商密钥在应用和开发环境中的扩散，也为组织提供一个统一位置来实施速率和预算策略。

Fastly 的运行时文档称，速率限制可按每分钟请求数或令牌数执行。预算规则可在达到配置阈值后提醒管理员，或阻止后续活动。

基于令牌的执行有一项重要限制。Fastly 表示，最终令牌数在响应完成前仍未知，因此令牌限制只能尽力执行。

这意味着控制平面可以约束使用量，却无法保证令牌执行绝对精确。一项高成本响应可能在最终令牌数写入计费记录前就已完成。

同一份文档称，管理员可以检查请求和响应记录。日志可能包括模型名称、虚拟密钥、会话数据、时间戳和令牌数量。

这种可见性具有运营价值，但也带来了治理问题。提示和补全内容可能包含内部文档、客户数据、凭证或个人信息。

在集中管理这些记录之前，安全团队需要明确的数据保留、访问控制和区域处理政策。统一日志只有在组织同时治理谁可以查看它时才真正有用。

Fastly 将流量管理与安全相结合的决定，反映了更广泛的市场转变。AI 网关正从简单代理转变为策略执行点。

例如，Cloudflare 将 AI Gateway 监控与其网络上的应用安全控制相结合。其提示注入控制会为请求分配评分，客户可在防火墙或速率限制规则中使用该评分。

Palo Alto Networks 则从企业安全角度切入。其运行时安全会检查模型、应用、智能体、插件、数据与外部服务之间的实时交互。

这些产品的架构和覆盖范围并不完全相同。不过，它们争夺的是同一个有价值的位置：AI 交互仍可被观察和阻止的节点。

Fastly 的优势在于它现有的应用流量交付和防护角色。已经使用其边缘网络的客户，可能更愿意扩展既有控制平面，而不是部署另一个独立网关。

它的劣势同样直接。买家可以选择已更贴近其模型、身份或数据控制的云平台、安全供应商或专业网关。

这场竞争同时给基础设施提供商和企业买家带来压力。提供商必须将性能、安全、可观测性和成本治理连接起来，且不能产生相互冲突的策略系统。

买家则必须决定权限应归属何处。网络边缘提供广泛可见性，而应用代码则可保留更细致的业务上下文。

没有任何单一层能够看到一切。网关可以检查请求，但应用可能知道某项请求的操作是否适合特定客户或工作流。

Fastly 押注于边缘可以成为通用执行层，同时让应用保留自身的授权逻辑。AI Runtime Control 的价值取决于这两个层面协同得如何。

产品机制也界定了其局限

Fastly AI Firewall 可降低请求路径中的暴露风险，但无法消除提示注入或不安全的智能体行为。

Fastly 将其检查描述为确定性的。防火墙会依据已知的注入和越狱特征检查请求，而不是将每一条提示都发送给另一个生成式模型。

这一选择具有现实吸引力。确定性检查可提供可预测的行为，并避免为每次交互运行第二个模型的成本。

Fastly 还会使用加密边界令牌封装不受信任的输入。随附指令会要求模型将被封装的内容视为数据，而非具有权威性的命令。

这一技术应对了语言模型应用的一项基本弱点。尽管系统指令和不受信任文本的预期权限不同，它们最终都会以相关的令牌流形式进入模型。

因此，恶意文档可能包含旨在操纵读取它的模型的指令。当载荷通过检索内容、电子邮件、网站或其他外部来源进入时，攻击便成为间接攻击。

Fastly 会检查符合条件的输出，以寻找攻击影响模型的证据。管理员可以结合其他请求信息查看检测标签、威胁分类和金丝雀测试结果。

这些控制为已知攻击增加了阻力，但攻击者可以改变措辞、编码、语言或上下文。随着新的规避方法出现，特征系统必须持续更新。

OWASP 在其 2025 年大型语言模型应用主要风险清单中将提示注入列为首位。其防护指南建议采用分层防御，而不是依赖单一过滤器。

这些防御措施包括分离指令与数据、限制模型权限、验证输出、对重要操作要求人工批准，以及监控行为。

Fastly 的文档还揭示了另一项边界。响应检查需要完整响应，因此流式请求会直接通过，不进行输出检查。

流式传输会增量交付生成文本，而不是等待完整答案。它支持响应迅速的聊天界面，但防火墙无法在应用开始接收内容前评估完整响应。

结构性隔离也会为请求增加令牌。Fastly 表示，客户的模型提供商会按照其常规用量对这些额外令牌计费。

这并不意味着这种防护不具备实际可行性。但这确实意味着，客户必须衡量额外的 token 成本在其生产规模下是否仍可接受。

延迟同样需要仔细审视。内联检测会增加处理环节，而用户本已在等待模型推理、工具执行和数据检索。

Fastly 的边缘网络布局应能缩短许多请求的网络距离。但该公告并未提供覆盖完整防火墙与控制平面流程的独立延迟基准测试。

误报则是另一项权衡。与安全相关的讨论、调试提示词和研究内容，可能合理地包含攻击中常见的相同短语。

日志模式让团队可以在阻断前观察这些检测结果。但在评估期间，它也会让匹配的请求继续执行。

阻断模式可降低这种暴露风险，但也可能拒绝有效流量。客户需要根据具体工作负载进行测试，而不能将一项策略视为适用于所有应用。

API 强制执行组件同样依赖准确的契约。过时或不完整的 schema 可能阻断有效的 agent 活动，或允许那些只有在业务上下文中才显现风险的操作。

契约合规不等同于授权。agent 可能携带有效数据调用获准的端点，却是在执行不恰当的目标。

因此，该产品最适合作为更广泛系统中的一层。应用权限、身份控制、工具限制、审计日志和人工审批仍然必不可少。

此次发布之所以重要，是因为它将这些控制能力封装进现有基础设施中。但其重要性不应被误解为：网络检测能够解决完整的 agent 安全问题。

Fastly 在同一请求路径上面对 Cloudflare 与安全厂商的竞争

主要竞争焦点在于对 AI 流量的控制，而非对底层模型的所有权。

Fastly 不需要客户统一采用某一家模型提供商。AI Runtime Control 旨在通过一个通用端点，将请求路由至公共模型和自托管模型。

对于担心服务中断、模型性能变化或依赖单一厂商的团队而言，提供商独立性颇具吸引力。但这也会形成一个客户必须运营并信任的中央中介层。

Cloudflare 采用了类似的边缘策略。其 AI Gateway 负责模型可观测性与控制，而 AI Security for Apps 则通过其 Web 应用防火墙提供提示词、主题和数据相关的检测。

Cloudflare 公布的注入检测系统采用 1 至 99 的分级评分。Fastly 则强调确定性签名、边界 token、检测标签，以及由客户选择日志或阻断行为。

现有文档描述了不同的控制界面，但不足以支持对准确率作出明确比较。独立测试需要采用共同的数据集、配置、模型和攻击方法。

Palo Alto Networks 提供了更广泛的安全框架。其运行时产品描述了针对注入、投毒内容、恶意链接、数据泄露、模型交互和 agent 活动的防护。

这种广度可能适合已将安全运营标准化为 Palo Alto Networks 的组织。Fastly 则可凭借其贴近应用交付的优势，以及现有客户熟悉的架构进行竞争。

专业 AI 安全公司构成了另一项压力来源。它们可以专注于模型评估、红队测试、护栏或 agent 行为，而无需维护通用交付网络。

专业厂商可能在单一威胁类别中快速创新。但它们也可能迫使客户增加一家供应商、一个代理层、一种策略语言和一个遥测存储库。

因此，采购决策将不仅取决于功能清单。团队必须比较部署位置、数据处理方式、模型覆盖范围、策略表达能力、可观测性和故障行为。

故障行为尤其值得关注。当检测、日志记录或策略服务不可用时，内联控制必须决定流量是否继续通过。

故障开放行为可保障可用性，却会允许未经检测的流量。故障关闭行为能维持强制执行，但可能让安全依赖变成应用中断。

Fastly 强调 AI Runtime Control 中的提供商故障转移。采购方应另行验证平台如何处理防火墙检测、日志记录、策略评估和 API 验证中的故障。

供应商整合本身也会带来矛盾。使用一个平台完成交付、应用安全、AI 路由和 agent 控制，可减少运营碎片化。

但这也会增加对单一路径的依赖。配置错误、平台事故或账户遭入侵，可能同时影响多个层面。

具有严格隔离要求的组织可能更倾向于选择独立的提供商或强制执行点。其他组织则会以更简单的运营和统一遥测为代价，接受这种集中化。

Fastly 还必须证明，现有边缘客户希望由该公司管理模型交互。交付 Web 资产与检查完整 AI 对话，会带来不同的隐私和合规预期。

最强的近期采用路径很可能来自现有 Fastly 客户。他们已经通过该网络发送应用流量，也了解其配置模型。

新客户面临的比较则更为困难。Fastly 必须展示足够的安全深度，以与专用厂商竞争，并提供足够的运营价值来证明重路由模型调用是合理的。

这正是此次发布不止是一项功能公告的原因。Fastly 正试图从保护应用，扩展到治理这些应用所产生的 AI 活动。

三个信号将揭示 Fastly 的 AI 安全押注是否奏效

采用证据、独立安全测试和竞争对手的回应，将揭示边缘层能否成为持久的 AI 控制层。

第一个信号是生产环境采用情况。Fastly 最终应披露客户案例，说明哪些模型、工作负载和策略正在通过 AI Runtime Control 运行。

有价值的案例研究应报告部署范围、迁移工作量、被阻断的活动、误报处理方式和运营结果。关于可见性或安全性的笼统表述所能提供的证据较少。

客户还应说明其如何治理提示词和生成结果日志。这些信息将显示，集中式可观测性能否经受隐私、合规与内部访问审查。

第二个信号是对 Fastly AI Firewall 的独立评估。测试应衡量其对直接注入、间接注入、越狱、编码提示词、多语言攻击和无害安全内容的检测率。

测试还应公布误报率、延迟、额外 token 消耗以及在流式传输下的表现。没有这些衡量指标，采购方只能比较架构，而无法比较经过验证的防御性能。

测试必须考虑不断变化的模型和攻击方法。面对已知签名表现良好的控制机制，仍可能难以应对自适应攻击或特定应用攻击。

第三个信号是 Cloudflare、Palo Alto Networks 和专业厂商如何回应。更深度集成的路由、身份、数据丢失防护或 agent 授权能力，都会加大 Fastly 组合平台面临的压力。

Fastly 自身的路线图同样重要。当前文档已经指出实际限制，包括尽力而为的 token 强制执行，以及对流式响应的不完整检测。

弥补这些缺口将强化单一控制平面的价值主张。若维持不变，则会为应用层或竞争性安全层保留空间。

企业团队无需等待市场尘埃落定后再评估此次发布。他们可以从日志模式下的狭窄工作负载开始，并将检测结果与现有控制措施进行比较。

试点应包括具有代表性的无害提示词、对抗性测试、流式响应、提供商故障和预算限制场景。团队还应验证 Fastly 存储哪些数据，以及谁可以访问每条记录。

agent 试验还需要额外测试。agent 应在明确的工具权限和 API 契约约束下，尝试执行有效及未经授权的工作流。

结果应在业务动作层面衡量，而不仅仅是网络请求层面。一个格式正确的请求，仍可能产生不可接受的动作。

Fastly AI Firewall 值得关注，因为它将安全与路由、支出和 agent API 强制执行连接起来。这种组合比孤立的提示词过滤器更贴近生产环境 AI 的运营形态。

悬而未决的问题是，Fastly 能否将其网络位置转化为对 AI 行为的可靠控制权。边缘检测提供了可见性和强制执行机会，但业务上下文仍存在于其他地方。

对于开发者和安全负责人而言，下一步很明确：针对真实工作负载测试 Fastly 的 AI 控制措施，记录每一个盲点，并将结果与竞争性请求路径防御进行比较。该产品的价值将体现在其面对故障和攻击时的可测量表现，而非支撑它的网络规模。