Network boundary for AI agents using NGINX and OpenTelemetry

I recently had an interesting conversation at a KCD about OpenClaw with one of the attendees, and they remarked that they wouldn’t put an agent in their network, because “we don’t know what that thing really does”. That got me thinking; agentic autonomy has huge potential to automate tasks previously needing humans, but at the same time, that capability introduces new operational and security challenges. This inspired me to start a passion project to create a network boundary for AI agents. You might be thinking, that’s why we have guardrails! While it’s important to understand agentic intent to influence generation, it’s also necessary to control network access for agentic tools. Enforcing network traffic security is fundamental, and there are already many solutions available for that purpose. How about if we built a network boundary that was both enforced and observable at the same time, without needing to introduce entirely new infrastructure? The answer turned out to be surprisingly simple. Use two mature open source components that are already common in cloud native environments: NGINX as the traffic control plane and OpenTelemetry as the audit plane. They allow us to gain observability and create an efficient boundary where we can implement fine-grained, application-aware traffic shaping rules. Image: Request flow diagram Because NGINX sits on both sides of the flow, it performs the reverse proxy role for inbound traffic, terminates TLS, and forwards requests for the agent. For outbound traffic, the same instance acts as a forward proxy through which every agent request must pass. We can control the flow with iptables rules that drop all other egress traffic, so there is no second path. That makes the boundary a property of the architecture, not a policy we hope the application respects. The NGINX native OpenTelemetry module allows us to emit an OTEL span for every request. Now we are getting traffic flow observability using a format that our tooling already understands, allowing us to correlate user interactions with the external calls made by the agent on their behalf. An OpenTelemetry Collector can persist those spans to an audit log, or we can feed them into observability and security tooling such as Jaeger, Grafana, or a SIEM platform. Validating the Idea To validate the design, I deployed a single-node Kubernetes cluster running four workloads: NGINX, Ollama, OpenClaw, and an OpenTelemetry Collector in the same namespace. Image: Containers in the openclaw namespace Our instance was equipped with a consumer NVIDIA GPU, but the design can be mirrored on a wide range of platforms, from edge devices to enterprise-grade AI infrastructure. As long as it can run Kubernetes workloads, the pattern remains applicable. Image: GPU usage during inference The OTEL spans we collected gave us enough information to start taking control and building rules to establish more granular control over the source content that the OpenClaw instance can access. Image: OTEL spans collected and their statuses Why This Matters Now The cloud native ecosystem has mature tools for authentication, admission control, runtime threat detection, observability, and more. What is still evolving are reusable patterns for bounding and auditing the outbound network behavior of autonomous AI workloads. Image: NGINX config map blocking all but nginx.org and duckduckgo.com Using NGINX and OpenTelemetry, we built an AI agent boundary based on open standards and deployable on Kubernetes using familiar operational tooling. While this implementation uses NGINX as the enforcement point, similar patterns could also be implemented using other proxy technologies, service mesh egress gateways, or network policy solutions. Limitations and Future Work This approach focuses on controlling and observing network behavior, not understanding agent intent. Restricting where an agent can communicate does not guarantee that its decisions are correct or safe. Additionally, proxy-based enforcement introduces another operational component that must be secured and monitored. Like any network control, it should be viewed as one layer in a broader defense-in-depth strategy alongside identity, policy, runtime security, and application-level guardrails. Future work will focus on exploring how network-level controls can complement higher-level governance mechanisms for autonomous systems. If you would like to try this deployment out yourself, take a look at the OpenClaw Network Boundary repository where you can find the code to deploy to Kubernetes. NGINX, NGINX Ingress Controller and NGINX Gateway Fabric Now you might be wondering how do the NGINX capabilities presented in this article relate to your deployment? You might be running NGINX Ingress Controller (NIC) or have already taken the big Kubernetes Gateway API leap and are running NGINX Gateway Fabric (NGF). NIC and NGF will inherit features released in the core NGINX proxy over time, and forward proxy is one of those features. The NGINX Ingress Controller and NGINX Gateway Fabric development teams are actively tracking these updates and closing the gaps on a daily basis. AI landscape is full of possibilities. If you’re interested in exploring this world with us, we would love to see you join the NGINX community. NIC and NGF also have regular community calls where you can connect with maintainers, ask questions, and pitch your ideas. Join the NIC Community call here and NGF Community call for AMER and EMEA time zones.