Source Code:
skwuwu
/
Analemma-GVM
A governance runtime for AI agents, built on Linux kernel security primitives.
Analemma-GVM
A lightweight secure runtime for autonomous AI agents. Governs every outbound HTTP call, isolates the filesystem, and locks down syscalls — using a Rust proxy and Linux kernel primitives.
I wanted to run multiple autonomous AI agents (such as OpenClaw) for my personal affairs. But every time I let agents do everything they want, there was always a little anxiety. What if it does something it shouldn't? What if it leaks personal information or deletes important data?
Existing answers (such as NemoClaw, OPA+Envoy) required Docker, an embedded Kubernetes cluster, NVIDIA GPUs, or Envoy sidecars. I wanted a lightweight alternative that doesn't need infrastructure setup and strictly enforces what agents do.
So I built GVM (Governance Virtual Machine) — a lightweight security runtime for AI agents. Two small Rust binaries (CLI + proxy, ~22MB total), no Kubernetes, no service mesh, no GPU. It sits between your agent and its actions…
Continuing from the previous post, this time I will explain the monitoring and control methods for outbound traffic—one of the two central axes—divided into DNS and proxy.
How do you stop an agent from making a malicious HTTP call? How do you prevent data exfiltration via DNS when cloud-managed services claim it's "out of scope"? Here is how I built a transparent interception layer for AI agents — adding just +14ms per HTTPS request.(measured on sandbox MITM path, EC2 t3.medium)
1.The Core Problem:
Guardrails vs. Raw Sockets Most AI security focuses on the "Prompt" or "Tool definition." But if an agent has the autonomy to run code, it can bypass your Python decorators and call raw sockets directly.
The Gap: There is disconnect between what an agent should do (as defined in your prompt) and what it can do (as allowed by the OS).
The Solution: We must move governance from the Application Layer to the Runtime/Network Layer.
2.DNS:
The First Gateway Before any HTTP call, there is a DNS query. In a GVM sandbox, the first step of the network governance.
*The resolv.conf Challenge *
Inside sandbox, resolv.conf points to the host's virtual ethernet (veth) IP. I don't use the standard systemd-resolved stub (127.0.0.53) because it binds only to the loopback interface, making it unreachable from the sandbox namespace.
Transparent Redirection
Using iptables PREROUTING rules on the host, I intercept DNS traffic via DNAT, forwarding it to GVM's upstream resolver.
-Note on DNS Tunneling: While GVM focuses on HTTP governance, I recognize DNS exfiltration is a threat. GVM logs query frequencies to provide visibility, but I delegate heavy DNS filtering (like Route 53 DNS Firewall) to the infrastructure layer to keep the runtime lightweight.
3.Proxy:
Forcing the Traffic In GVM, I offer two modes of enforcement:
Cooperative Mode: Injects HTTP_PROXY env vars. Simple, but "polite"—an agent can choose to ignore it.
Sandbox Mode: kernel-level isolation. isolating the agent in a dedicated Network Namespace.
-iptables OUTPUT Chain: It drops everything except traffic destined for Proxy (TCP) and DNS (UDP).
-IPv6 Lockdown: GVM completely disable IPv6 to prevent "happy eyeballs" algorithms from bypassing IPv4-only firewall rules.
-Result: No matter what library the agent uses—requests, httpx, or raw curl— all outbound traffic is routed through the proxy.
4.MITM TLS Inspection:
Peeking Inside the Tunnel A standard CONNECT tunnel only lets you see the destination domain. To enforce granular policies (paths, methods, bodies), GVM must perform Man-in-the-Middle (MITM) inspection.
Ephemeral CA & Just-in-Time Certs
GVM generate an ephemeral CA and inject it into the sandbox's trust store.
-Intercept: The agent initiates a TLS handshake.
-Impersonate: GVM extracts the SNI, generates a per-domain ECDSA P-256 certificate on the fly, and terminates the TLS.
-Inspect: The traffic is now plaintext. GVM apply SRR (Semantic Request Router) policies.
-Relay: GVM establishes a new TLS connection to the actual upstream server.
-Optimization: GVM force ALPN to HTTP/1.1 to simplify parsing and avoid the overhead of complex HTTP/2 frame inspection.
5.SRR: Programmable Traffic Governance
Once the traffic is decrypted, Semantic Request Router (SRR) engine takes over. Using a TOML-based rule system, GVM define deterministic boundaries:
example:
[[rules]]
method = "POST"
pattern = "api.telegram.org"
path_regex = "^/bot[^/]+/sendMessage$"
decision = { type = "Delay", milliseconds = 500 }
Why SRR is different:
Payload Inspection: GVM can block specific GraphQL mutations or gRPC calls by inspecting the body fields.
Default-to-Caution: If no rule matches, GVM applies a "Caution" penalty (a 300ms delay) for user to recognize.
It doesn't trust Agents: not verifying intent, but the actual request/behavior
Summary:
The Multi-Layer DefenseLayerTechnologyPrevents
| Layer | Technology | Prevents |
|---|---|---|
| L0 (DNS) | DNAT / Query logging | Domain-based exfiltration |
| L1 (TCP) | iptables OUTPUT | Proxy bypass, non-standard port leakage |
| L1 (TLS) | Ephemeral CA MITM | Hidden malicious payloads in HTTPS |
| L2 (App) | SRR Engine | Unauthorized API calls, Data theft |
What’s Next?
Governing the network is only half the system. What if the agent tries to read your /etc/shadow or escape the container via a kernel exploit? In the next post, I will explore lower level: How I use Namespaces, Seccomp-bpf, and OverlayFS to create a secure filesystem and process isolation.
Top comments (0)