Kernel holds ai agent network requests until safe verdict arrives
Connection Escrow: Holding AI-Agent Pod Egress in the Kernel Until an Isolated Verifier Rules
Cryptography and SecurityNetworking and Internet ArchitectureOperating Systems
Summary
AI agents running in containers open network connections that could be risky or controlled by harmful instructions. The authors developed a method where the operating system’s kernel temporarily pauses these network connections until a separate trusted program inspects and approves them. This ensures that only safe connections are allowed, even if the AI agent tries to bypass controls. Their approach works without changing the AI agents themselves and adds minimal delay.
What this means in practice
- •For cloud infrastructure engineers: Control and verify every outbound connection from containerized AI agents by holding connections in the kernel until a separate verifier approves them.
- •For security operations teams: Prevent malicious or unauthorized network activities from AI agent pods by integrating kernel-level connection escrow with identity-based policies on Kubernetes clusters.
Authors
Ashok Subbabhatta Gopalakrishna
Abstract
AI agents in containers act by opening network connections, and the text that drives them can be hostile. Controls placed between the agent and its tools are bypassed by a child process or a direct socket, and their approval is not tied to the connection the kernel later opens. We present connection escrow: every outbound TCP connection from a supervised pod is parked inside the kernel's connect() path, before any packet exists, by a 98-instruction eBPF program on the pod's cgroup. A node interceptor attributes the held socket to its kernel socket cookie, process, executable digest, cgroup and pod identity, parks the first bytes the agent writes, and asks a verifier in a separate container with its own key. The connection is released only on a signed verdict naming that one socket cookie and destination, unexpired and unused; no verdict by the deadline resets it, and a late approval is refused. The agent is unmodified. A 36-check adversarial suite with real cgroups passes on the eBPF hold point (33 of the checks also apply, and pass, on an iptables hold point): refused connections never reach the destination; forged, rebound, replayed, expired and late verdicts are refused; the agent's attempt to reach the verifier is itself escrowed; child-process and renamed-binary bypasses fail; UDP is pinned to the resolver. On a Kubernetes cluster, unmodified pods are held per connection and attributed to their SPIFFE identity, a raw socket that bypasses a sidecar proxy is held, and 600 connections from six pods are gated. The hold adds 4.5 ms median per released connection, of which 24 us is policy. Finally, we gate on request content without terminating TLS: an eBPF uprobe reads the plaintext at the agent's TLS-library boundary (shared OpenSSL, static OpenSSL, Go crypto/tls), a model scores it, and the connection is held on that verdict while TLS stays end-to-end and the enforcer holds no key.