**Building a Network Boundary for AI Agents Using NGINX and OpenTelemetry**
The rapid adoption of AI agents in cloud-native environments has raised important questions around security, observability, and control. While the community has made strides in securing the network perimeter, the unique challenges posed by autonomous agent workloads—particularly around outbound traffic and behavior auditing—demand new approaches. In a recent discussion at KubeCon, a thought leader highlighted these concerns and presented a practical, open-source-based solution to enforce and observe AI agent network activity without introducing heavy new infrastructure.
**The Challenge: Trust, But Verify**
Many teams are hesitant to deploy AI agents that operate autonomously within their networks, especially when those agents make external calls—sometimes to unexpected or unintended destinations. While guardrails and intent-based policies help guide agent behavior, they don’t replace the need for enforceable network controls. Without visibility and control over outbound traffic, organizations risk data leakage, compliance violations, or unintended interactions with external services.
**A Simpler Approach: Two Proven Tools**
Instead of deploying a new security layer or sidecar proxy, the proposed architecture leverages two widely adopted CNCF-native components:
– **NGINX** as the enforcement and reverse proxy point
– **OpenTelemetry (OTEL)** as the audit and observability plane
This combination allows teams to implement a tightly controlled, observable network boundary that’s application-aware and built on open standards.
**How It Works**
In this design, NGINX operates in dual roles:
– **Inbound:** It acts as a reverse proxy, terminating TLS and routing requests to the AI agent (in this case, OpenClaw).
– **Outbound:** It functions as a forward proxy, ensuring that all agent-initiated egress traffic passes through it.
To eliminate alternate egress paths, iptables rules are applied to drop any traffic that doesn’t go through the proxy. Meanwhile, the NGINX OpenTelemetry module generates a span for every request, capturing detailed metadata about each interaction. These spans are then sent to an OpenTelemetry Collector, where they can be persisted as audit logs or integrated with observability and security platforms such as Grafana, Jaeger, or SIEM tools.
**Validation in a Real-World Scenario**
To validate the concept, a single-node Kubernetes cluster was deployed with the following workloads:
– NGINX
– Ollama (for LLM execution)
– OpenClaw (the AI agent)
– OpenTelemetry Collector
The deployment was tested on a system with an NVIDIA GPU, but the pattern is portable and can scale from edge devices to enterprise AI infrastructures.
By analyzing the collected OTEL spans, the team could reconstruct agent behavior and begin defining fine-grained rules—such as limiting access to specific domains or external services. This insight enables organizations to move from reactive monitoring to proactive traffic shaping.
**Why Now?**
While CNCF tools already provide strong support for authentication, runtime security, and observability, patterns for bounding autonomous workloads are still emerging. This architecture fills that gap by combining enforcement with rich telemetry using technologies that are already familiar to cloud-native practitioners.
**Limitations and Future Directions**
It’s important to note that network-level enforcement doesn’t equate to understanding agent intent. This solution restricts *where* an agent can go, not whether its decisions are safe or correct. Additionally, operating a proxy layer adds another component that must be secured and monitored as part of a broader defense-in-depth strategy.
Future work will explore how network controls can complement higher-level governance frameworks, including policy engines and application-level guardrails.
**Get Involved**
If you’re interested in experimenting with this setup, the OpenClaw Network Boundary repository provides the necessary code to deploy the architecture on Kubernetes. The article also highlights ongoing collaboration opportunities within the NGINX community—particularly through the NGINX Ingress Controller (NIC) and NGINX Gateway Fabric (NGF)—which continue to evolve to support modern AI workloads.
—
**Original Article Source:**
Marko Sluga, F5. (2026, July 8). *CNCF projects highlighted in this post*. CNCF. https://www.cncf.io/wp-content/uploads/2026/06/image-11.png
