设想这样一个场景：AI工厂中的一个智能体检索到一份文档，其中暗藏了一条用户从未打算让智能体执行的指令。智能体按照指令打开连接，通过模型上下文协议（MCP）调用工具，提取一条无人请求的记录，并将其发送到未经批准的位置。本应拦截这一行为的防护机制是同一容器中的边车，因此智能体先将其关闭。日志也由智能体控制，所以该事件从未被记录。整个过程不到1秒。没有人发现，因为路径上没有任何组件能够发现。
这并非罕见的故障。只要控制措施与智能体位于同一信任域，遭入侵或被误导的智能体就能禁用或绕过这些措施，甚至篡改证据，这种故障就会成为常态。简而言之：不能让智能体监管自身。
The F5 Application Delivery and Security Platform可交付并保护每个应用和API。接下来是AI智能体，而它们的行为有所不同：智能体会调用模型，通过MCP调用工具，与其他智能体通信，并访问工厂内外的API。要创造价值，智能体需要以受控方式访问沙箱之外的模型、工具、API和数据，而这些交互必须始终受可执行策略的约束。NVIDIA OpenShell参考架构正是围绕这一需求构建的，NVIDIA将在NVIDIA GTC Berlin上推出该架构。它将智能体的运行时权限、硬件强制执行和推理分别部署在三个层级的NVIDIA硬件上，并为合作伙伴参与这些层级之间的路径留出空间。要清楚说明各方的职责，最直观的方式是跟随一个请求走出沙箱。
NVIDIA OpenShell Reference Architecture 的作用
该参考架构以代理不可信为前提，并据此对硬件进行隔离。
在面向安全AI智能体的NVIDIA OpenShell参考架构中，NVIDIA OpenShell在NVIDIA Vera CPU上运行，并管理智能体的运行时权限。其监督程序会评估出站请求，对已配置的HTTP、GraphQL和MCP流量实施精细控制，保护凭据，并记录每项策略决策。智能体在沙箱中运行，而管理智能体的监督程序则不在沙箱中运行。
NVIDIA Sentry在NVIDIA BlueField-4 DPUs上增加了一个独立的硬件监控和策略执行层。该层位于代理无法访问或修改的隔离安全域中，可提供威胁检测、请求和响应检查、代理治理，以及毫秒级遏制。NVIDIA Sentry是一个可选层；在NVIDIA Vera Rubin系统中，它位于通往模型的路径上。
NVIDIA Vera Rubin NVL72基础设施运行智能体调用的模型。因此，该架构已能从智能体无法触及的基础设施层面，决定智能体是否可以执行操作，并监控其行为。在此基础上，F5通过专为AI流量构建的内容检查、红队测试和应用交付能力，对这些控制措施形成补充，这也延续了我们与NVIDIA在智能体网络安全领域的合作。
OpenShell和NVIDIA Sentry决定的事项
OpenShell能够识别发出请求的代理、请求所依据的策略，以及目标和方法是否获准。为提供额外保护，NVIDIA Sentry使用NVIDIA DOCA在NVIDIA BlueField-4上运行，可独立监控代理、在芯片中实施策略，并在数毫秒内隔离代理。两者协同工作，在代理自身控制范围之外判定代理是否可以执行操作。这正是该设计的要点。
运行时权限、行为监控和AI专用内容检查可提供相互补充的多层保护。F5还可检查受支持的提示词、模型响应和工具调用，以发现提示词注入、越狱和敏感数据泄露，从而补充OpenShell的运行时治理，以及NVIDIA Sentry的持续行为监控和硬件隔离策略执行能力。
F5检查智能体发送和接收的内容
F5 AI Guardrails会检查从执行路径路由至自身的受支持流量，包括通过OpenShell所控制协议传输的提示、模型响应和工具调用。它会对检查结果执行三项操作：阻止提示注入、越狱以及不符合策略的工具调用；在敏感数据离开前将其隐去；将每项决策记录到会话记录中以供审计。OpenShell和NVIDIA Sentry可以获取其判定结果和遥测数据，因此，根据运营方的策略，被阻止的请求可转化为智能体级决策，最高可采取遏制措施。由于拦截发生在执行路径上，而非智能体的容器内，因此智能体无法禁用Guardrails或绕过它进行路由，也没有可供关闭的边车。
F5 AI Red Team可检验防护机制是否可靠。它沿用户使用的相同路径对智能体和模型发起攻击，无论私有还是公共环境均适用；其发现会转化为防护策略，使防御措施能够跟上所管控智能体的发展。
治理智能体还意味着要证明它执行了哪些操作。F5控制平面保存会话记录，包括用户、提示词上下文、工具调用和已批准的参数。OpenShell保存其策略决策。NVIDIA Sentry保存系统记录，包括文件访问、内核调用和DPU数据包指标。将这些记录关联起来，即可根据智能体无法篡改的数据源，形成一条完整时间线，呈现模型的意图、智能体尝试执行的操作及其实际执行的操作。
The F5 AI Security Platform控制平面和AI Red Team在AI工厂内部的服务器端运行。智能体调用的生产推理模型在NVIDIA Vera Rubin NVL72上运行，AI Red Team也使用GPU资源进行安全测试。AI Guardrails仅需Arm CPU，因此可在NVIDIA Vera和BlueField-4上运行。以下两种参考架构展示了各组件的部署位置。
基于NVIDIA OpenShell的两种F5参考架构
在NVIDIA的三层架构之上进行部署：Vera上的AI Guardrails应用于OpenShell内的智能体框架；NVIDIA BlueField-4上也部署AI Guardrails，使其不受智能体故障影响，并在AI工厂需要时与数据平面协同运行；控制平面和AI Red Team则与模型一同部署在Vera Rubin NVL72上。由此形成两种参考架构。两者均基于NVIDIA OpenShell参考架构构建，采用相同的策略和控制平面，区别在于智能体路径中部署的组件。
参考架构1：F5 AI Guardrails与NVIDIA OpenShell和NVIDIA Sentry
适用于按设计运行NVIDIA技术栈的运营方。F5 AI Guardrails在同一策略下部署于两个位置：一处位于NVIDIA Vera上，应用于OpenShell内的智能体运行框架；另一处位于集成到NVIDIA Sentry中的BlueField-4 DPU上，智能体无法访问。前者可在智能体发送内容时进行拦截，后者则无法被智能体关闭。Guardrails可阻止、隐去和审计路由至其中的受支持流量；在BlueField上，其判定结果可供NVIDIA Sentry使用，以立即遏制智能体。无需额外硬件。采用NVIDIA技术栈标准的NVIDIA Cloud Partner无需进行其他更改，即可获得内容检查能力。
支持更大规模和企业级交付。F5 BIG-IP Next for Kubernetes 作为工厂的数据平面，与NVIDIA Sentry一同运行在NVIDIA BlueField-4 DPU上，也可运行在主机CPU上；F5 AI Guardrails则在其中按照同一策略运行。NVIDIA Sentry执行基本策略，BIG-IP Next for Kubernetes承载流量。BIG-IP Next for Kubernetes与NVIDIA Dynamo集成，在Vera Rubin NVL72上的各模型实例之间路由代理和应用流量并进行负载均衡。它可隔离租户、扩展并保护模型上下文协议（MCP）连接、管理各租户的令牌用量，并为运维人员提供跨租户和模型的统一视图。BIG-IP Next for Kubernetes还会将运维人员的外部出站策略应用于经其路由的流量，与OpenShell的运行时访问控制和NVIDIA Sentry的基础设施策略执行形成互补。
选择权在运营方。可以将AI Guardrails引入OpenShell和NVIDIA Sentry，也可以添加内置AI Guardrails的BIG-IP Next for Kubernetes。两种方案采用相同的策略和控制平面。第二种方案还为整个工厂增加了租户隔离、出口控制和流量管理功能。
这里单独列出一项数据，因为它是独立测量的，与安全架构分开。在The Tolly Group对搭载NVIDIA BlueField-3 DPU的BIG-IP Next for Kubernetes进行的测试中（报告编号#226104，发布于2026年3月），BIG-IP Next for Kubernetes的令牌吞吐量比测试基准高40%，同时将数据路径从主机CPU卸载。这项数据仅衡量BIG-IP Next for Kubernetes自身的数据平面，不包括本文所述的检查功能。在AI领域，性能直接影响经济效益。
始终驻留在AI工厂内的安全防护
在完全自托管的部署中，F5安全处理和审计记录均保留在运营方的环境内：控制平面和Red Team与模型一同位于服务器端，检查则在Vera和BlueField-4上进行。对外部模型和服务的访问仍受企业策略管控；图中标示公共目标位置并非没有原因。要将每个提示和响应都保留在AI工厂内，还需要使用本地托管的目标位置，并限制外部出站流量。该架构可实现这一点。是否这样做由运营方的策略决定，而BIG-IP Next for Kubernetes会强制执行该出站策略。
智能体时代与其说带来了新的安全要求，不如说是将最重要的控制点转移到了智能体的出站流量路径上，并部署在智能体无法触及的基础设施中。F5深耕此类路径已有30年。在NVIDIA OpenShell Reference Architecture中，智能体无法通过交互绕过这条路径。
如需了解更多信息，建议访问我们的F5 AI Security Platform、F5 AI Guardrails、F5 AI Red Team和F5 BIG-IP Next for Kubernetes网页。
关于作者
Kunal Anand担任首席产品官，负责领导F5产品组织。他负责产品愿景、战略和执行，推动开发突破性解决方案，以应对关键挑战，并为客户打造卓越体验。在此前担任首席技术与AI官期间，Kunal制定了公司的技术与AI战略和愿景。 加入F5之前，Kunal曾在Imperva同时担任首席技术官和首席信息安全官。2018年，Imperva收购了他于2013年联合创立的应用安全初创公司Prevoty，他也由此加入Imperva。在加入Prevoty之前，他曾担任BBC Worldwide技术总监。Kunal拥有深厚的创新经验和技术专长，曾在Gravity、MySpace和NASA Jet Propulsion Lab担任领导职务，负责安全、数据、技术和工程团队。 Kunal在AI和机器学习领域拥有超过15年的经验，涵盖模型训练、运用AI驱动的算法增强产品，以及设计和实施AI架构。 Kunal拥有Babson College计算机科学理学学士学位。
Kunal Anand 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。