Mens OpenClaw vokser sig stadigt større med 430.000+ linjer kode og 50+ integrationer, er et nyt projekt dukket op med en radikalt anderledes tilgang. NanoClaw er en letvægts AI-agent-platform der kan opsummeres i ét tal: ~500 linjer core TypeScript. Og ét princip: din AI-agent bør aldrig køre direkte på din maskine.
Projektet er skabt af Gavriel Cohen — VP i PR-firmaet Concrete Media og medstifter af Qwibit — og har på ganske kort tid fået opmærksomhed fra VentureBeat, Hacker News og diverse AI-communities. Men hvad er det egentlig NanoClaw gør rigtigt, hvad mangler det, og er container-isolation virkelig svaret på AI-agenters sikkerhedsproblemer?
Problemet: AI-agenter med adgang til dit liv
Kerneproblemet, som NanoClaw adresserer, er reelt nok. Når du kører en AI-agent som personlig assistent — med adgang til dine filer, din kalender, dine beskeder — så stoler du på, at softwaren holder sig inden for de grænser, den lover. OpenClaw og lignende platforme bruger application-level sikkerhed: allowlists, pairing-koder og tilladelses-tjek i selve koden. Det virker i praksis, men det er fundamentalt en anden slags garanti end OS-level isolation.
Som Cohen selv formulerer det: “I can’t sleep well running software I don’t understand with access to my life.” Og det er svært at være uenig i præmissen — selvom man kan diskutere om hans løsning er den eneste rigtige.
Arkitekturen: elegant i sin enkelhed
NanoClaws arkitektur kan beskrives i en enkelt linje:
WhatsApp (baileys) → SQLite → Polling loop → Container (Claude Agent SDK) → ResponseDet hele kører som én Node.js-process. Beskeder fra WhatsApp gemmes i SQLite, en polling-loop fanger nye beskeder, og for hver besked startes en isoleret Linux-container (Apple Containers på macOS, Docker på Linux) hvor Claude Agent SDK behandler forespørgslen. Svaret sendes tilbage via WhatsApp.
De centrale kildefiler er overraskende overskuelige:
src/index.ts— orkestrering, state, beskedloopsrc/container-runner.ts— spawner isolerede agent-containeresrc/channels/whatsapp.ts— WhatsApp-forbindelse via baileyssrc/db.ts— SQLite-operationersrc/task-scheduler.ts— planlagte opgavergroups/*/CLAUDE.md— per-gruppe hukommelse
Hver WhatsApp-gruppe får sit eget isolerede filsystem og sin egen CLAUDE.md-hukommelsesfil. Det betyder at agenten i din “Familie”-gruppe aldrig kan se data fra din “Arbejde”-gruppe. Det er en ren og gennemtænkt model.
Sikkerhedsmodellen: containere som sandkasse
Her er NanoClaws virkelige salgsargument. I stedet for at sige “vi har en allowlist der blokerer farlige kommandoer”, siger NanoClaw: “agenten kan slet ikke se dit filsystem — den kører i en container.”
Konkret betyder det:
- Filsystem-isolation — agenten kan kun tilgå mapper der eksplicit er mounted ind i containeren
- Mount-allowlist — konfigureret i
~/.config/nanoclaw/(uden for containerens rækkevidde), med symlink-beskyttelse via real path resolution - Automatisk blokering af sensitive stier som
.ssh,.gnupg, credentials og lignende - Bash-kommandoer eksekveres inde i containeren — aldrig på host-maskinen
På macOS bruges Apple Containers (kræver macOS Tahoe/26), mens Linux-brugere kører Docker. Blast radius ved en potentiel prompt injection er dermed begrænset til containerens indhold og den specifikke kommunikationskanal.
Det er en ægte forbedring i forhold til applikationsniveau-sikkerhed. Men det er vigtigt at holde perspektivet: container-isolation er ikke magisk. En ondsindet agent kan stadig misbruge de mountede mapper, sende uønskede beskeder via WhatsApp, eller bruge API-nøgler der er tilgængelige i containerens miljø. Containeren begrænser overfladen, men eliminerer ikke risikoen.
“AI-native” udvikling: et paradigmeskift eller en begrænsning?
NanoClaw er bygget med det, Cohen kalder en “AI-native” tilgang. Setup kører via Claude Code (git clone → cd nanoclaw → claude → /setup), debugging sker ved at spørge Claude hvad der er galt, og udvidelser bidrages som “skills” — Claude Code-instrukser der transformerer din installation — i stedet for traditionelle pull requests.
Filosofien er bevidst: ingen installationswizards, ingen monitoring-dashboards, ingen config-filer. Vil du ændre trigger-ordet? Sig det til Claude. Vil du have kortere svar? Bed Claude om det. Kodebasen er lille nok til at Claude kan ændre den sikkert.
Det er en fascinerende tilgang, men den rejser spørgsmål om vedligeholdelse og tilgængelighed. Hvad sker der når Claude’s SDK ændrer sig? Hvad med brugere der foretrækker at læse dokumentation frem for at føre en samtale? Og som Hacker News-debatten afslørede: når selve README’en lugter af LLM-genereret tekst, signalerer det for mange at koden heller ikke er grundigt gennemgået af et menneske.
Hvad siger fællesskabet?
NanoClaw har fået blandede reaktioner. Superprompt.com listede det som “Most Secure” OpenClaw-alternativ. TechPlanet lavede en solid teknisk gennemgang.
Men VentureBeat-artiklen fra 11. februar fortjener et forbehold: Concrete Media, der sandsynligvis har faciliteret dækningen, er Cohens eget PR-firma. Det gør ikke artiklen forkert, men det er værd at have med i sin kildekritik.
På Hacker News var tonen mere skeptisk. Kritikpunkterne var primært:
- AI-genereret dokumentation — flere kommentatorer pegede på “LLM-lugten” i README og docs, hvilket rejste tvivl om menneskelig gennemgang af koden
- 500-linjers påstanden — det gælder core-logikken, ikke hele kodebasen, hvilket er en vigtig nuance
- Container-isolation løser ikke alt — en sandbox begrænser overfladen, men den “dødelige treenighed” af AI-agenter med bred adgang forbliver en udfordring
- Vedligeholdelse på lang sigt — bekymring over om AI-genereret kode uden dyb investering kan holde over tid
Cohen var åben omkring sin tilgang: “I don’t care deeply about this code. It’s not a masterpiece. It’s functional code that is very useful to me.” Det er ærligt — og det er i virkeligheden hele pointen med projektet.
Hvad NanoClaw mangler
At sammenligne NanoClaw med OpenClaw er lidt som at sammenligne en schweizisk lommekniv med en skalpel. De løser forskellige problemer. Men det er værd at nævne hvad der mangler:
- Kun WhatsApp — OpenClaw understøtter 50+ integrationer (Telegram, Discord, Slack, email, kalender osv.). NanoClaw har en skills-baseret model til at tilføje flere, men i praksis er det stadig primært WhatsApp.
- Single-user fokus — NanoClaw er designet til én person. Det er ikke en platform, det er et personligt værktøj.
- macOS Tahoe-krav — Apple Containers kræver den nyeste macOS. Linux-brugere kan bruge Docker, men den native oplevelse er Mac-fokuseret.
- Lille økosystem — OpenClaw har ClawHub, hundredvis af skills og et stort fællesskab. NanoClaws skills-katalog er stadig spædt.
- Kun Claude — bygget direkte på Anthropic’s Agent SDK, så der er ingen mulighed for at bruge andre modeller.
Hvad betyder det i praksis?
NanoClaw er ikke en erstatning for OpenClaw. Det er et proof-of-concept for en vigtig idé: at AI-agenter bør køre i isolerede miljøer, ikke med direkte adgang til host-systemet. Det er en idé som hele branchen bør tage alvorligt — og som OpenClaw i øvrigt også bevæger sig mod med deres container-isolation roadmap.
For den teknisk nysgerrige er NanoClaw værd at studere. Kodebasen er lille nok til at man reelt kan forstå hele systemet på en eftermiddag. Arkitekturen er elegant. Og sikkerhedsmodellen med mount-allowlists og container-isolation er gennemtænkt.
For den der bare vil have en AI-assistent der virker med alt — kalender, email, smart home, Telegram, Discord — er OpenClaw stadig det oplagte valg. Men måske med en smule eftertanke om hvad der sker, når man giver en AI-agent adgang til hele sit digitale liv, kun beskyttet af en allowlist i JavaScript.
Links
Denne artikel er skrevet i samarbejde med AI, og efterfølgende redigeret af et rigtigt menneske 🙂
