OpenClaw Egress Traffic Control — A New Security Market for AI Agents

AI Agents are evolving from tools into autonomous executors, yet our security models still operate at the level of permissions and resource access. The real risk is no longer resource access — it is intent generation and path drift.

This article shares a proof-of-concept experiment using cgroup + TProxy + TLS SNI to explore a possible enhancement path for AI security. The next wave of the security market may be built around what I call Intent Security. The rise of AI Agents could mark the beginning of a new security cycle.

Introduction

In “AI Anxiety: From OpenClaw to Agent Smith in The Matrix”, I discussed the evolution of AI Agents and the anxiety that follows their rapid development.

But anxiety is only the surface.

The real question is:

When AI Agents begin executing real-world operations on behalf of humans, is our current security architecture ready?

If the answer is no, then a new security market is not optional — it is inevitable.

Software like OpenClaw — personal AI Agents — may soon become as common as PC applications were in the 1990s and early 2000s. They may run on desktops, local servers, or even mobile devices.

History has repeatedly shown:

Every leap in capability is accompanied by a leap in risk.

This is no longer about Siri or Google Assistant-style voice helpers. These systems can execute, compose, plan, and chain actions.

The more powerful the capability, the larger the attack surface.

History Doesn’t Repeat, But It Rhymes

The 1990s saw the explosion of PC software.

I first started using PCs around 1995. It was a “function-first” era. People downloaded programs freely, exchanged floppy disks, and installed software from unknown sources — until viruses became widespread.

1996 — KV100 antivirus released in China
1998 — CIH demonstrated that even BIOS could be destroyed
2000 — ILOVEYOU marked large-scale internet virus propagation
2003 — SQL Slammer showed how networks could be infected within minutes
2017 — WannaCry turned ransomware into a global event

The pattern is clear:

Every amplification of execution capability leads to exponential amplification of attack capability.

AI Agents are now at the starting point of execution amplification.

Risk

AI Agents Change the Fundamental Assumption of Security

Traditional security assumes:

Humans initiate operations. Programs execute predefined logic.

In the AI Agent era, the structure reverses:

Humans describe goals.
Agents generate execution paths.
Systems perform concrete operations.

The protected object shifts from:

Files
Processes
Ports
APIs

To:

Intent

This is not rhetorical — it is a structural shift in the security boundary.

An Agent can:

Generate shell commands autonomously
Access external networks automatically
Operate SaaS platforms in bulk
Compose multi-step execution chains

The question is no longer:

Does it have permission?

The real questions become:

Does it understand the objective correctly?
Was it misled by prompt injection?
Has the goal drifted during multi-step planning?

Sandbox Is Not the End

Developers already recognize the need to constrain Agents. Sandboxes and containers are now common patterns. Runtime isolation is necessary — but insufficient.

At the system level:

How do we control outbound L3/L7 network connections?
How do we trace and audit the intent origin of every command and network request?

At the user-permission level:

What identity does the Agent assume?
When chat becomes the primary interface, does the Agent inherit full user privileges?
Traditional RBAC lacks sufficient granularity.
Agents operate at a higher abstraction level than static permission models were designed for.
Information trust becomes a problem.
If the Agent is a loyal secretary, how does it evaluate untrusted internet content?

All of these mechanisms focus on resource access, not goal drift.

For example:

“Help me optimize server performance.”

This high-level objective can be decomposed into countless low-level execution paths.

Traditional RBAC cannot determine whether:

The action is reasonable optimization
It is excessive intervention
Or it is malicious behavior triggered by prompt injection

What we lack is not more permission rules.

We lack a controllable execution-path layer.

The fundamental difference is this:

Agent execution chains are dynamically generated.
Dynamic systems require dynamic security layers.

If PC-era security products protected the file system, AI-era security products will need to protect the intent system.

This is a paradigm shift.

Risk Is Opportunity

“The pessimist sees difficulty in every opportunity.
The optimist sees opportunity in every difficulty.”
— Winston Churchill

Every technological leap reshapes the security market.

PCs created the antivirus industry
The internet created firewalls and IDS
Mobile computing created mobile security and app auditing

What will AI Agents create?

Network Flow Control PoC

Below is a proof-of-concept experiment.

Core objective:

Make AI Agent egress traffic markable, redirectable, and auditable.

Technical Approach

Use cgroup v2 to precisely mark service traffic
Use TProxy to transparently redirect TCP outbound traffic
Use TLS SNI for domain-level identification
Apply policy routing or interception based on domain

This example demonstrates TLS/HTTPS-level outbound control with domain-based routing and blocking.

The idea is to deploy an egress control gateway that allows policy-based selection of outbound internet paths.

+----------------------------------+                        
| +------------------+             |         +-------------+
| |                  |             |         |             |
| |     OpenClaw     |             |  TProxy |             |
| |                  |             +-------->|    Proxy    |
| ++-----------------+             |         |             |
|  |                               |         |             |
|  | +-------------------------+   |         ++----+-------+
|  +-+ child processes:        |   |          |    |        
|    |                         |   |          |    |        
|    |  bash commands: curl/...|   |          |    |        
|    |  browser: Chrome/...    |   |          |    |        
|    |                         |   |          |    |        
|    +-------------------------+   |          |    |        
|                                  |          |    |        
|     Linux service cgroupv2       |          |    |        
+----------------------------------+          |    |        
                                              |    |        
                                              v    |        
                                    +-----------+  |        
                                    | Internet 1|  |        
                                    +-----------+  |        
                                                   |        
                                    +-----------+  |        
                                    | Internet 2|<-+        
                                    +-----------+

TProxy Traffic Control

Each Linux service runs in an independent cgroup v2 hierarchy.

➜ $ systemctl --user status openclaw-gateway.service
● openclaw-gateway.service - OpenClaw Gateway (v2026.2.22-2)
     Loaded: loaded (/home/mark/.config/systemd/user/openclaw-gateway.service; enabled; preset: enabled)
    Drop-In: /home/mark/.config/systemd/user/openclaw-gateway.service.d
             └─override.conf
     Active: active (running) since Tue 2026-02-24 16:06:19 HKT; 8s ago
   Main PID: 87270 (openclaw-gatewa)
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/openclaw-gateway.service
             └─87270 openclaw-gateway

Each cgroup v2 can apply its own outbound TProxy rules.

Using nftables + policy routing + TProxy, we can:

Precisely mark TCP traffic from a specific service
Transparently redirect it to a local proxy
Perform SNI-based policy control

Advantages:

No modification to Agent code
No intrusion into business logic
Operates as a system-level security enhancement layer

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92


#!/bin/bash

# Configuration
PROXY_PORT=12345
SERVICE_PATH="user.slice/user-1000.slice/user@1000.service/app.slice/openclaw-gateway.service"
MARK_ID=1
TABLE_ID=100

set -x
# set -e

echo "=== Setting up TPROXY for openclaw-gateway.service ==="

# 1. Create routing table for marked packets
echo "Configuring policy routing..."
ip rule del fwmark $MARK_ID table $TABLE_ID 2>/dev/null || true
ip -6 rule del fwmark $MARK_ID table $TABLE_ID 2>/dev/null || true

ip rule add fwmark $MARK_ID table $TABLE_ID
ip route add local 0.0.0.0/0 dev lo table $TABLE_ID
ip -6 rule add fwmark $MARK_ID table $TABLE_ID
ip -6 route add local ::/0 dev lo table $TABLE_ID

# 2. Delete existing table (outside heredoc)
echo "Configuring nftables..."
nft delete table inet tproxy_openclaw 2>/dev/null || true

# 3. Apply nftables ruleset
nft -f - <<EOF
table inet tproxy_openclaw {
    # RFC1918 Private IPv4 Networks
    set bypass_v4 {
        type ipv4_addr
        flags interval
        elements = {
            10.0.0.0/8,
            172.16.0.0/12,
            192.168.0.0/16,
            127.0.0.0/8,
            169.254.0.0/16,
            224.0.0.0/4,        # Multicast
            240.0.0.0/4         # Reserved
        }
    }

    # Private and Special IPv6 Addresses
    set bypass_v6 {
        type ipv6_addr
        flags interval
        elements = {
            ::1/128,            # Loopback
            fe80::/10,          # Link-local
            fc00::/7,           # Unique local (ULA)
            ff00::/8            # Multicast
        }
    }

    chain output_mark {
        type route hook output priority mangle; policy accept;

        # Bypass local/private destinations
        ip daddr @bypass_v4 return
        ip6 daddr @bypass_v6 return

        # Mark traffic from openclaw-gateway service
        socket cgroupv2 level 5 "$SERVICE_PATH" meta l4proto tcp meta mark set $MARK_ID
    }

    chain prerouting_tproxy {
        type filter hook prerouting priority mangle; policy accept;

        # Handle already-established transparent connections
        socket transparent 1 meta mark set $MARK_ID accept

        # Redirect marked TCP traffic to TPROXY
        meta l4proto tcp meta mark $MARK_ID \
            tproxy ip to 127.0.0.1:$PROXY_PORT \
            meta mark set $MARK_ID accept

        meta l4proto tcp meta mark $MARK_ID \
            tproxy ip6 to [::1]:$PROXY_PORT \
            meta mark set $MARK_ID accept
    }
}
EOF

echo "=== Setup complete! ==="
echo ""
echo "Verify with:"
echo "  sudo nft list table inet tproxy_openclaw"
echo "  sudo ip rule show"
echo "  sudo ip route show table $TABLE_ID"

Traffic Routing

With a TLS SNI–aware proxy (any open-source proxy with sniffing capability. V2ray is an example), we can implement:

Domain-based routing
Blacklist / whitelist blocking
Multi-egress strategies
Auditing and logging

If future policies are dynamically maintained by a governance Agent, we form a closed loop:

Agent executes

Security Agent supervises

Policies evolve dynamically

This becomes, in essence, a system of strategic interaction between Agents.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63


inbounds:
  - port: 12345
    protocol: dokodemo-door
    settings:
      network: tcp,udp
    sniffing:
      enabled: true
      destOverride:
        - http
        - tls
    streamSettings:
      sockopt:
        tproxy: tproxy  # TPROXY inbound

outbounds:
  - protocol: vm***
    settings:
      ...
    tag: internet_1

  - protocol: vm***
    settings:
    ...
    tag: internet_2

  - protocol: blackhole
    settings: {}
    tag: block

  - protocol: freedom
    tag: direct
    settings: {}

routing:
  domainStrategy: AsIs
  rules:
    - type: field
      domain:
        - domain:internet1.com
      outboundTag: internet_1

    - type: field
      domain:
        - domain:internet2.com
      outboundTag: internet_2

    - type: field
      domain:
        - domain:blocked_domain.com
      outboundTag: blackhole

    - type: field
      ip:
        - 192.168.0.0/16
        - fc00::/7
        - fe80::/10
      outboundTag: direct

    - type: field
      ip:
        - geoip:private
        - geoip:XX
      outboundTag: direct

Conclusion

Security is moving from resource control to intent control.

As AI Agents gain execution autonomy, the core challenge is no longer permission management, but execution-path governance. System-level egress control using cgroup, TProxy, and SNI inspection offers one possible foundation for Intent Security.

The next security cycle may not protect files or networks — it may protect intention itself.

Chat