OpenClaw und NanoClaw: Die Sicherheitsdebatte um autonome KI-Agenten

Anfang 2026 löste ein rel­a­tiv unbekan­ntes Open-Source-Pro­jekt einen bemerkenswerten Hype aus: Open­Claw, ein Frame­work für autonome KI-Agen­ten, das auf der eige­nen Hard­ware läuft und via What­sApp, Telegram oder Slack ges­teuert wird. Über 142.000 GitHub-Stars und geschätzt 150.000 laufende Instanzen weltweit – inner­halb weniger Wochen. Das Han­dels­blatt sprach von einem möglichen “iPhone-Moment” für KI-Agen­ten.

Doch bere­its nach kurz­er Zeit mehrten sich kri­tis­che Stim­men. Sicher­heits­forsch­er doku­men­tierten, dass rund 25% der Com­mu­ni­ty-entwick­el­ten “Skills” Schwach­stellen enthal­ten, einzelne pop­uläre Erweiterun­gen exfil­tri­erten aktiv Dat­en. CSO Online pub­lizierte einen Artikel mit dem unmissver­ständlichen Titel: “What CISOs need to know about the Open­Claw secu­ri­ty night­mare.”

Die Reak­tion ließ nicht lange auf sich warten: Mit Nan­oClaw ent­stand eine radikale Alter­na­ti­var­chitek­tur, die expliz­it als Antwort auf Open­Claws Sicher­heit­sprob­leme konzip­iert wurde. Die Debat­te zwis­chen bei­den Ansätzen ist mehr als nur ein tech­nis­ch­er Stre­it – sie illus­tri­ert fun­da­men­tale Trade-offs in der Entwick­lung autonomer Sys­teme.

Das Ver­sprechen: Agen­ten mit vollem Sys­temzu­griff

Open­Claw ist kein Sprach­mod­ell, son­dern ein Orchestrierungs-Frame­work. Es läuft auf der eige­nen Hard­ware (PC, Serv­er, Cloud-VPS) und verbindet sich mit LLMs wie Claude, GPT‑4 oder lokalen Mod­ellen. Die Steuerung erfol­gt über Mes­sen­ger – man chat­tet mit dem Agen­ten wie mit einem Kol­le­gen, nicht über eine Web-UI.

Die Fähigkeit­en sind beein­druck­end: Shell-Befehle aus­führen, Dateien ver­wal­ten, Brows­er automa­tisieren, Buchun­gen durch­führen, E‑Mails bear­beit­en. Der Agent hat per­sis­tentes Gedächt­nis über Ses­sions hin­weg und kann proak­tiv han­deln – etwa tägliche Brief­in­gs ver­schick­en oder automa­tisch auf bes­timmte Events reagieren.

Ein oft zitiertes Beispiel: Der Agent zieht automa­tisch YouTube-RSS-Feeds, analysiert Tran­skripte und gener­iert daraus LinkedIn-Posts, die er zur Freiga­be vor­legt. Der gesamte Con­tent-Recy­cling-Prozess wird automa­tisiert.

Das Sys­tem ist über “Skills” erweit­er­bar – meist ein­fache Mark­down-Dateien mit Instruk­tio­nen, die dem Agen­ten neue Fähigkeit­en für GitHub, Gmail, Smart Home etc. beib­rin­gen. Die Skill-Reg­istry ClawHub fungiert als Mar­ket­place mit Com­mu­ni­ty-Bew­er­tun­gen. Die niedrige Ein­stiegshürde (jed­er kann Mark­down schreiben) hat schnelle Adop­tion ermöglicht.

Das Prob­lem: Con­ve­nience gegen Secu­ri­ty

Die Architek­tur, die diese Flex­i­bil­ität ermöglicht, ist zugle­ich ihre größte Schwäche. Open­Claw läuft in einem einzi­gen Node-Prozess mit shared mem­o­ry. Alle Agen­ten teilen sich densel­ben Adress­raum. Sicher­heit wird über Allowlists und Pair­ing Codes auf Anwen­dungsebene imple­men­tiert – nicht über Betrieb­ssys­tem-Iso­la­tion.

Die Code­ba­sis umfasst über 400.000 Zeilen mit 52+ Mod­ulen, 45+ Depen­den­cies und Abstrak­tio­nen für 15 Chan­nel-Provider. Diese Kom­plex­ität macht voll­ständi­ge Secu­ri­ty-Audits prak­tisch unmöglich. Ein kom­pro­mit­tiert­er Agent oder manip­uliert­er Skill kann poten­ziell auf alle Ressourcen des Host-Sys­tems zugreifen.

Die doku­men­tierten Prob­leme sind konkret: Sicher­heits­forsch­er fan­den, dass etwa ein Vier­tel der unter­sucht­en Skills Schwach­stellen enthält. Einzelne pop­uläre Skills haben aktiv Dat­en exfil­tri­ert. Die ein­fache Mark­down-basierte Skill-Def­i­n­i­tion erle­ichtert zwar die Entwick­lung, macht aber sys­tem­a­tis­che Vali­dierung nahezu unmöglich.

Ein Red­dit-Post brachte es auf den Punkt: “Thou­sands of Open­Claw installs are run­ning with no auth on the gate­way. If you can find it, you can reach it.” Die Real­ität zeigt, dass viele Nutzer die Sicher­heit­skon­fig­u­ra­tion nicht beherrschen.

Die tur­bu­lente Namen­shis­to­rie (Clawd­bot → Molt­bot → Open­Claw) wird von Sicher­heit­sex­perten bere­its als Warnsignal gew­ertet. Open­Claw hat mit­tler­weile reagiert und Virus­To­tal-Scan­ning für alle ClawHub-Skills imple­men­tiert – ein reak­tiv­er Schritt, der bekan­nte Mal­ware erken­nt, aber logis­che Exploits in natür­lich­sprachi­gen Anweisun­gen nicht adressiert.

Die Alter­na­tive: Sicher­heit durch radikale Sim­pliz­ität

Gavriel Cohen, ehe­mals Entwick­ler bei Wix.com, for­mulierte seine Moti­va­tion für Nan­oClaw klar: “I can­not sleep peace­ful­ly when run­ning soft­ware I don’t under­stand and that has access to my life.”

Nan­oClaw invertiert Open­Claws Desig­nentschei­dun­gen fun­da­men­tal:

500 Zeilen statt 400.000: Der Core-Code wurde auf etwa 500 Zeilen Type­Script reduziert. Das gesamte Sys­tem ist in acht Minuten audi­tier­bar. Cohen emp­fiehlt expliz­it: “Send the repos­i­to­ry link to your secu­ri­ty team. They can review it in an afternoon—not just read the code, but white­board the entire sys­tem, map out the attack vec­tors, and ver­i­fy it’s safe.”

Con­tain­er-Iso­la­tion statt Shared Process: Jed­er Agent läuft in einem eige­nen Lin­ux Con­tain­er (Apple Con­tain­er auf macOS, Dock­er auf Lin­ux) mit sep­a­ratem Filesys­tem. Bash-Befehle wer­den inner­halb des Con­tain­ers aus­ge­führt, nicht auf dem Host. Ein kom­pro­mit­tiert­er Agent kann nur auf zugewiesene Con­tain­er-Ressourcen zugreifen, nicht auf das gesamte Sys­tem.

Skills statt fer­tige Fea­tures: Die radikalste Abwe­ichung ist die Entwick­lungsphiloso­phie. Bei typ­is­chen Soft­ware­pro­jek­ten fügen Entwick­ler neue Funk­tio­nen direkt zum Pro­gramm hinzu – etwa Unter­stützung für Telegram oder Dis­cord. Jed­er Nutzer bekommt dann alle Funk­tio­nen, egal ob er sie braucht oder nicht. Das macht die Soft­ware immer kom­plex­er und fehler­an­fäl­liger.

Nan­oClaw geht einen anderen Weg: Das Pro­gramm selb­st bleibt klein und ein­fach. Stattdessen gibt es Anleitun­gen (soge­nan­nte “Skills”), die einem KI-Assis­ten­ten beib­rin­gen, wie er den Code für genau deine Bedürfnisse umschreiben soll.

Ein Beispiel: Du willst Telegram nutzen statt What­sApp? Du gib­st ein­fach den Befehl /add-telegram ein. Der KI-Assis­tent liest die Anleitung, ent­fer­nt den What­sApp-Code aus dein­er Instal­la­tion und baut stattdessen Telegram ein. Dein Sys­tem enthält am Ende nur genau das, was du wirk­lich brauchst – kein über­flüs­siger Bal­last, keine ungenutzten Funk­tio­nen, die Sicher­heit­slück­en öff­nen kön­nten.

Prax­is­test: Pro­duk­tiv­er Ein­satz bei Qwib­it

Die Architek­tur ist kein the­o­retis­ches Kon­strukt. Die Cohen-Brüder nutzen Nan­oClaw pro­duk­tiv für ihre AI-GTM-Agen­tur Qwib­it. Die interne Instanz “Andy” ver­wal­tet die Sales-Pipeline: tägliche Brief­in­gs zu Lead-Sta­tus, automa­tis­che Task-Zuweisung, frik­tion­slose Daten­er­fas­sung via What­sApp.

So funk­tion­iert es im All­t­ag: Die Team­mit­glieder schick­en ein­fach Noti­zen, E‑Mails oder Gesprächsver­läufe an eine gemein­same What­sApp-Gruppe – oft unvoll­ständig for­muliert oder durcheinan­der. Der Agent “Andy” liest diese Nachricht­en, ver­ste­ht den Kon­text und sortiert die wichti­gen Infor­ma­tio­nen her­aus. Er trägt dann automa­tisch ein, welch­er Kunde was gesagt hat, in welchem Sta­di­um ein Verkauf­s­ge­spräch ste­ht oder wann nachge­fasst wer­den muss. Dabei spe­ichert er alles sauber struk­turi­ert ab und erin­nert das Team zur richti­gen Zeit an die näch­sten Schritte.

Das Beson­dere: Nie­mand muss mehr manuell Lis­ten pfle­gen oder Daten­banken aktu­al­isieren. Das Team arbeit­et ein­fach wie gewohnt über What­sApp – der Agent übern­immt im Hin­ter­grund die gesamte Ver­wal­tungsar­beit.

Dieser Case demon­stri­ert, dass Con­tain­er-Iso­la­tion pro­duk­tive Nutzung nicht ver­hin­dert. Die Sicher­heit­sar­chitek­tur ist ein Enabler, kein Block­er – solange Use-Cas­es klar definiert sind.

Nan­oClaw unter­stützt als erster per­sön­lich­er Assis­tent auch Agent Swarms: Teams spezial­isiert­er Agen­ten für kom­plexe Auf­gaben. Beispiel: Ein Audit-Agent analysiert wöchentlich die Git-His­to­ry, ein Research-Agent aggregiert täglich News – jed­er in eigen­em Con­tain­er mit spez­i­fis­chen Zugrif­f­en.

Der Trade-off: Zwei Philoso­phien, zwei Wel­ten

Die Debat­te zwis­chen Open­Claw und Nan­oClaw ist keine tech­nis­che Frage nach “besser­er” Tech­nolo­gie. Sie illus­tri­ert fun­da­men­tale Architek­tur-Philoso­phien:

Open­Claw: Con­ve­nience-First

• Max­i­male Fea­tures out-of-the-box
• Niedrig­ste Ein­stiegshürde
• Gener­ische Lösung für viele Use-Cas­es
• Secu­ri­ty durch Appli­ca­tion-Lay­er-Con­trols
• Preis: Hohe Kom­plex­ität, große Angriffs­fläche, schw­er audi­tier­bar

Nan­oClaw: Secu­ri­ty-First

• Min­i­maler Core, erweit­ert durch Skills
• Höhere ini­tiale Cus­tomiza­tion-Hürde
• Spez­i­fis­che Lösung für definierte Use-Cas­es
• Secu­ri­ty durch OS-Lev­el-Iso­la­tion
• Preis: Mehr manuelle Arbeit, weniger sofor­tige Funk­tion­al­ität

Ein Ver­gle­ich der Sicher­heitsmod­elle macht die Unter­schiede deut­lich:

Wichtig: Auch Nan­oClaw ist keine per­fek­te Lösung. Die Con­tain­er-Tech­nik ver­hin­dert zwar, dass ein kom­pro­mit­tiert­er Agent das gesamte Sys­tem infiziert oder auf andere Agen­ten zugreift. Aber grund­sät­zliche Sicher­heit­srisiken bleiben beste­hen:

Ein Angreifer kann den Agen­ten durch geschickt for­mulierte Nachricht­en oder E‑Mails zu uner­wün­scht­en Hand­lun­gen brin­gen. Der Agent kann Dat­en über nor­male Inter­netverbindun­gen nach außen schick­en. Und Nutzer kön­nen durch geschick­te Manip­u­la­tion dazu gebracht wer­den, gefährliche Befehle zu erlauben.

Auch die Con­tain­er-Absicherung ist nicht unknack­bar. Mit genü­gend tech­nis­chem Aufwand kön­nen Angreifer aus dem Con­tain­er aus­brechen. Die richtige Kon­fig­u­ra­tion der Sicher­heitsmech­a­nis­men erfordert Fach­wis­sen – das haben viele Nutzer nicht.

Und dann gibt es noch offene Fra­gen zum Entwick­lungsmod­ell: Wenn jed­er Nutzer seinen eige­nen, indi­vidu­ell angepassten Code hat – wie hil­ft dann die Com­mu­ni­ty bei Prob­le­men? Wie tauscht man Verbesserun­gen aus? Funk­tion­iert das über­haupt in der Prax­is, wenn hun­derte oder tausende Nutzer völ­lig unter­schiedliche Ver­sio­nen ver­wen­den? Das muss sich erst noch zeigen.

Einord­nung: Wo ste­hen wir wirk­lich?

Der medi­ale Hype um einen “iPhone-Moment” für Agen­ten ist ver­früht. Das iPhone war ein voll­ständig entwick­eltes, pro­duk­tion­sreifes Con­sumer-Pro­dukt mit umfassen­dem Sup­port. Open­Claw und Nan­oClaw sind exper­i­mentelle Frame­works ohne klare Pro­duk­treife, Gov­er­nance oder Sup­port-Struk­turen.

Bei­den fehlen kri­tis­che Enter­prise-Require­ments:

• SAM­L/S­SO-Inte­gra­tion
• Role-Based Access Con­trol (RBAC)
• Audit-Log­ging mit Reten­tion-Poli­cies
• Com­pli­ance-Zer­ti­fizierun­gen (SOC2, ISO27001)
• Pro­fes­sion­al Sup­port-Verträge und SLAs

Ohne diese Bausteine bleiben bei­de auf Indi­vid­ual- und Small-Team-Seg­mente beschränkt.

Für Entwick­ler und Ear­ly Adopters:

• Open­Claw: Inter­es­sant für max­i­male Flex­i­bil­ität, erfordert hohe Risiko­tol­er­anz
• Nan­oClaw: Ratio­nalere Wahl für sicher­heits­be­wusste Nutzer – audi­tier­bar, isoliert, min­i­mal

Für Unternehmen:

• Open­Claw: Nur in strikt isolierten Exper­i­men­tierumge­bun­gen vertret­bar, CSO-War­nun­gen ernst nehmen
• Nan­oClaw: Bess­er audi­tier­bar, aber Con­tain­er-Secu­ri­ty muss Enter­prise-Grade sein
• Bei­de: Pro­to­typ­ing-Tools, keine Pro­duc­tion-Sys­teme

Für die Indus­trie: Open­Claw und Nan­oClaw sind wertvolle Exper­i­mente in der frühen Phase der Agent-Entwick­lung. Sie zeigen unter­schiedliche Wege, aber bei­de sind noch weit von Main­stream-Adop­tion ent­fer­nt.

Was bleibt: Die Lehren aus der Debat­te

Drei zen­trale Erken­nt­nisse kristallisieren sich her­aus:

1. Secu­ri­ty-by-Archi­tec­ture ist möglich – aber teuer

Nan­oClaw beweist, dass fun­da­men­tale Sicher­heit­sprob­leme durch architek­tonis­chen Neuan­fang lös­bar sind. Con­tain­er-Iso­la­tion, min­i­maler Code und Skill-basierte Cus­tomiza­tion funk­tion­ieren. Aber: Sie erfordern bewussten Verzicht auf Con­ve­nience. Sys­teme, die max­i­male Flex­i­bil­ität ver­sprechen, zahlen in Form erhe­blich­er Sicher­heit­srisiken. Sys­teme, die Sicher­heit pri­or­isieren, zahlen in Form höher­er Cus­tomiza­tion-Last.

2. Es gibt keine uni­verselle “richtige” Architek­tur

Die Debat­te ist keine Frage von richtig oder falsch, son­dern von Kon­text und Trade-offs. Unter­schiedliche Use-Cas­es erfordern unter­schiedliche Posi­tio­nen auf dem Con­ve­nience-Secu­ri­ty-Spek­trum. Die Indus­trie muss ler­nen:

• Klarere Use-Case-Seg­men­tierung: Welche Auf­gaben recht­fer­ti­gen welche Risiken?
• Dif­feren­zierte Architek­tur­mod­elle für unter­schiedliche Szenar­ien
• Sys­tem­a­tis­che Gov­er­nance-Frame­works für Agent-Behav­ior

3. Wir sind am Anfang, nicht am Ende

Die Indus­trie begin­nt erst zu ver­ste­hen, welche Architek­turen für welche Agent-Use-Cas­es funk­tion­ieren. Open­Claw und Nan­oClaw sind wichtige Daten­punk­te in dieser Explo­ration – wertvoll für das Ler­nen, aber nicht die finalen Antworten.

Bis sys­tem­a­tis­che Gov­er­nance-Frame­works, reg­u­la­torische Com­pli­ance (EU AI Act etc.) und reife Sup­port-Struk­turen existieren, soll­ten bei­de als exper­i­mentelle Tools behan­delt wer­den – mit allen damit ver­bun­de­nen Chan­cen und Risiken.

Aus­blick: Die näch­sten Fra­gen

Mehrere grund­sät­zliche Fra­gen bleiben offen:

Wird sich das neue Entwick­lungsmod­ell bewähren? Die Idee ist bestechend: Statt das Pro­gramm immer größer und kom­plex­er zu machen, bleibt es klein – und jed­er baut sich seine eigene Ver­sion nach Bedarf. Das macht die Soft­ware sicher­er und schlanker. Aber entste­ht dadurch ein Flick­en­tep­pich aus hun­derten ver­schieden­er Ver­sio­nen? Wie soll man da noch gemein­sam Prob­leme lösen oder Verbesserun­gen aus­tauschen? Erst wenn viele Men­schen das Sys­tem nutzen, wird sich zeigen, ob es wirk­lich funk­tion­iert.

Näh­ern sich bei­de Sys­teme an – oder gehen sie getren­nte Wege? Vielle­icht lernt Open­Claw von Nan­oClaws Sicher­heit­skonzept und wird sicher­er. Vielle­icht fügt Nan­oClaw mehr fer­tige Funk­tio­nen hinzu und wird kom­fort­abler. Dann wür­den bei­de irgend­wann ähn­lich ausse­hen. Oder es zeigt sich, dass jedes Sys­tem für völ­lig unter­schiedliche Zwecke gut ist: Open­Claw zum Exper­i­men­tieren und Aus­pro­bieren, Nan­oClaw für ern­sthafte Arbeitsabläufe.

Wie geht es mit der Sicher­heit weit­er? Früher oder später wer­den Behör­den Regeln für solche autonomen Sys­teme auf­stellen – ähn­lich wie es jet­zt Geset­ze für selb­st­fahrende Autos gibt. Wer­den die Entwick­ler-Com­mu­ni­ties von sich aus dafür sor­gen, dass ihre Soft­ware diese Anforderun­gen erfüllt? Oder warten sie ab, bis der Geset­zge­ber sie dazu zwingt, und müssen dann hek­tisch nachrüsten?

Wer baut die Enter­prise-Bridges? Bei­de Pro­jek­te sind Com­mu­ni­ty-getrieben ohne klares kom­merzielles Mod­ell. Open-Source-Pro­jek­te mit diesem Ambi­tion­s­grad benöti­gen typ­is­cher­weise kom­merzielle Unter­stützung (siehe Kuber­netes, Dock­er). Entste­hen Com­pa­ny-backed Ver­sio­nen mit Enter­prise-Fea­tures? Oder bleiben sie Nis­chen-Tools für Enthu­si­as­ten?

Faz­it: Exper­i­mente, keine Lösun­gen

Open­Claw und Nan­oClaw sind faszinierende Exper­i­mente, aber keine pro­duk­tion­sreifen Lösun­gen. Sie demon­stri­eren unter­schiedliche Antworten auf die Frage: Wie bal­ancieren wir Autonomie und Kon­trolle bei KI-Agen­ten?

Open­Claw zeigt, wie schnell ein Ökosys­tem entste­hen kann, wenn man Con­ve­nience max­imiert. 150.000+ Instal­la­tio­nen weltweit, reich­es Skill-Ecosys­tem, niedrige Ein­stiegshürde. Aber auch: doku­men­tierte Sicher­heit­sprob­leme, schw­er audi­tier­bar, CSO-War­nun­gen.

Nan­oClaw demon­stri­ert, dass Secu­ri­ty-by-Archi­tec­ture möglich ist – durch radikale Sim­pliz­ität, OS-Lev­el-Iso­la­tion, audi­tier­bare Code­ba­sis. Pro­duk­tiv nutzbar (siehe Qwib­it), aber mit eige­nen Unbekan­nten und höher­er ini­tialer Cus­tomiza­tion-Hürde.

Bei­de repräsen­tieren legit­ime, aber unter­schiedliche Desig­nentschei­dun­gen. Die Indus­trie lernt, welche Trade-offs für welche Kon­texte funk­tion­ieren. Das ist der eigentliche Wert dieser Pro­jek­te – nicht als finale Pro­duk­te, son­dern als Lern­felder.

Der proklamierte “iPhone-Moment” ist Zukun­ftsmusik. Bis sys­tem­a­tis­che Gov­er­nance, klare Reg­ulierung und pro­fes­sionelle Sup­port-Struk­turen existieren, bleiben autonome Agen­ten auf eigen­er Hard­ware exper­i­mentelle Werkzeuge – mächtig, riskant und faszinierend zugle­ich.

Die wichtig­ste Erken­nt­nis: Wer mit KI-Agen­ten arbeit­et, muss bewusst Trade-offs tre­f­fen zwis­chen Con­ve­nience und Secu­ri­ty, zwis­chen Flex­i­bil­ität und Kon­trolle, zwis­chen schneller Adop­tion und langfristiger Sta­bil­ität. Es gibt keine ein­fachen Antworten – nur kon­textab­hängig bessere oder schlechtere Entschei­dun­gen.

Und genau deshalb lohnt es sich, die Open­Claw-Nan­oClaw-Debat­te genau zu ver­fol­gen. Sie ist mehr als ein tech­nis­ch­er Stre­it – sie ist ein Lehrstück über die Architek­tur-Entschei­dun­gen, die die näch­ste Gen­er­a­tion autonomer Sys­teme prä­gen wer­den.

Quellen und weit­ere Infor­ma­tio­nen:

Wie Open Claw mich in zwei Tagen überzeugt hat https://www.handelsblatt.com/technik/ki/kuenstliche-intelligenz-wie-open-claw-mich-in-zwei-tagen-ueberzeugt-hat-02/100198522.html

Open­Claw aus­pro­biert: Die gefährlich­ste Soft­ware der Welt? https://www.heise.de/news/OpenClaw-ausprobiert-Die-gefaehrlichste-Software-der-Welt-11161203.html

Wie sich­er ist Open­Claw? https://www.security-insider.de/openclaw-ki-agent-clawhub-sicherheitsrisiko-a-2e2d3988c5f125e652485bcc3a8c7e63/

Nan­oClaw solves one of OpenClaw’s biggest secu­ri­ty issues — and it’s already pow­er­ing the creator’s biz https://venturebeat.com/orchestration/nanoclaw-solves-one-of-openclaws-biggest-security-issues-and-its-already

How to test Open­Claw with­out giv­ing an autonomous agent shell access to your cor­po­rate lap­top https://venturebeat.com/security/how-to-test-openclaw-without-giving-an-autonomous-agent-shell-access-to-your

Run­lay­er is now offer­ing secure Open­Claw agen­tic capa­bil­i­ties for large enter­pris­es https://venturebeat.com/orchestration/runlayer-is-now-offering-secure-openclaw-agentic-capabilities-for-large