# Beyond Ingress: How We’re Securing AI Traffic and Bridging BIG-IP with NGINX Gateway Fabric

**URL:** <https://community.f5.com/t/beyond-ingress-how-we-re-securing-ai-traffic-and-bridging-big-ip-with-nginx-gateway-fabric/77467>\
**Category:** F5 Technical Articles\
**Tags:** security, nginx, big-ip, application-delivery, ai\
**Created:** [October 7, 2026, 7:20pm UTC](https://community.f5.com/t/beyond-ingress-how-we-re-securing-ai-traffic-and-bridging-big-ip-with-nginx-gateway-fabric/77467 "2026-10-07T19:20:02Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Akash\_Ananthanarayan](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/akash_ananthanarayan/32/13333_2.png) [@Akash\_Ananthanarayan](https://community.f5.com/u/Akash_Ananthanarayan)\
**Post date:** [October 7, 2026, 7:20pm UTC](https://community.f5.com/t/beyond-ingress-how-we-re-securing-ai-traffic-and-bridging-big-ip-with-nginx-gateway-fabric/77467/1 "2026-10-07T19:20:02Z")

</div>

## Introduction:

As the industry rapidly rallies behind the **Kubernetes Gateway API** , platform, NetOps, and SecOps teams are facing a new set of immediate architectural challenges. Instead of managing separate routing silos, enterprise teams are asking two fundamental questions:

1. _**How do we bring our enterprise edge (specifically our F5 BIG-IP fleet)** seamlessly into modern Gateway API architectures without operational churn?_

2. _**How do we govern and secure AI inference workloads (LLMs)** running inside our clusters without drowning in sidecars, bespoke proxies, or application code changes?_

With the release of **[F5 NGINX Gateway Fabric (NGF) 2.7](https://github.com/nginx/nginx-gateway-fabric/blob/main/CHANGELOG.md#release-270)**, we tackled both issues head-on. By adding native support for edge-to-cluster integration and gateway-level AI security, NGINX Gateway Fabric helps organizations simplify their infrastructure while strengthening their security posture.

Below is a breakdown of why these two capabilities matter, how they work under the hood, and what the deployment workflows look like.

## **1. Bridging the Enterprise Edge: Introducing GatewayLink**

![image](https://d20hrnpixdzcsd.cloudfront.net/original/3X/b/b/bb459a95c20c34ac6ff2df713e3d12eafd5ae523.webp)

### **The Problem It Solves**

For years, teams using classic ingress controllers relied on tightly coupled integrations to bridge BIG-IP with Kubernetes. This setup gave NetOps teams their familiar, rock-solid perimeter control on BIG-IP (hardware SSL offload, massive DDoS mitigation, and global traffic management), while letting DevOps engineers route traffic dynamically inside Kubernetes.

However, microservice pods in Kubernetes are inherently ephemeral. Their IPs change constantly. Forcing external enterprise load balancers to directly track hundreds of shifting pod endpoints across multiple namespaces creates unnecessary configuration churn on the edge **Application Delivery Controller (ADC)** control plane—the system responsible for managing, securing, and optimizing application traffic at the network edge (in this case, your F5 BIG-IP).

Furthermore, as teams migrate to the Gateway API, they need that same clean separation of responsibilities without reinventing their ingress plumbing.

### **Enter GatewayLink & ExternalLoadBalancer**

In NGINX Gateway Fabric 2.7, we introduced GatewayLink via an extensible ExternalLoadBalancer resource.

- **Zero-Code Integration** : It bridges F5 Container Ingress Services (CIS) and NGINX Gateway Fabric without requiring custom CRD acrobatics or CIS code changes.

- **Eliminates Control Plane Churn** : BIG-IP forwards external traffic to a predictable, highly stable entry point inside the cluster—the NGINX Gateway Fabric data plane pods. NGINX Gateway Fabric then handles dynamic Layer 7 routing and service discovery directly to application pods.

- **Role Separation Restored** : NetOps manages edge security, certificates, and perimeter traffic on BIG-IP, while cluster operators and developers retain full autonomy using standard Gateway API resources (Gateway, HTTPRoute).

🎥 **Watch the Step-by-Step Walkthrough:** For a complete configuration walkthrough showing how CIS discovers NGINX Gateway Fabric, connects the BIG-IP pools, and routes edge traffic to your workloads, watch the video below.  
**Bridging the Enterprise Edge to Kubernetes with F5 BIG-IP and NGINX Gateway Fabric**

[![](https://d20hrnpixdzcsd.cloudfront.net/original/3X/8/e/8ee27d4bc297caffef117f980844d208b416d380.jpeg "Bridging the Enterprise Edge to Kubernetes with F5 BIG-IP and NGINX Gateway Fabric") ](https://www.youtube.com/watch?v=P3aJzMh2Kzw)

## **2. Securing AI Inference Traffic: Native Gateway-Level AI Guardrails**

![Figure 2: Secure AI traffic natively in NGINX Gateway Fabric](https://d20hrnpixdzcsd.cloudfront.net/original/3X/2/2/229c17da3ad676de470db249afeb31c99ec16058.webp)

### **The Problem It Solves**

Deploying Large Language Models (LLMs) and generative AI applications inside Kubernetes introduces a host of operational risks:

- Accidental data leakage (PII, SSNs, internal IP addresses).

- Malicious prompt injections and jailbreak attempts.

- Compliance exposures (EU AI Act, HIPAA, GDPR).

Until now, securing these endpoints often meant either writing custom sanitization code directly inside client applications or injecting heavyweight sidecars next to every single LLM pod. That approach creates latency, fragments policy enforcement, and leaves SecOps blind to what’s happening across different clusters.

### **Gateway API Payload Processing with F5 AI Guardrails**

In F5 NGINX Gateway Fabric release 2.7, we aligned with the Gateway API Inference Extension working group to introduce a payload processing CRD for AI traffic. Instead of bolting on sidecars, NGINX Gateway Fabric uses the PayloadProcessor Custom Resource (CR). This allows NGF to act as a centralized, high-performance inference gateway.

### Key Highlights from the Setup:

1. **Bidirectional Inspection:** AI Guardrails inspect client prompts before they ever reach the model and inspect model outputs _before_ they return to the user. If either violates policy, the gateway blocks traffic immediately.

2. **Zero Code Changes & Zero Sidecars:** The frontend application simply communicates with standard OpenAI-compatible endpoints (like `/v1/chat/completions`). The gateway transparently handles inspection offloading.

3. **Auditing & Telemetry:** When we attempt to send or leak sensitive data (such as internal IP addresses or Social Security numbers), the transaction is blocked instantaneously. This generates granular audit logs in the F5 AI Guardrails dashboard with session IDs, timestamps, and the exact policy violated.

🎥 **Watch the Step-by-Step Walkthrough:** To see this configuration tested live against an Ollama pod running `Llama 3.2`, check out this video to learn more!!

**F5 NGINX Gateway Fabric: Securing AI Traffic with F5 AI Guardrail**

[![](https://d20hrnpixdzcsd.cloudfront.net/original/3X/f/5/f57182a5388e8c54a920728cad2d3a455084bb44.jpeg "F5 NGINX Gateway Fabric: Securing AI Traffic with F5 AI Guardrail") ](https://www.youtube.com/watch?v=21ccsrbYuo4)

## Conclusion: The Path Forward for Modern Kubernetes Architectures

The transition to the Kubernetes Gateway API isn’t just about adopting a new API spec—it’s about building a sustainable operational model that respects the distinct responsibilities of your NetOps, Platform, and SecOps teams.

By leveraging **GatewayLink** , you get to keep the enterprise-grade edge protections of your F5 BIG-IP fleet without forcing it to track highly volatile Kubernetes pod IPs. Simultaneously, implementing gateway-level **F5 AI Guardrails** via the standard Gateway API `PayloadProcessor` CRD ensures that your generative AI applications are compliant, secure, and shielded from prompt injections without introducing sidecar lag or forcing developers to rewrite application code.

## **Getting Started**

If you want to test these flows yourself, here are the direct links and resources:

- 📖 Read the 2.7 Announcement: [F5 NGINX Gateway Fabric 2.7 Article](https://www.google.com/url?q=https%3A%2F%2Fcommunity.f5.com%2Fkb%2Ftechnicalarticles%2Ff5-nginx-gateway-fabric-2-7---securing-ai-workloads-and-extending-big-ip-into-ku%2F347470 "https://community.f5.com/kb/technicalarticles/f5-nginx-gateway-fabric-2-7---securing-ai-workloads-and-extending-big-ip-into-ku/347470")
- 🛠 Official Documentation: [NGINX Gateway Fabric Docs](https://www.google.com/url?q=https%3A%2F%2Fdocs.nginx.com%2Fnginx-gateway-fabric%2F "https://docs.nginx.com/nginx-gateway-fabric/")
- 🛡 AI Security Documentation: [F5 AI Guardrails Overview](https://www.google.com/url?q=https%3A%2F%2Fdocs.aisecurity.f5.com%2F "https://docs.aisecurity.f5.com/")
- 💻 GitHub Project: [nginx/nginx-gateway-fabric](https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fnginx%2Fnginx-gateway-fabric "https://github.com/nginx/nginx-gateway-fabric")

---

<div class="post-metadata">

**Author:** ![KaiThor](https://avatars.discourse-cdn.com/v4/letter/k/b77776/32.png) [@KaiThor](https://community.f5.com/u/KaiThor)\
**Post date:** [October 7, 2026, 8:14pm UTC](https://community.f5.com/t/beyond-ingress-how-we-re-securing-ai-traffic-and-bridging-big-ip-with-nginx-gateway-fabric/77467/4 "2026-10-07T20:14:38Z")

</div>

The 2.7 release is very promising with both waf, plm, the new oidc and external loadbalancer with CIS . I hope you will keep focus on the issues reported in the nginx gwfab repo.

Great Work

---

<div class="post-metadata">

**Author:** ![Akash\_Ananthanarayan](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/akash_ananthanarayan/32/13333_2.png) [@Akash\_Ananthanarayan](https://community.f5.com/u/Akash_Ananthanarayan)\
**Post date:** [October 7, 2026, 8:50pm UTC](https://community.f5.com/t/beyond-ingress-how-we-re-securing-ai-traffic-and-bridging-big-ip-with-nginx-gateway-fabric/77467/5 "2026-10-07T20:50:41Z")

</div>

Thank you, @KaiThor for reviewing the article. We’ll focus on the issues reported in the GitHub repo. If you’d like to see any NGF articles you’re interested in, please let us know.
