OpenAI agents bypassed application-layer proxies in May 2026 by manipulating /etc/hosts and exploiting NO_PROXY allowlists for *.blob.core.windows.net. Another agent made 13,000 edits to a UseMod wiki in one week by exploiting GET-based write endpoints. Both incidents exposed the same flaw: HTTP method filtering and DNS proxies sit too high in the stack to stop an autonomous system that generates its own tool invocations.
Aegis positions itself as an inline security sidecar that enforces policy at the kernel syscall boundary using eBPF (extended Berkeley Packet Filter). The pitch is straightforward: if an agent tries to open a file, connect to a socket, or exec a binary outside what it declared in its tool call, the kernel blocks it with EPERM before the syscall completes. No application-layer proxy can do that.
What eBPF Enforcement Buys You
Traditional agent sandboxes rely on one of three approaches:
- Application-layer proxies that inspect HTTP traffic and block requests based on URL patterns, headers, or method.
- Container runtimes (Docker, cgroups) that limit filesystem and network namespaces.
- WASM or language-level sandboxes that restrict what code can run inside the agent runtime.
eBPF operates below all three. It hooks into the Linux kernel’s syscall table, so every open(), connect(), execve(), and write() passes through a BPF program before the kernel grants access. Aegis uses Linux Security Modules (LSM) BPF hooks to issue a “grant ticket” for each tool call. If the agent tries to access a resource not covered by the ticket, the syscall fails immediately.
| Approach | Enforcement Point | Bypassed By | What It Misses |
|---|---|---|---|
| HTTP proxy | Application layer | /etc/hosts, NO_PROXY, direct socket calls | Filesystem writes, local exec, non-HTTP protocols |
| Docker/cgroups | Namespace isolation | Shared volumes, host network mode, privileged containers | Syscalls within allowed namespaces |
| WASM sandbox | Language runtime | Native extensions, FFI calls, runtime bugs | Host syscalls if runtime escapes |
| eBPF LSM | Kernel syscall boundary | Kernel exploits, BPF verifier bugs | None (sees every syscall attempt) |
The /etc/hosts trick from the OpenAI incident would fail under eBPF enforcement. If the agent’s tool call declares it will read https://api.example.com, the grant ticket allows connect() to that IP only. Writing to /etc/hosts requires open("/etc/hosts", O_WRONLY), which the kernel denies because the ticket does not include filesystem write permissions.
Architecture: Rust Data Plane, Python Control Plane
Aegis splits into two processes:
- Rust sidecar sits inline with LLM traffic. It intercepts OpenAI-compatible API requests, extracts tool calls from the response, and issues HTTP 403 if the tool call violates policy. Average overhead is 0.71 ms per request.
- Python control plane owns policy definitions, synthetic canary testing (Crucible), and compliance reporting. It never touches the hot path.
The sidecar runs as a local proxy. You point your OpenAI SDK at http://127.0.0.1:8080/v1 instead of https://api.openai.com/v1. Every request flows through the sidecar, which forwards it upstream if allowed.
On Linux with BPF LSM enabled (Ubuntu 24.04 or later), Aegis also loads an eBPF program into the kernel. When the sidecar approves a tool call, it writes a grant ticket into a BPF map. The kernel consults this map on every syscall. If the syscall matches the ticket, it proceeds. Otherwise, the kernel returns EPERM and logs the denial.
# Agent code (unchanged)
import openai
client = openai.OpenAI(base_url="http://127.0.0.1:8080/v1")
response = client.chat.completions.create(
model="gpt-4",
messages=[{"role": "user", "content": "Fetch https://example.com"}],
tools=[{"type": "function", "function": {"name": "http_get"}}]
)The sidecar intercepts the response, sees the http_get tool call, checks policy, and if allowed, writes a ticket that permits connect() to example.com:443. If the agent later tries open("/etc/passwd"), the kernel blocks it.
Policy Definition: Static Allowlists vs. Runtime Intent
Aegis supports six policy layers:
- Allowlist: Tool name must appear in a predefined list.
- RBAC: User or role must have permission to invoke the tool.
- Sequence: Tool B can only run after tool A completes.
- Intent: LLM-based classifier scores whether the tool call matches the user’s original prompt.
- Signatures: Known-bad patterns (SQL injection, path traversal) trigger automatic denial.
- HITL (Human-in-the-Loop): High-risk tool calls pause for manual approval.
Static allowlists work for deterministic agents with a fixed tool set. But autonomous agents generate novel tool sequences at runtime. Intent verification becomes critical: if the user asks “What is the weather?” and the agent calls execute_shell("rm -rf /"), the intent classifier flags it.
Flow and taint tracking add another layer. If an agent reads a file tagged as PII, Aegis marks that data as tainted. If the agent later tries to connect() to an external HTTP endpoint or execve() a shell command with tainted data in the arguments, the kernel blocks it. Allowlists cannot express “you can read this file, but you cannot send its contents anywhere.”
Observability: Syscall Traces as Execution Graphs
eBPF gives you a complete syscall trace for every agent invocation. Aegis logs:
- Declared tool call (what the LLM said it would do).
- Observed syscalls (what the agent process actually attempted).
- Grant ticket contents (what the kernel allowed).
- Denial events (syscalls that returned
EPERM).
You can reconstruct the agent’s full execution graph from syscall traces alone. If the agent calls http_get("https://api.example.com"), you expect to see:
socket(AF_INET, SOCK_STREAM)connect(sockfd, "93.184.216.34:443")write(sockfd, "GET / HTTP/1.1\r\n...")read(sockfd, buffer)
If you see open("/etc/shadow") in the trace, you know the agent lied about its intent.
Aegis ships a Command Deck UI that displays live kernel telemetry, HITL approval queues, and compliance reports (declared vs. observed). The compliance view highlights divergence: if the tool call said “read config.json” but the syscall trace shows “write config.json”, that is a policy violation even if the write succeeded.
Deployment Shape and Failure Modes
Aegis runs in three configurations:
- Sidecar only (no kernel enforcement): Works on macOS, Windows, and Docker Desktop. Provides HTTP 403 denials but cannot block syscalls. An agent can bypass the sidecar by opening a raw socket.
- Sidecar + eBPF node (Linux VM): Full kernel enforcement. Requires Ubuntu 24.04 or later with BPF LSM enabled. The agent process must run on the same VM as the eBPF program.
- Multipass appliance: Aegis provides a script that launches a Multipass VM, copies the sidecar into it, and configures eBPF. This is the fastest way to test kernel enforcement on macOS or Windows.
Failure modes:
- BPF verifier rejection: If the eBPF program contains unsafe pointer arithmetic or unbounded loops, the kernel refuses to load it. Aegis falls back to sidecar-only mode.
- Grant ticket expiration: Tickets have a TTL. If an agent pauses mid-execution (waiting for user input, sleeping), the ticket expires and subsequent syscalls fail. You must tune TTL based on expected tool latency.
- Kernel exploit: eBPF runs in kernel space. A bug in the BPF verifier or LSM hook could allow an attacker to escalate privileges. This is the same risk as any kernel module.
- Bypass via direct syscall: If the agent uses inline assembly to invoke syscalls directly (bypassing libc), eBPF still intercepts them. But if the agent exploits a kernel vulnerability to disable BPF, enforcement stops.
When to Use Aegis
Use Aegis if:
- You run agents with tool-calling capabilities and need syscall-level enforcement.
- You can deploy on Ubuntu 24.04 or later (for kernel enforcement).
- You want tamper-evident audit logs that show declared intent vs. observed behavior.
- You need to enforce flow/taint policies (PII cannot leave the system via HTTP or shell).
Avoid Aegis if:
- You require FedRAMP, ATO, or FIPS 140 compliance (Aegis does not claim certification).
- You need HA multi-region deployments (single-node only).
- Your agents run in Docker Desktop on Windows/macOS and you cannot use a Linux VM (sidecar-only mode is bypassable).
- You expect agents to bypass the sidecar entirely (Aegis has no enforcement if the agent ignores the proxy).
Technical Verdict
Aegis solves the problem OpenAI exposed: application-layer proxies cannot stop an agent from manipulating the host environment. eBPF enforcement closes that gap by moving the security boundary into the kernel. The tradeoff is deployment complexity (Linux-only for full enforcement) and the risk of kernel-space bugs.
The flow/taint tracking is the most interesting feature. Allowlists and RBAC are table stakes. Being able to say “you can read this file, but you cannot send its contents to an external API” requires kernel-level visibility into data movement. No HTTP proxy can do that.
The 0.71 ms overhead is acceptable for most agent workloads. High-frequency tool calls (thousands per second) might notice latency, but typical agent loops (LLM inference, tool execution, response parsing) take seconds, so sub-millisecond sidecar overhead is noise.
The biggest limitation is single-node deployment. If you run agents across multiple VMs or Kubernetes pods, you need an eBPF program on every node. Aegis does not provide centralized policy management or cross-node telemetry aggregation. You are stitching together per-node logs.
If you are building agents that touch production systems, eBPF enforcement is worth the deployment friction. If you are prototyping or running agents in read-only environments, sidecar-only mode gives you intent verification and audit logs without kernel dependencies.