DEV Community: Kyubin Kim

Agent can bypass Proxy governance, What can we do?

Kyubin Kim — Tue, 14 Apr 2026 16:57:05 +0000

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…

View on GitHub

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.

I built a secure runtime for AI agents with Rust and Linux kernel features

Kyubin Kim — Fri, 10 Apr 2026 14:01:13 +0000

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.

View on GitHub

Why I built this?:
I really wanted to use multiple autonomous agents (such as OpenClaw) 24/7 to automate my workflows, but letting them to do everything they require made me anxious. For example, they can read my .env files and expose it to internet by misleading context, call external api incorrectly that making financial costs, and delete my important data accidentally. Because they are not essentially deterministic the probability of such events occurring isn't zero. In fact, a lot of security accident cases are found in reality.

For sure, i considered about using existing security options such as NVDIA's NemoClaw, docker/VM isolation for agents, but i didn't want to build and maintain kubernetes or virtual machine infrastructure. For solo dev or small teams, this solutions are so heavy. Also, they don't enforce what agent actually do.

So i decided to build this project(GVM), light weight governance runtime with low dependencies for AI agent made with Rust proxy combining Linux kernel features(Namespace, Overlayfs, seccomp-bpf). Rust proxy governs agent's actual external I/O, and Linux kernel stacks enforce agent to use proxy, and what syscalls they can use.

What it actually can do:

-Proxy catches every outbound HTTP/HTTPS call and checks if it matches with your ruleset. unknown calls are delayed or denied.

-On Linux environment, kernel level isolation guarantees that the proxy isn't bypassed by agent.

-Agents write to an overlay file system, so they can't directly change real data.

-GVM is just binary, and it does not extract your data from your server like saas services.

How it works, briefly:

Agent → GVM Proxy (rule check) → External API
↓ denied/delayed
Merkle-chained audit log

On Linux, kernel-level network isolation forces all traffic through
the proxy — the agent has no userspace path around it. On macOS/Windows, cooperative mode works via HTTP_PROXY injection.

Typical workflow:

gvm run --sandbox --watch — see what your agent calls
gvm suggest — generate rules from the session
gvm run --sandbox — enforce with kernel isolation

About more technical information:
It will be covered in next posts. explaining all about my project can make this post too long, so there will be another deep dive posts. If you are interested before my next posts are written, please read github link's docs!

Welcome for Feedbacks!
It's alpha release stage, so it's not hardened yet. It has only been tested on the EC2 and OpenClaw combination now. I'd be glad to get architecture and technical feedbacks.