Dan Finneran used a QCon London 2026 presentation to argue that AI-generated code is entering production faster than teams can understand, own, or secure it. His answer was an eBPF-based gateway for Kubernetes that can transparently intercept AI API traffic, rewrite prompts and models, enforce token limits, and block risky behavior without changing application source code.
Why AI code and agents are becoming a production risk
Finneran’s talk focused on a problem many teams now recognize: code created with AI assistance often arrives without clear ownership. He said open-source maintainers are already seeing AI-generated pull requests, but that when they ask contributors to explain how the code works or how it will be supported, they are often met with silence.
That gap becomes more serious once code lands in production. A quick “vibe coded” feature can quickly become business-critical, even if nobody fully understands its dependencies, its failure modes, or who is responsible for maintaining it later.
The risk extends beyond code quality. Finneran also pointed to AI agents that have been given more control over calendars, file systems, and laptops, sometimes with destructive results. He cited cases where agents have run commands such as terraform destroy, deleted folders, or removed source code while thinking they were helping.
How eBPF fits into the Kubernetes picture
The presentation positioned eBPF as the enforcement layer that makes this kind of control possible. eBPF, which is part of the Linux kernel, lets teams attach programmable logic to running systems and intervene in areas such as networking, files, and syscalls.
Finneran described eBPF as a practical alternative to kernel modules, which are tied to specific kernels and harder to distribute broadly. He also noted that modern Linux systems, Android devices, and Kubernetes networking stacks already use eBPF in production, often without the user needing to know it is there.
In the Kubernetes context, he said the technology is especially useful because it can observe and manipulate traffic at runtime. Instead of rebuilding applications or restarting containers, teams can attach logic to kernel events and change behavior on the fly.
Building an AI API gateway with eBPF
At the center of the talk was a proof of concept for an AI gateway designed to sit between an application and an LLM endpoint. The goal is to intercept traffic transparently, inspect requests and responses, and then modify or block them according to policy.
Finneran said the gateway can:
- redirect AI traffic to a user-space proxy without changing the application
- observe prompts, models, and responses in transit
- swap models dynamically
- rewrite prompts
- cap token usage
- block requests or responses that violate policy
Rather than attaching at the network card or dealing with raw frames, the demo hooks into sockets. That gives the gateway visibility into the application’s network streams while keeping the process unaware that traffic has been redirected.
What the demo showed
Finneran demonstrated a Kubernetes workload that repeatedly asked an LLM to tell a joke about Go. Initially, the application used a hard-coded model and produced its own responses. A watcher in the cluster then detected an AI="true" annotation and added an ephemeral container to the pod, effectively inserting the gateway beside the running workload.
Another annotation, netflush, forced a new connection so the gateway could capture traffic immediately. From there, policy changes took effect without restarting the original application.
He then showed a config map that changed the model from Llama to Gemma 2 and altered the prompt behavior so the system returned facts instead of jokes. Later, he demonstrated filtering that blocked responses containing references to rabbits, with the gateway returning “Kube-gateway says no.”
What the gateway changes in practice
The broader point of the demo was not just interception, but control. By placing policy enforcement between the app and the LLM, teams can make runtime changes to behavior that would otherwise require application updates or code changes.
That matters because AI applications are often built with hard-coded models, weak prompt handling, and no clear limits on token usage. Finneran warned that poor prompt controls can create denial-of-service conditions or lead to unexpected cloud costs if a poisoned prompt produces excessive output.
He also described the gateway as a way to impose encryption, including mTLS, between services in a cluster where internal AI traffic might otherwise be unencrypted.
Security is not limited to prompts and models
Although most of the presentation centered on networking and API control, Finneran said eBPF can also help secure the rest of the runtime. Because it can attach to syscall events and file access paths, it can prevent risky actions such as opening /etc/passwd or running commands like rm when policy says not to.
That means eBPF can be used not only to shape AI behavior, but also to limit what AI agents can do once they start shelling out to other tools. Finneran argued that this kind of control is important because agents often expand their reach beyond the original prompt.
He framed the approach as a way to stay one step ahead: the eBPF hook runs before the kernel completes the action, so the system can deny the syscall before it causes harm.
A sign of where Kubernetes AI controls may be heading
Finneran connected the demo to work already underway in the Kubernetes ecosystem around AI gateways and governance. He said a new working group is standardizing how teams can observe, control, and change AI agents in Kubernetes clusters, and that his example was a proof of concept aligned with that direction.
The underlying theme was clear: as AI-generated code and autonomous agents spread, organizations need runtime controls that do not depend on perfect code ownership or manual intervention. eBPF, in his view, is one of the few tools that can provide that level of flexibility without forcing application redesigns.
For teams already running Kubernetes, the message was less about learning kernel programming and more about using the capabilities that eBPF makes available underneath the platforms they already depend on.
Source: Original report
Was this helpful?
Explore more: DevOps Services More Cloud & DevOps Tech News
Last Modified: August 22, 2026 at 1:53 am
4 views
