CargoWall: A High-Performance eBPF-Based Network Firewall for Container (and LLM) Security
?1761549113815)
Customizable Firewalls for your GenAI Agents
September 15, 2025
Introduction
When we at CodeCargo started building CargoWall, we weren’t trying to reinvent firewalls. We were trying to solve a very specific problem: how to keep containerized workloads — especially LLM-powered workloads — from talking to things they shouldn’t.
In today’s cloud-native environments, workloads are dynamic, network boundaries are fluid, and the speed of change outpaces traditional firewalls. LLMs add a new layer of risk: with internet access and tool call capabilities, they can be persuaded — intentionally or not — into actions developers never intended, like exfiltrating source code or calling unauthorized APIs. Security teams need fine-grained controls that operate at kernel speed, adapt to DNS churn, and integrate with distributed systems to enforce certainty in LLM behavior. Developers, meanwhile, need those controls to stay invisible until the moment they matter.
That’s where CargoWall comes in. It’s an eBPF-based L4 firewall purpose-built for containers. It delivers microsecond-level packet filtering and DNS-aware rules that make it possible to enforce isolation without adding noticeable overhead.
And if you’re running LLMs in production, that last part is critical.
Why LLM Isolation Matters
LLMs are powerful — and risky. By default, they’ll try to pull in data from the internet, call APIs you didn’t intend, or exfiltrate prompts and context through unexpected channels. Even if your model is running in a secure container, without network isolation it’s just one function call away from leaking sensitive data. And because we run a hybrid, distributed architecture for agentic jobs — where LLM calls execute directly in our customers’ environments — this layer of security isn’t optional; it’s paramount.
CargoWall makes LLM isolation practical:
- Restrict outbound access so the model can’t call arbitrary APIs.
- Allow-list only trusted services (package registries, vector DBs, or model hubs).
- Dynamically adapt to DNS changes so your rules stay valid when IPs rotate.
- Audit every network attempt, so you know exactly what the model tried to do.
This is how you can run LLM workloads safely in multi-tenant clusters — or in regulated environments where “default-allow” is simply not an option.
Architecture Overview
CargoWall is built around a simple but powerful architecture:
- eBPF Programs – Kernel-space filters attached at TC hooks.
- Control Plane (Go) – Manages rules, processes DNS events, and coordinates updates.
- State Machine Integration (NATS) – Dynamic rule distribution and event notifications.
- DNS Intelligence – Real-time mapping from hostnames to IPs.
The result: a firewall that understands both packets and application intent.
Technical Deep Dive
eBPF Filtering
CargoWall attaches eBPF classifiers at the ingress/egress TC layer:
SEC("classifier/egress")
int tc_egress(struct __sk_buff *skb)
// Parse headers
// Match against CIDR/port maps
// Drop or allow in microseconds
}Rules are stored in:
- LPM Trie (map_cidrs) – For CIDR-based network rules.
- Hash Map (map_ports) – For granular port-specific restrictions.
The decision path:
- Allow only TCP/UDP.
- Match against CIDR rules.
- Validate port rules.
- Allow or drop immediately.
DNS-Aware Filtering
Unlike IP-only firewalls, CargoWall keeps up with DNS changes. It captures DNS responses at the kernel level and updates hostname-to-IP mappings in real time:
- Parse DNS responses via ring buffer.
- Update allow/deny rules dynamically.
- Re-resolve hostnames on TTL expiration.
This is why you can safely write rules like:
allow:
- host: api.openai.com
- host: my-internal-api.company.comand know they’ll keep working, even when the IPs change.
Performance
Operating entirely in kernel space gives CargoWall:
- Sub-microsecond decision latency.
- Zero-copy packet inspection.
- Scalable eBPF maps with lock-free lookups.
- Hardware offload support where available.
In practice, that means you can enforce LLM isolation policies transparently without sacrificing performance.
Configuration
From the administrator’s perspective, CargoWall isn’t just a kernel-level feature hidden away in the stack — it’s fully exposed and configurable through the CodeCargo UI. Teams can define allow/deny rules by hostname, CIDR range, or port with just a few clicks, without needing to touch low-level networking primitives. Policies can be applied across the entire platform and changes propagate instantly. This gives operators confidence that their guardrails are not only technically enforced at the kernel level, but also easy to manage at scale.
Conclusion
CargoWall isn’t a general-purpose firewall bolted onto containers — it’s a purpose-built, eBPF-powered security layer embedded directly into the CodeCargo platform. Its role is to keep modern workloads — and especially LLMs — inside the lines you draw for them, without slowing developers down.
In CodeCargo, CargoWall acts as the enforcement layer for zero-trust networking. It ensures that agentic jobs running in customer environments can only reach the services they’re supposed to, with kernel-speed filtering and DNS-aware intelligence backing every decision.
For LLM-powered workflows, that difference isn’t academic. It’s the line between confidently deploying AI in production and quietly leaking sensitive data to the internet. With CargoWall built into CodeCargo, we’ve made that security capability foundational.
C
CodeCargo Team
The CodeCargo team writes about GitHub workflow automation, developer productivity, and DevOps best practices.
