Inspiration

AI can now generate infrastructure code that runs extremely close to the Linux kernel.

That is powerful, but it creates a different trust problem than ordinary application development.

eBPF lets developers run high-performance programs in the Linux kernel for things like firewalls, packet filtering, observability, rate limiting, and DDoS mitigation. But a networking program can compile successfully while still blocking legitimate users, exposing a service, or simply implementing a different policy than the one the developer intended.

This is not a hypothetical direction. Major infrastructure companies are already moving toward programmable networking. Meta has deployed XDP/eBPF in Katran, its production load balancer. Google uses eBPF and Cilium in GKE Dataplane V2. More recently, Cloudflare introduced Programmable Flow Protection, allowing customers to run custom stateful mitigation logic across its network.

These systems are not KernelGate, but they point to the same broader shift: more networking policy is becoming programmable. As that happens, the question becomes increasingly important: how do we verify that new networking logic is both safe to run and actually implements the policy we intended?

The Linux BPF verifier solves part of this problem by checking whether an eBPF program satisfies the kernel's safety constraints.

But verifier-safe does not mean policy-correct.

That led to the question behind KernelGate:

If AI is going to write privileged infrastructure code, who verifies the AI?

KernelGate is our answer.

KernelGate is a CI/CD verification layer for eBPF. OpenAI, another coding agent, or a human developer can propose an implementation. KernelGate sits downstream of the author and independently decides whether that implementation should be trusted.

The idea is similar to why teams still use CI even though a developer or an AI agent could manually run a compiler and test suite.

The value of CI is not that nobody else can execute those commands.

The value is that every change is forced through a defined, repeatable gate before it can ship.

A general coding agent can perform the workflow. KernelGate standardizes and enforces the workflow.

AI proposes. KernelGate decides.

What it does

KernelGate takes a natural-language networking policy and turns it into an eBPF implementation that must survive several independent verification stages before deployment is allowed.

A request such as:

Block inbound TCP traffic to destination port 22. Allow all other traffic.

first becomes a typed Policy IR.

That structured policy is important because the generated program never gets to define what "correct" means. The specification exists before code generation and becomes the contract against which the candidate is evaluated.

From there, KernelGate:

uses the OpenAI API to propose an XDP/eBPF implementation;
compiles the candidate using Clang/LLVM;
submits it to the real Linux BPF verifier;
attaches the verified candidate to an isolated virtual Ethernet environment;
sends real network traffic through it;
reads counters written by the eBPF program inside the kernel;
compares observed behavior against expectations derived from the Policy IR; and
approves or refuses deployment.

KernelGate currently supports two different policy families:

Stateful UDP rate limiting, grouped by source IP.
Stateless TCP destination-port blocking.

For the TCP policy, KernelGate checks that blocked TCP traffic is dropped, allowed TCP traffic still passes, UDP using the same numeric port is unaffected, and unrelated ICMP traffic still works.

For the UDP rate limiter, the harness derives below-limit, above-limit, and per-source scenarios from the requested rate.

This was important to us because we did not want to build a single hardcoded eBPF demo. Different policies produce different programs and different behavioral contracts, while moving through the same verification architecture.

KernelGate is deliberately fail-closed.

If compilation fails, the Linux kernel rejects the program, or the observed packet behavior disagrees with the policy, deployment is refused.

When a generated candidate fails, KernelGate can feed the real compiler or verifier diagnostic back into the OpenAI API and request a repaired candidate.

The repaired program gets no special trust.

It must go through the same pipeline again.

The model can repair its proposal. It cannot bypass the gate.

How we built it

KernelGate is intentionally built as several independent systems instead of one large AI workflow.

Policy layer

Natural-language intent is converted into a schema-validated Policy IR.

The IR is kept separate from the generated source code so that KernelGate can reason about expected behavior without trusting the implementation being tested.

OpenAI proposal and repair engine

The validated policy is sent to the OpenAI API, which generates an XDP/eBPF candidate.

OpenAI acts as the author, not the verifier.

That distinction is fundamental to KernelGate.

The model is allowed to propose implementations and use real diagnostics to repair failed candidates, but the final decision comes from independent systems with concrete evidence.

Real compilation

Candidates are compiled into BPF bytecode using Clang/LLVM.

Compiler output is preserved as evidence rather than hidden behind a simple pass/fail indicator.

Real Linux kernel verification

Compiled candidates are sent through the actual Linux BPF verification path.

This is not an LLM judging another LLM and it is not a simulated verification step.

The real operating system decides whether the candidate satisfies the kernel's safety constraints.

Real behavioral validation

Kernel safety still does not tell us whether a firewall or rate limiter actually implements the requested policy.

KernelGate therefore creates an isolated Linux networking environment using network namespaces and a virtual Ethernet pair.

The candidate is attached to that environment and real packets are sent through it.

The eBPF program updates BPF maps inside the kernel with values such as:

seen
passed
dropped

KernelGate then reads those kernel-resident counters and compares the observed behavior with the Policy IR.

Real traffic. Real kernel counters. Not simulated.

Hard deployment gate

The final decision combines all of these independent checks.

A candidate is not deployable just because OpenAI generated it.

It is not deployable just because it compiled.

It is not even deployable just because the Linux kernel accepted it.

It must also behave according to the original policy.

Our core design principle is:

Kernel-verified for safety, behaviorally validated against policy.

How we used OpenAI while building it

OpenAI was also part of our development workflow.

We used OpenAI tooling, including ChatGPT and Codex during development, to reason through architecture, inspect implementation plans, debug low-level eBPF/compiler/verifier problems, review test results, and iterate quickly across the backend and developer interface.

The interesting part was the symmetry:

we were using AI tooling to accelerate development of a system whose entire purpose is ensuring that AI-generated systems code does not receive automatic trust.

OpenAI accelerated development. KernelGate enforced trust.

Challenges we ran into

eBPF generation is much harder than ordinary code generation

Generated eBPF can look completely reasonable and still fail compilation or be rejected by the Linux verifier.

We saw this happen during development.

In one end-to-end TCP policy run, Candidate v1 failed compilation. KernelGate captured the real diagnostic, OpenAI proposed Candidate v2, and the new candidate then passed compilation, passed the Linux verifier, passed the behavioral contract, and reached deployment approval.

Instead of hiding these failures, we designed KernelGate around them.

Kernel-safe and policy-correct are different problems

This became one of the most important lessons of the project.

The Linux verifier can determine whether the kernel will accept a candidate under its safety model.

It cannot tell us whether:

"block TCP port 22" accidentally became "block all TCP";
a rate limiter properly isolates individual sources; or
unrelated traffic still works.

That is why KernelGate has both a kernel-safety gate and a separate behavioral gate.

Testing real networking code safely

We wanted real packet behavior, not mocked function outputs, but we also could not allow generated networking code to interfere with the host machine.

Network namespaces and a veth pair gave us a controlled environment where we could attach the XDP candidate, generate traffic, observe kernel behavior, and tear everything down afterward.

Building a gate that is willing to say no

A verification system has little value if every demo ends green.

Compiler failure, verifier rejection, candidate revisions, behavioral failures, and final deployment refusal are all first-class states in KernelGate.

A system protecting deployment has to be willing to refuse deployment.

Accomplishments that we're proud of

The biggest accomplishment is that the verification pipeline is real end to end.

KernelGate:

generates real eBPF through the OpenAI API;
compiles it using Clang/LLVM;
sends it through the actual Linux BPF verifier;
loads it into an isolated virtual network;
sends real packets through the candidate;
reads kernel-resident BPF counters;
derives behavioral expectations independently from the Policy IR;
repairs failed generated candidates using real diagnostics; and
refuses deployment when a required gate fails.

We are also proud that KernelGate already works across two meaningfully different networking policies instead of one canned example.

The TCP port-block policy is stateless access control.

The UDP policy is a stateful per-source rate limiter.

Both use the same verification architecture while producing different generated programs and different tests.

That was our strongest indication that KernelGate was becoming a framework rather than a hackathon script.

What we learned

The biggest lesson was that good generation and trustworthy generation are different problems.

Language models are powerful code authors, but probabilistic generation and privileged infrastructure have very different trust models.

Our solution was not to ask the model to judge itself more aggressively.

Instead, we surrounded the model with systems that have their own sources of evidence.

The model proposes code.

The compiler provides evidence.

The Linux kernel provides evidence.

Observed packet behavior provides evidence.

The Policy IR remains the contract tying those checks together.

That changed how we think about AI developer tooling more generally.

The LLM is replaceable. The verification architecture is the product.

What's next for KernelGate

The next step is moving KernelGate directly into pull-request and deployment workflows.

The model we envision is:

PR + changed eBPF + policy contract -> KernelGate -> merge/deployment decision

A developer, coding agent, or automated system could submit eBPF code.

KernelGate would automatically:

compile it;
run it through the Linux verifier;
execute its behavioral contract;
attempt evidence-driven repair when allowed; and
block the merge or deployment when verification fails.

In other words, KernelGate would become the CI gate teams do not have to remember to run manually.

From there, we want to expand beyond XDP into additional eBPF hooks and security policy families, introduce stronger property-based and adversarial behavioral testing, and explore formal verification for selected invariants where mathematical proof can provide assurance beyond empirical testing.

The long-term goal is not to build another AI coding assistant.

It is to build the trust boundary that lets AI-generated systems code become something engineers can actually deploy.