在之前的一篇博客中，我曾指出，在应对Mythos级模型时，在哪里拦截攻击比能否检测到攻击更重要，而流量路径是推理型对手无法绕过的唯一控制点。本文将这一观点延伸到企业内部：当组织开始应用AI后，究竟有哪些内容会沿这条路径传输，以及答案为何会改变我们的安全设计方式。
几个月前，我旁听了一场企业AI讨论。和大多数此类讨论一样，大家一开始就在问：应该使用哪种模型？是自行运行，还是调用公共模型？如何提高准确性并减少幻觉？这些问题都很重要。但没有人问，选定模型之后会发生什么。
接下来会发生这些事情。用户发送提示词。应用接收提示词，验证用户身份，从文档存储或数据库中提取上下文，并调用若干内部API。智能体可能会判断需要使用某个工具。组装后的请求到达模型，由模型生成令牌。这些令牌可能是答案，也可能是触发下一次API调用、下一个工作流或记录系统变更的指令。
从这个角度看，模型只是一个更长链路中的一个组件。我所说的推理路径就是这条链路，而本文基于一个简单的观察：推理路径就是流量路径。
“传统流量承载数据。推理流量承载意图、上下文和决策。”
推理路径究竟是什么
训练让模型学会如何完成任务。推理则是将训练好的模型投入使用。当员工要求企业助手“总结最新结果，并为领导团队起草一封电子邮件”时，该请求大致会经历以下过程：
用户 → 应用 → 身份 → 上下文和检索 → API → 智能体 → 模型 → 工具 → 模型 → 响应 → 用户
这一过程中的每一跳都属于网络和应用流量。每一跳都有端点、延迟和路由决策，并关联相应的身份。它承载数据、消耗预算，并且越来越多地被赋予执行操作的权限。
我的同事Lori MacVittie今年早些时候提出了一个相关观点：推理是生产环境中的运行时行为，其运作方式类似于应用层，涉及用户、流量模式、延迟敏感性、故障模式、成本限制和安全风险。F5首席产品官Kunal Anand将同一过程描述为一条新的价值供应链：从提示词到入口，经过工作流和推理，再返回用户。接受这一框架后，安全讨论也必须随之转变。F5产品管理副总裁（AI安全）Mani Ganesan在近期的博客《AI现已成为攻击面，您准备好保护它了吗？》中探讨了这一转变对攻击面意味着什么。
应当摒弃的四个假设
随着CISO加强AI安全防护，以下4种固有观念需要摒弃：
- “一切都围绕模型。”模型之所以备受关注，是因为它是可见的部分。但提示词可能包含敏感数据，检索步骤可能会调取机密记录，智能体可能持有API凭据，而它调用的工具可能具备数据库写入权限。只保护模型，就像只加固数据库，却忽略与其通信的应用和API。整个交互路径都是攻击面。
- “从试点到生产只是扩展规模。” 试点通常只有一个模型、少量用户、一个应用，以及需要人工审批的访问权限。生产环境则截然不同。F5《2026 年应用策略现状报告》发现，各组织平均需要协调7个AI模型；77%的组织表示，推理而非训练现已成为其主要AI活动；52%的组织会将多个模型串联或编排在一起。这并非只是在同一架构中增加用户，而是采用了不同的架构，安全模型也必须随之改变。
- “速度、安全和治理是彼此独立的层面。”以包含个人信息的提示词为例。在请求从用户传输到模型的过程中，必须对其进行检查，按策略要求隐去敏感信息，将其路由到获准使用的模型，并进行监控和日志记录以供审计。原本判断“此请求应发送到哪里？”的同一决策点，现在还必须判断“此请求是否应该发送到那里？”。这是一个统一的流量处理决策，而不是三个拼凑在一起的功能。
- “我们可以将单点工具拼接起来。”组织当然可以自行搭建技术栈，包括API网关、WAF、DLP、IAM、AI护栏、模型网关、可观测性、SIEM、智能体控制和MCP安全。这些工具本身都没有问题，问题在于它们之间的衔接。设想一个请求要经过6个控制点，每个控制点都有自己的策略引擎和身份上下文。谁能确认输入提示词的用户与当前调用工具的是同一身份？谁能看出API调用、模型调用和工具调用属于同一笔事务？谁能在整个流程中实施一致的策略，并在事后证明发生了什么？
我在上一篇博客中指出，推理型攻击者首先会寻找系统之间的衔接漏洞。对于无恶意但偏离策略的智能体，情况同样如此。
当流量开始承载意图
AI为熟悉的“请求、路由、策略、响应”序列增加了新的阶段：上下文、检索、编排和工具调用。但更深层的变化在于流量所承载的内容。传统流量承载数据，而推理流量承载意图、上下文和决策。
这一点对智能体尤为重要。能够回答问题的助手是一回事，而能够读取客户记录、创建工单、发送电子邮件、执行代码、更改基础设施或发出付款指令的智能体，则完全是另一回事。推理路径由此变为行动路径，错误决策的影响范围也不再局限于信息层面。
推理事务成为新的安全单元
传统安全以用户、设备、应用、API、工作负载和数据为考量对象。零信任让我们不仅要问“您是谁？”，还要问“您要访问什么？”。AI系统要求我们提出第三个问题：“您要求AI使用哪些数据、通过哪个模型执行什么任务，以及这次交互可能触发哪些操作？”
要回答这个问题，需要综合考虑上下文，而现有的任何单一控制措施都无法掌握全部信息。例如，一名通过身份验证的财务助手用户发出请求，将机密财务数据传入外部模型，再交由财务智能体处理，最终调用ERP API创建付款指令。仅凭用户身份无法作出这一决策，必须基于整个事务进行判断。
正因如此，身份、应用安全、API安全、AI安全和流量管理正在融合。它们共同聚焦于推理事务，即身份、提示词、上下文、模型、数据、工具、输出和操作的组合。与HTTP请求相比，推理事务包含的信息要丰富得多。
一旦从事务的角度思考，安全就不再是单一检查点，而会形成闭环。在推理之前，需要判断请求者是谁、提供了哪些数据、提示词是否具有恶意，以及应由哪个模型接收该请求。
在推理过程中，需要判断请求是否符合策略和预算要求，以及智能体是否正尝试调用从未获准使用的工具。推理完成后，需要判断响应是否可以安全返回、是否触发了操作，以及需要记录哪些内容。每项判断都必须在流量流经的位置作出，因为只有在那里才能同时获得全部上下文。
这对CISO意味着什么
这种演变模式并不陌生。单体架构演变为分布式应用，客户端-服务器架构演变为API和微服务，边界安全也逐渐转向可感知身份和应用的控制机制。每一次演变中，负责交付流量并保障其安全的基础设施都会成为战略重点。推理是这一演变周期的下一阶段。
因此，需要向架构团队提出的问题不只是模型部署在哪里。还要问：推理流量流向何处、承载哪些内容、可以访问什么、会做出哪些决策，以及可以触发哪些操作。最后再问一个最棘手的问题：如何在不降低应用性能的情况下，对这一切实施策略？
因为在AI时代，最重要的安全边界可能不再位于模型周围，而是位于进出模型的路径上。
要进一步了解F5如何应对这一问题，请访问F5 AI Gateway页面。此外，也请务必阅读我之前的博客文章《在网络边界阻止前沿AI：为何内联控制是抵御Mythos级模型的核心优势》。
关于作者
相关博客文章
WAF和API发现技术在保护智能体AI应用中的作用
智能体AI系统的功能和集成会在运行时快速变化。要以同样的速度保障其安全，需要通过API发现和Web应用防火墙（WAF）实施切实可行的控制措施。
