OpenClaw: Nüchterne Analyse eines agentenbasierten KI-Frameworks

1. Grun­dar­chitek­tur und tech­nis­che Posi­tion­ierung

Open­Claw ist kein eigen­ständi­ges Sprach­mod­ell, son­dern ein Orchestrierungs-Frame­work für Large Lan­guage Mod­els. Die Architek­tur basiert auf drei Ker­nele­menten: Self-Host­ing auf eigen­er Hard­ware (PC, Serv­er, VPS), Anbindung extern­er LLMs (Anthrop­ic Claude, Ope­nAI, lokale Mod­elle via Olla­ma) und Mes­sen­ger-basierte Steuerung (What­sApp, Telegram, Sig­nal, Slack, Dis­cord, iMes­sage). Diese Desig­nentschei­dun­gen unter­schei­den Open­Claw fun­da­men­tal von web­basierten Chat­bot-Inter­faces und posi­tion­ieren es als lokale Automa­tisierungsin­fra­struk­tur mit per­sis­ten­ter Laufzeit.

Die Entschei­dung für Self-Host­ing bringt tech­nis­che Autonomie, erfordert aber entsprechende Infra­struk­tur und Know-how. Anders als SaaS-Lösun­gen liegt die Ver­ant­wor­tung für Betrieb, Updates und Sicher­heit voll­ständig beim Betreiber. Die Mes­sen­ger-Inte­gra­tion fol­gt dem Par­a­dig­ma “Chat as Inter­face” – Nutzer inter­agieren mit dem Sys­tem wie mit einem men­schlichen Kol­le­gen, ohne dedi­zierte Anwen­dung­sober­fläche.

2. Funk­tion­sum­fang und Sys­tem­inte­gra­tion

2.1 Sys­temzu­griff und Automa­tisierung

Open­Claw erhält stan­dard­mäßig weitre­ichen­den Zugriff auf das Host-Sys­tem: Shell-Kom­man­dos aus­führen, Dateisys­tem lesen und schreiben, Soft­ware instal­lieren, Skripte starten. Diese Fähigkeit­en ermöglichen tief­greifende Automa­tisierung von Sys­temad­min­is­tra­tion, Daten­ver­ar­beitung und Work­flow-Orchestrierung. Der Agent kann eigen­ständig Entwick­lung­sumge­bun­gen auf­set­zen, Logs analysieren, Back­ups erstellen oder Mon­i­tor­ing-Auf­gaben übernehmen.

Die Brows­er-Automa­tisierung erweit­ert den Aktion­sra­dius auf Web-basierte Sys­teme: For­mu­la­re aus­füllen, Buchun­gen durch­führen, Dat­en extrahieren, E‑Mails in Webin­ter­faces bear­beit­en. Damit wer­den auch Dien­ste automa­tisier­bar, die keine API anbi­eten. Dies ist prak­tisch rel­e­vant für Lega­cy-Sys­teme, admin­is­tra­tive Por­tale oder Dien­ste mit restrik­tiv­en API-Poli­cies.

2.2 Mem­o­ry und Kon­textper­sis­tenz

Ein zen­trales Dif­feren­zierungsmerk­mal ist das per­sis­tente Gedächt­nis über Ses­sions hin­weg. Open­Claw spe­ichert Pro­jek­tkon­text, Dateip­fade, Nutzer­präferen­zen und frühere Inter­ak­tio­nen. Dies ermöglicht kon­tinuier­liche Arbeit an langfristi­gen Pro­jek­ten ohne repet­i­tive Kon­textver­mit­tlung. Der Agent “ken­nt” bere­its bear­beit­ete Code­bas­es, laufende Recherchen oder wiederkehrende Auf­gaben­stel­lun­gen.

Diese Kon­textper­sis­tenz ist zugle­ich Stärke und Schwach­stelle: Sie erhöht die Pro­duk­tiv­ität erhe­blich, schafft aber auch Abhängigkeit­en und wirft Fra­gen nach Daten­hal­tung, Ver­sion­ierung und Migra­tion auf.

2.3 Proak­tive Aktio­nen und Work­flow-Ini­ti­ierung

Anders als reak­tive Chat­bots kann Open­Claw eigenini­tia­tiv han­deln. Der Agent meldet sich selb­st­ständig via Mes­sen­ger, wenn Tasks abgeschlossen sind, Schwell­w­erte über­schrit­ten wer­den oder vordefinierte Zeit­punk­te erre­icht sind. Beispiele sind tägliche News-Digests, automa­tis­che Back­up-Berichte oder Benachrich­ti­gun­gen bei Sys­tem-Anom­alien.
Diese Proak­tiv­ität ver­wan­delt den Agen­ten von einem Frage-Antwort-Sys­tem in einen autonomen Prozes­sak­teur. Damit ver­schieben sich auch die Kon­trollmech­a­nis­men: Statt expliziter Befehle wer­den Ziele, Rah­menbe­din­gun­gen und Eskala­tion­skri­te­rien definiert.

3. Erweit­er­barkeit durch Skills

3.1 Skill-Architek­tur

Das Skill-Sys­tem von Open­Claw fol­gt einem bemerkenswert ein­fachen Ansatz: Skills sind primär Mark­down-Dateien mit struk­turi­erten Anweisun­gen, die dem Agen­ten neue Fähigkeit­en ver­mit­teln. Diese niedrige Ein­stiegshürde ermöglicht bre­ite Com­mu­ni­ty-Beteili­gung – jed­er, der natür­liche Sprache for­mulieren kann, kann the­o­retisch Skills entwick­eln.

Die Skill-Reg­istry ClawHub fungiert als zen­trale Verteilungsin­fra­struk­tur mit Ver­sion­ierung, Vek­tor­suche und Com­mu­ni­ty-Bew­er­tun­gen. Dieser Mar­ket­place-Ansatz erzeugt Net­zw­erk­ef­fek­te: Je mehr Skills ver­füg­bar sind, desto wertvoller wird die Plat­tform. Die über 142.000 GitHub-Stars Anfang 2026 indizieren erhe­bliche Entwick­ler-Aufmerk­samkeit.

3.2 Ökosys­tem-Dynamik

Rund um Open­Claw entste­ht ein zweis­chichtiges Ökosys­tem: Zum einen Skills für spez­i­fis­che Inte­gra­tio­nen (GitHub, Gmail, Smart Home, Daten­banken), zum anderen Meta-Ser­vices wie Cloud-Host­ing-Ange­bote, 1‑Click-Deploys und spezial­isierte Dien­ste wie Molt­book (ein Sozial­net­zw­erk, in dem Agen­ten posten).

Diese Ökosys­tem-Dynamik fol­gt bekan­nten Plat­tform-Mustern: Frühe Adop­tion, schnelle Skill-Pro­lif­er­a­tion, Dif­feren­zierung durch spezial­isierte Dien­ste. Die tur­bu­lente Namen­shis­to­rie (Clawd­bot → Molt­bot → Open­Claw) deutet allerd­ings auf organ­isatorische Insta­bil­ität hin, die typ­isch für junge Open-Source-Pro­jek­te ist.

4. Anwen­dungsszenar­ien und pro­duk­tive Nutzung

4.1 Entwick­ler- und Pow­er-User-Work­flows

Der offen­sichtlich­ste Nutzungskon­text sind Entwick­ler­work­flows: Code-Review-Automa­tisierung, Doku­men­ta­tion­s­gener­ierung, CI/CD-Inte­gra­tion, automa­tisiertes Test­ing. Open­Claw kann kon­tinuier­lich Repos­i­to­ries überwachen, Pull Requests analysieren, Deploy­ment-Logs prüfen und bei Anom­alien ein­greifen.

Für Pow­er-User bietet sich Con­tent-Repur­pos­ing an: Ein häu­fig genan­ntes Beispiel ist die automa­tis­che Ver­ar­beitung von YouTube-Tran­skripten zu LinkedIn-Posts. Der Agent zieht RSS-Feeds, extrahiert Ker­naus­sagen, for­muliert Social-Media-Con­tent und legt ihn zur Freiga­be vor. Dies automa­tisiert den gesamten Con­tent-Recy­cling-Prozess.

4.2 Organ­isatorische und admin­is­tra­tive Automa­tisierung

Wiederkehrende admin­is­tra­tive Auf­gaben sind ein weit­eres Ein­satzfeld: E‑Mail-Triage, Kalen­derko­or­di­na­tion, Reise­buchun­gen, Doku­menten­man­age­ment. Der Agent kann eigen­ständig Ein­gangspost sicht­en, nach definierten Kri­te­rien pri­or­isieren, Stan­dard-Antworten for­mulieren und Ter­mine koor­dinieren.

Research- und Infor­ma­tion­sag­gre­ga­tion prof­i­tieren von der Kom­bi­na­tion aus Web-Zugriff und Kon­textper­sis­tenz. Der Agent kann über Tage oder Wochen Infor­ma­tio­nen zu einem The­ma sam­meln, struk­turi­eren und verdicht­en, ohne dass der Nutzer kon­tinuier­lich Kon­text liefern muss.

4.3 Pro­to­typ­ing und Explo­ration

Für Unternehmen bietet Open­Claw eine niedrigschwellige Pro­to­typ­ing-Umge­bung für Agent-Use-Cas­es. Teams kön­nen exper­i­men­tieren, welche Auf­gaben sich sin­nvoll automa­tisieren lassen, bevor sie in kon­trol­lierte, pro­duk­tion­sreife Sys­teme investieren. Diese Explo­ration ist beson­ders wertvoll, weil sie reale Prozesse unter realen Bedin­gun­gen testet.

5. Struk­turelle Chan­cen

5.1 Tech­nol­o­gis­che Autonomie

Self-Host­ing bedeutet volle Kon­trolle über Dat­en, Mod­ell­wahl und Kon­fig­u­ra­tion. Organ­i­sa­tio­nen kön­nen lokale Mod­elle nutzen, sen­si­ble Dat­en on-premise hal­ten und das Sys­tem nach eige­nen Com­pli­ance-Anforderun­gen kon­fig­uri­eren. Dies ist beson­ders rel­e­vant für reg­ulierte Branchen oder Organ­i­sa­tio­nen mit strik­ten Daten­schutzan­forderun­gen.

5.2 Com­pos­abil­i­ty und Inte­gra­tion

Die mod­u­lare Architek­tur ermöglicht flex­i­ble Kom­po­si­tion ver­schieden­er Fähigkeit­en. Statt mono­lithis­ch­er Lösun­gen kön­nen spez­i­fis­che Funk­tions­bün­del nach Bedarf kom­biniert wer­den. Dies reduziert Ven­dor Lock-in und erlaubt inkre­mentelle Adop­tion.

5.3 Com­mu­ni­ty-getriebene Inno­va­tion

Das offene Skill-Ökosys­tem erzeugt dezen­trale Inno­va­tion ohne zen­trale Pla­nungsin­stanz. Nutzer entwick­eln Skills für ihre spez­i­fis­chen Bedürfnisse, die dann der gesamten Com­mu­ni­ty zur Ver­fü­gung ste­hen. Dieser Bot­tom-up-Ansatz ist typ­is­cher­weise schneller und vielfältiger als top-down-ges­teuerte Entwick­lung.

5.4 Kosten­struk­tur

Die Nutzung eigen­er Hard­ware und offen­er Mod­elle kann sig­nifikante Kosten­vorteile gegenüber pro­pri­etären SaaS-Lösun­gen bieten, beson­ders bei hohem Nutzungsvol­u­men. Statt pro Request zu zahlen, fall­en primär Infra­struk­turkosten an.

6. Struk­turelle Risiken und Lim­i­tierun­gen

6.1 Sicher­heit­sar­chitek­tur

Die größte struk­turelle Schwäche ist die Sicher­heit­sar­chitek­tur. Sicher­heits­forsch­er haben doku­men­tiert, dass etwa 25% der unter­sucht­en Skills Schwach­stellen enthal­ten. Einzelne pop­uläre Skills haben aktiv Dat­en exfil­tri­ert. Die Kom­bi­na­tion aus tiefem Sys­temzu­griff, Com­mu­ni­ty-gener­ierten Skills und Mark­down-basiert­er Skill-Def­i­n­i­tion schafft erhe­bliche Angriffs­flächen.

Typ­is­che Bedro­hungsvek­toren sind: Daten­abfluss durch manip­ulierte Skills, Miss­brauch von Sys­tem­berech­ti­gun­gen, Prompt-Injec­tion aus exter­nen Quellen (E‑Mails, Web­seit­en), unbe­ab­sichtigte Schad­funk­tio­nen durch schlecht for­mulierte Anweisun­gen. Die Ein­fach­heit der Skill-Entwick­lung – jed­er kann Mark­down schreiben – ist zugle­ich Sicher­heit­srisiko.

6.2 Priv­i­lege Esca­la­tion und Blast Radius

Ein kom­pro­mit­tiert­er Agent mit Shell-Zugriff kann erhe­blichen Schaden anricht­en: Dat­en löschen, Sys­tem lahm­le­gen, Net­zw­erk infil­tri­eren, Cre­den­tials extrahieren. Der “Blast Radius” eines Sicher­heitsvor­falls ist bei Open­Claw erhe­blich größer als bei sand­boxed SaaS-Lösun­gen.
Seg­men­tierung (eigene VMs/Container, min­i­male Berech­ti­gun­gen, Net­zw­erk­iso­la­tion) ist tech­nisch möglich, wider­spricht aber dem Con­ve­nience-Ver­sprechen von Open­Claw. Je stärk­er man absichert, desto weniger funk­tion­iert die Vision des “autonomen Agen­ten mit vollem Zugriff”.

6.3 Skill-Qual­ität und Ver­trauenskette

Die niedrige Ein­stiegshürde für Skill-Entwick­lung erzeugt ein Qual­ität­sprob­lem. Mark­down-basierte Anweisun­gen sind schw­er zu vali­dieren, zu testen oder zu ver­i­fizieren. Es gibt keine for­male Spez­i­fika­tion, keine sta­tis­che Analyse, keine stan­dar­d­isierten Tests. Die Com­mu­ni­ty-Bew­er­tun­gen auf ClawHub sind sub­jek­tiv und kön­nen manip­uliert wer­den.

Die Ver­trauenskette ist intrans­par­ent: Ein Skill kann weit­ere Skills laden, externe Ressourcen ref­eren­zieren oder dynamisch Code gener­ieren. Sup­ply-Chain-Attacks sind schw­er zu detek­tieren. Es fehlen Mech­a­nis­men wie Code-Sign­ing, Sand­box-Exe­cu­tion oder Capa­bil­i­ty-basierte Sicher­heit.

6.4 Oper­a­tionale Kom­plex­ität

Self-Host­ing bedeutet auch Self-Oper­a­tion: Updates ein­spie­len, Depen­den­cies man­a­gen, Logs überwachen, Per­for­mance opti­mieren, Fehler debuggen. Für Einzel­nutzer oder kleine Teams kann dies erhe­blichen Aufwand bedeuten. Die Ver­füg­barkeit hängt von der eige­nen Infra­struk­tur ab – kein SLA, kein pro­fes­sioneller Sup­port.

6.5 Modellab­hängigkeit und Kosten­volatil­ität

Open­Claw orchestri­ert externe Mod­elle, kon­trol­liert sie aber nicht. API-Änderun­gen, Preis­steigerun­gen, Ver­füg­barkeit­sen­g­pässe oder Pol­i­cy-Änderun­gen bei den LLM-Anbi­etern wirken sich direkt auf Open­Claw aus. Die ver­meintliche Unab­hängigkeit durch Self-Host­ing ist begren­zt, wenn man für jede Oper­a­tion externe APIs bezahlen muss.

Lokale Mod­elle (via Olla­ma) sind eine Alter­na­tive, brin­gen aber eigene Lim­i­tierun­gen: gerin­gere Qual­ität, höhere Hard­ware­an­forderun­gen, langsamere Inferenz. Der Qual­ität­sun­ter­schied zwis­chen lokalen und Fron­tier-Mod­ellen kann erhe­blich sein.

6.6 Gov­er­nance und Account­abil­i­ty

Wer ist ver­ant­wortlich, wenn ein Agent fehler­hafte Buchun­gen durch­führt, sen­si­ble Dat­en leaked oder Sys­tem-Schä­den verur­sacht? Die verteilte Architek­tur macht Account­abil­i­ty kom­plex: Liegt es am Basis-Frame­work, am ver­wen­de­ten LLM, am fehler­haften Skill, an der Kon­fig­u­ra­tion, an unklaren Anweisun­gen?

Für Unternehmen stellen sich schwierige Com­pli­ance-Fra­gen: Wie doku­men­tiert man automa­tisierte Entschei­dun­gen? Wie stellt man Audi­tier­barkeit sich­er? Wie imple­men­tiert man Approval-Work­flows für kri­tis­che Aktio­nen? Open­Claw bietet hier­für keine Stan­dard-Lösun­gen.

6.7 Skalierungs­gren­zen

Die Mes­sen­ger-basierte Steuerung ist für indi­vidu­elle Nutzung intu­itiv, skaliert aber schlecht für organ­isatorische Anwen­dungs­fälle. Wie koor­diniert man mul­ti­ple Agen­ten? Wie man­agt man Berech­ti­gun­gen im Team? Wie inte­gri­ert man mit Enter­prise-Sys­te­men (ERP, CRM, Work­flow-Man­age­ment)?

Die Architek­tur ist primär für “ein Nutzer, ein Agent” opti­miert. Mul­ti-Ten­ant-Szenar­ien, rol­len­basierte Zugriff­skon­trolle oder organ­isatorische Work­flows erfordern erhe­bliche Zusatzen­twick­lung.

7. Ver­gle­ich zu beste­hen­den Ansätzen

7.1 vs. SaaS-Chat­bots (Chat­G­PT, Claude, etc.)

SaaS-Chat­bots bieten begren­zte Funk­tion­al­ität ohne Sys­temzu­griff, dafür aber pro­fes­sionellen Betrieb, Sicher­heit­sar­chitek­tur und definierte SLAs. Open­Claw invertiert dieses Trade-off: max­i­male Funk­tion­al­ität gegen oper­a­tionale Kom­plex­ität und Sicher­heit­srisiken.

7.2 vs. Enter­prise-Automa­tisierungsplat­tfor­men (UiPath, Automa­tion Any­where, etc.)

Enter­prise-RPA-Lösun­gen bieten Gov­er­nance, Audit-Trails, zen­trale Ver­wal­tung und Sup­port. Sie sind aber teuer, kom­plex und auf definierte Work­flows beschränkt. Open­Claw ist flex­i­bler und gün­stiger, aber auch chao­tis­ch­er und riskan­ter.

7.3 vs. Cus­tom-Devel­op­ment

Eine maßgeschnei­derte Lösung bietet max­i­male Kon­trolle, erfordert aber sig­nifikante Entwick­lungsres­sourcen. Open­Claw posi­tion­iert sich als “Rapid Prototyping”-Alternative: schneller Start, gerin­gere ini­tiale Kosten, dafür aber langfristig möglicher­weise höhere Tech­ni­cal Debt.

8. Kri­tis­che Bew­er­tung und Einord­nung

8.1 Tech­nol­o­gis­che Reife

Open­Claw ist tech­nol­o­gisch noch unreif. Die tur­bu­lente Namen­shis­to­rie, die Com­mu­ni­ty-getriebene Entwick­lung ohne klare Gov­er­nance und die doku­men­tierten Sicher­heit­sprob­leme deuten auf ein Pro­jekt in früher Phase hin. Der Hype (142.000 GitHub-Stars) ste­ht in Kon­trast zur tat­säch­lichen Pro­duk­tion­sreife.

8.2 Use-Case-Fit

Für spez­i­fis­che Szenar­ien – Entwick­ler-Work­flows, Con­tent-Automa­tisierung, per­sön­liche Pro­duk­tiv­ität­stools – kann Open­Claw erhe­blichen Wert liefern. Für unternehmen­skri­tis­che Anwen­dun­gen, reg­ulierte Prozesse oder Szenar­ien mit hohen Sicher­heit­san­forderun­gen ist es aktuell nicht geeignet.

8.3 Ökonomis­che Tragfähigkeit

Die langfristige ökonomis­che Tragfähigkeit ist unklar. 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, etc.). Ob und wie Open­Claw mon­e­tarisiert wird, ist offen. Die entste­hen­den Cloud-Host­ing-Dien­ste kön­nten ein Busi­ness-Mod­el darstellen, frag­men­tieren aber möglicher­weise das Ökosys­tem.

8.4 Strate­gis­che Posi­tion­ierung

Open­Claw repräsen­tiert einen spez­i­fis­chen Architek­tu­ransatz: Self-Host­ed, LLM-agnos­tisch, Mes­sen­ger-ges­teuert, Com­mu­ni­ty-erweit­ert. Dies ist eine legit­ime Desig­nentschei­dung mit spez­i­fis­chen Trade-offs. Die Frage ist nicht, ob dieser Ansatz grund­sät­zlich funk­tion­iert, son­dern für welche Kon­texte er opti­mal ist.

9. Imp­lika­tio­nen und offene Fra­gen

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

Open­Claw ist ein inter­es­santes Exper­i­men­tier­feld für tech­nisch ver­sierte Nutzer, die bere­it sind, Sicher­heit­srisiken gegen Flex­i­bil­ität zu traden. Es eignet sich für per­sön­liche Pro­duk­tiv­ität, Pro­to­typ­ing und Explo­ration, nicht für kri­tis­che Infra­struk­tur.

9.2 Für Unternehmen

Unternehmen soll­ten Open­Claw als Research-Pro­jekt betra­cht­en: nüt­zlich, um Agent-Poten­ziale zu ver­ste­hen, aber nicht als Pro­duk­tion­slö­sung. Die Erken­nt­nisse aus Open­Claw-Exper­i­menten kön­nen in kon­trol­lierte, gov­er­nance-kon­forme Sys­teme ein­fließen.

9.3 Für die KI-Agent-Land­schaft

Open­Claw zeigt, wie schnell sich ein Ökosys­tem um ein ein­fach­es, aber mächtiges Frame­work entwick­eln kann. Die Kom­bi­na­tion aus Self-Host­ing, Mes­sen­ger-Inter­face und Com­mu­ni­ty-Skills ist ein valides Muster, das wahrschein­lich iteriert und pro­fes­sion­al­isiert wird.

9.4 Offene Fra­gen

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

• Wie lässt sich die Sicher­heit­sar­chitek­tur sub­stantiell verbessern, ohne die Flex­i­bil­ität zu opfern?
• Welche Gov­er­nance-Mech­a­nis­men sind notwendig, damit Open­Claw in organ­isatorischen Kon­tex­ten nutzbar wird?
• Wie entwick­elt sich das Ökosys­tem: Kon­so­li­dierung oder Frag­men­tierung?
• Welche reg­u­la­torischen Anforderun­gen wer­den auf autonome Agen­ten zukom­men und wie bere­it­et sich Open­Claw darauf vor?

10. Faz­it

Open­Claw ist ein tech­nol­o­gisch inter­es­santes, aber oper­a­tiv riskantes Frame­work für KI-Agen­ten. Die Stärken – Flex­i­bil­ität, Sys­temzu­griff, Com­mu­ni­ty-Ökosys­tem – sind zugle­ich die größten Schwächen aus Sicher­heits- und Gov­er­nance-Per­spek­tive.

Für tech­nisch ver­sierte Einzel­nutzer und Exper­i­men­tier­szenar­ien bietet Open­Claw erhe­blich­es Poten­zial. Für Unternehmen ist es aktuell primär als Pro­to­typ­ing-Werkzeug rel­e­vant, nicht als Pro­duk­tion­ssys­tem. Die langfristige Bedeu­tung von Open­Claw wird davon abhän­gen, ob die Com­mu­ni­ty die Sicher­heits- und Gov­er­nance-Prob­leme sys­tem­a­tisch adressiert, ohne dabei die Ein­fach­heit und Flex­i­bil­ität zu ver­lieren – ein schwieriger Bal­anceakt.

Der medi­ale Hype um einen “iPhone-Moment” für Agen­ten erscheint ver­früht. Open­Claw demon­stri­ert tech­nis­che Möglichkeit­en, aber es fehlen noch grundle­gende Bausteine für bre­ite Adop­tion jen­seits der Ear­ly-Adopter-Com­mu­ni­ty.

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/