Jag har byggt en infrastruktur för Zed – min AI-agent på OpenClaw – där den kör i containrar med tydlig nätverkssegmentering. All utgående trafik passerar genom en enda port som jag kontrollerar. Agenten har ingen direkt åtkomst till internet; den kan varken stänga av proxyn eller nå något som inte finns på min tillåtslista. Det här inlägget beskriver vad som är byggt och varför det håller – på hög nivå.

Vad som är byggt

Container och tre nätverk. Zed och dess browser kör i ett isolerat nätverk utan direkt internet – nätverket blockerar på operativsystemnivå, inte bara i applikationen. Den enda vägen ut är via host till en proxy som jag styr. Ett andra nätverk huserar proxyn, MCP-sidecar och databas; ett tredje nätverk är för övervakning (NATS, monitor, PostgreSQL för loggar och godkännanden). Agenten har ingen åtkomst till övervakningsnätverket – den kan varken läsa sina egna loggar eller påverka godkännanden.

En port för all trafik. All HTTP/HTTPS-trafik från Zed går genom mitmproxy. En allowlist i kod bestämmer vilka domäner som släpps igenom; allt annat blockeras. Att lägga till en domän är en kodändring som syns i git – ingen hemlig konfiguration. För domäner som inte är tillåtna kan jag godkänna tillfällig åtkomst direkt i Telegram; godkännandena har tidsgräns och loggas.

Övervakning utanför agentens räckvidd. Nätverkshändelser skickas till en event-bus som bara proxy och monitor använder. Det gäller inte bara tillåtna och blockerade HTTP/HTTPS-anrop, utan också DNS-uppslag och annan trafik som passerar kontrollpunkten. Agentens container har varken tillgång till den busen eller till monitoring-databasen. Säkerheten bygger på nätverksnivå (ingen direkt internet) plus policy som kod plus separation mellan körning och övervakning.

Varför det håller

Kontrollen ligger på nätverksnivå, inte på applikationsnivå. Även om agenten tog bort miljövariabler eller försökte anropa nätet direkt skulle det interna nätverket blockera – det finns ingen rutt ut förbi proxyn. Det ger en tydlig gräns: jag bestämmer vad som kan nås, och jag ser vad som passerar. Zed används som tidigare; skillnaden är att infrastrukturen är byggd så att den inte kan kringgås.

Jag beskrev ett tidigare steg – container och en kontrollpunkt – i Zed ett steg längre: mer kontroll utan mer krångel. Det här bygget bygger på samma idé men med nätverksisolering och tre separata nätverk så att både körning och övervakning har tydliga gränser.

Arkitektur

Tre nätverk med tydliga roller: agenten (Zed + browser) i ett isolerat nätverk, proxy och databas i mitten, övervakning (NATS, monitor) i ett tredje nätverk som agenten inte kan nå.

Övervakningsflödet: proxyn publicerar varje nätverkshändelse till en event-bus, inklusive tillåtna och blockerade anrop, DNS-uppslag och annan trafik som passerar kontrollpunkten. Monitorn prenumererar, lagrar strukturerad data i PostgreSQL och skickar notiser till Telegram vid behov. Agenten har ingen åtkomst till detta flöde.

Det intressanta med att samla detta som strukturerad data i PostgreSQL är nästa steg: att koppla in machine learning och LLM:er för analys. Då kan jag se mönster över tid, förklara avvikelser och bygga smartare regler ovanpå den övervakning som redan finns.