Microsoft: kör inte OpenClaw på vanliga arbetsdatorer

Den 19 februari 2026 publicerade Microsoft Defender Security Research Team ett inlägg med titeln "Att köra OpenClaw säkert: identitet, isolering och runtime-risk", och i det gjorde man en rekommendation som Orca AI Incident Archive inte registrerar för någon annan post: OpenClaw "bör behandlas som otillförlitlig kodkörning med beständiga autentiseringsuppgifter", och "Det är inte lämpligt att köra på en vanlig personlig eller företagsarbetsstation." OpenClaw är en självhostad agent-runtime — användaren installerar den på sin egen maskin, ger den konton och token och låter den installera skills från ett offentligt register och agera utifrån text den läser varifrån som helst. Microsofts argument är arkitektoniskt, inte en buggrapport: körningsmiljön flyttar körningspunkten från statisk applikationskod till innehåll som tillhandahålls vid körning, och kontrollerna kring identitet, indatahantering och behörighet har inte flyttats med. Inlägget namnger ingen CVE, ingen kampanj och inget offer, och registrerar ingen kompromettering. Hela posten finns i Orca AI Incident Archive, där den klassificeras som en policy-post av milstolpekaraktär med konfidensgrad A och ingen registrerad verklig skada.

Vad inlägget sa, och vad det inte sa

Inlägget tar ungefär tolv minuter att läsa och innehåller ingen avslöjandemekanism alls: ingen CVE-identifierare, inget intervall för drabbade versioner, ingen åtgärdad build, ingen kompromissindikator kopplad till en verklig driftsättning. Microsoft Defender Security Research listar Idan Hen som bidragsgivare. Det som det i stället innehåller är en hotmodell och en driftsättningsregel, vilket är anledningen till att arkivet registrerar det som en policy-post snarare än en incident – allvarlighetsinformation, konfidensgrad A, ingen dokumenterad verklig skada, ett datum med enbart dags precision.

Resonemanget komprimeras till ett inledande stycke. OpenClaw "har begränsade inbyggda säkerhetskontroller", skriver teamet, eftersom körmiljön "kan ta in otillförlitlig text, ladda ner och köra skills (dvs. kod) från externa källor och utföra åtgärder med de autentiseringsuppgifter som tilldelats den." Konsekvensen sägs i samma andetag: detta "flyttar i praktiken exekveringsgränsen från statisk applikationskod till dynamiskt tillhandahållet innehåll och tredjepartsfunktioner, utan motsvarande kontroller kring identitet, indatahantering eller behörighetsavgränsning."

Tre risker följer, och de är värda att läsa i Microsofts egna ord, eftersom större delen av rapporteringen som följde omformulerade dem till något vagt:

• "Inloggningsuppgifter och åtkomliga data kan exponeras eller exfiltreras."

• "Agentens beständiga tillstånd eller 'minne' kan ändras, vilket gör att den över tid följer instruktioner som angriparen tillhandahållit."

• "Värdmiljön kan komprometteras om agenten förmås att hämta och köra skadlig kod."

Notera vad som saknas i den listan. Det finns ingen utnyttjad brist, ingen sårbar funktion, ingen patch att leverera. Microsoft säger inte att OpenClaw har en säkerhetsbugg; de säger att ett program som avgör vad det ska göra vid körtid, utifrån text det har hämtat, med hjälp av autentiseringsuppgifter det har fått, inte kan göras säkert genom konfiguration på en maskin som också innehåller operatörens verkliga arbete. Rekommendationen som följer är motsvarande rakt på sak – för de flesta miljöer "kan det lämpliga beslutet vara att inte distribuera det."

Två försörjningskedjor, en körningsslinga

Mekanismen som inlägget beskriver är sammansmältningen av det som det kallar de två leveranskedjorna för en självhostad agent: otillförlitlig kod, det vill säga skills och tillägg, och otillförlitliga instruktioner, det vill säga extern text. De flesta programvaror har det ena eller det andra. En pakethanterare hämtar otillförlitlig kod men läser inte internet och bestämmer vad som ska köras härnäst; en chattmodell läser otillförlitlig text men kan inte installera något. OpenClaw gör båda i en enda loop, och loopen körs under användarens egen identitet.

"Att installera en färdighet är i princip att installera privilegierad kod", står det i inlägget. Färdigheter "upptäcks och installeras ofta via ClawHub, det offentliga färdighetsregistret för OpenClaw", och i tillåtande distributioner "kan körmiljön tillåtas att köra installationsflödet utan mänskligt godkännande." Den andra leveranskedjan hanteras av Moltbook, som inlägget beskriver som en agentfokuserad plattform och ett identitetslager där agenter publicerar, läser och autentiserar via API:er – och därför, enligt dess formulering, "en högvolymsström av innehåll som angripare kan påverka och som agenter tar in enligt ett schema." Komprimeringen är poängen: "Ett enda skadligt inlägg kan därför nå flera agenter."

Inlägget delar sedan upp betroendegränsen i tre komponenter, vilket är den mest återanvändbara delen av hela dokumentet: identitet, det vill säga de tokens som agenten använder för att utföra arbete över SaaS-API:er, kodförråd, e-post och molnkontrollplan; utförande, det vill säga de verktyg den kan köra som ändrar tillstånd, inklusive filer, skal, infrastruktur och meddelanden; och beständighet, det vill säga de sätt på vilka den kan behålla ändringar mellan körningar, genom uppgifter, konfiguration och scheman. En agent som har alla tre är inte en applikation med en behörighetsdialog. Den är en principal.

Den förgiftade färdigheten, i fem steg

Microsoft tillhandahåller en genomarbetad kompromisskedja, märkt som ett representativt scenario snarare än en fallrapport, och den är värd att gå igenom eftersom de två sista stegen är de som besegrar vanliga slutpunktsförsvar. Inlägget inleder den med ett påstående om omvärlden – "Offentlig rapportering har dokumenterat att skadliga skills förekommer i offentliga register", och i vissa fall "har registerinnehåll varit renodlad skadlig kod paketerad som en skill, snarare än en subtil imitation" – men namnger ingen registerpost, kampanj, aktör eller offer, så kedjan står som ett rimlighetsargument, inte som en rekonstruktion.

• Distribution. En angripare publicerar en skadlig skill på ClawHub, ibland förklädd till ett verktyg och ibland öppet skadlig, och marknadsför den via communitykanaler; andra gånger hittas den organiskt via sökning och installeras eftersom installationen är enkel.

• Installation. En utvecklare eller agenten själv startar installationen eftersom färdigheten verkar relevant för uppgiften. I en tillåtande distribution godkänner ingen människa den.

• Tillståndsåtkomst. Angriparen går efter token, cachelagrade autentiseringsuppgifter, konfigurationsdata och transkript, plus de beständiga instruktionskanalerna – uppgiftsfiler, schemalagda åtgärder, agentkonfiguration – som styr framtida körningar.

• Återanvändning av privilegier. Med giltigt identitetsmaterial agerar angriparen via standard-API:er och verktyg, och aktiviteten "liknar ofta legitim automatisering om inte starka övervaknings- och loggningskontroller finns på plats."

• Beständighet genom konfiguration. Det som återstår är varaktig konfigurationsändring: "nya OAuth-medgivanden, schemalagda körningar, ändrade agentuppgifter eller verktyg som förblir permanent godkända."

Det femte steget innehåller inläggets skarpaste mening, och den som bäst förklarar varför detta är ett policyproblem snarare än ett malwareproblem: "Målet handlar mindre om att distribuera malware och mer om att upprätthålla långsiktig kontroll över automatiseringsvägen." Säkerhetsverktyg som letar efter en nyttolast hittar ingenting. Det de skulle behöva fånga är ett samtyckesgodkännande, en cron-post eller ett verktyg som tyst lämnats godkänt.

Den lägsta hållning som Microsoft kommer att acceptera

Microsoft lämnar inte läsaren med "gör inte". Det tillhandahåller en miniminivå för organisationer som ändå beslutar sig för att utvärdera körtiden, och miniminivån är strängare än en sandlåda. Miljön bör vara "en dedikerad virtuell maskin eller en separat fysisk enhet som inte används för dagligt arbete", och den bör behandlas som engångsartikel. Autentiseringsuppgifter bör skapas enbart för agentens syfte, vara icke-privilegierade och roteras utifrån antagandet att de redan är komprometterade. Endast icke-känsliga data bör vara åtkomliga. Agentens sparade instruktioner och tillstånd bör granskas regelbundet för oväntade beständiga regler, källor som nyligen har betrotts eller beteende som förändras mellan körningar. Och en ombyggnad bör vara en förväntad kontroll snarare än en nödsituation: installera om regelbundet och bygg om omedelbart vid avvikande beteende.

En detalj i inlägget är mer användbar än dess längd antyder. Att säkerhetskopiera .openclaw/workspace/ fångar agentens arbetstillstånd utan att inkludera autentiseringsuppgifter; att säkerhetskopiera hela .openclaw/ katalogen är enklare att återställa men fångar också tokens och autentiseringsuppgifter, och inlägget varnar för att det kan vara olämpligt om man misstänker att autentiseringsuppgifterna är komprometterade. Ett team som säkerhetskopierar hela katalogen och kallar det katastrofåterställning har arkiverat det angriparen ville ha.

Vägledningen är också en produktkarta

Den andra halvan av inlägget kopplar varje rekommenderad kontroll till en Microsoft-produkt: Microsoft Entra ID för minsta behörighet och villkorlig åtkomst för agentidentiteter, Microsoft Defender for Cloud Apps App Governance för OAuth-inventering och samtyckesavvikelser, Microsoft Defender for Endpoint för agentvärden, Microsoft Defender XDR för korrelation, Microsoft Purview för dataförlustskydd på slutpunkter, Microsoft Defender for Cloud för nätverksutgång och Microsoft Sentinel där längre kvarhållning eller automatisering behövs. Det är sedvanlig praxis för en säkerhetsblogg från en leverantör, och det är också värt att säga rakt ut: dokumentet som rekommenderar att en tredjeparts agentruntime ska begränsas publiceras av ett företag som säljer begränsningen.

Jaktinnehållet är den del som överlever den inramningen, eftersom det är specifikt. Inlägget tillhandahåller KQL-frågor mot Defender XDR-tabellerna DeviceProcessEvents, CloudProcessEvents, DeviceFileEvents, DeviceNetworkEvents och OAuthAppInfo som söker efter processkommandorader och filnamn som innehåller "openclaw", "moltbot" eller "clawdbot", efter anrop av clawhub install med sällsynta skill-sluggar, efter ändringar i tilläggsmappar på utvecklarslutpunkter, efter nya OAuth-program med hög behörighet, efter lyssnande tjänster som öppnats av agentprocesser och efter agent-runtimes som startar cmd.exe, powershell.exe, pwsh.exe, bash, sh, curl eller wget. Vad man än tycker om produktmappningen kan dessa frågor köras av alla Defender XDR-kunder på publiceringsdagen, och de förutsätter ingen förhandskännedom om vilka värdar som kör runtimemiljön.

Vad som är fastställt, och vad som inte är det

Fastställt och styrkt: Microsoft publicerade inlägget den 19 februari 2026, och citaten ovan är därifrån. Cybernews rapporterade om varningen den 23 februari 2026 och TechRadar den 24 februari 2026, och båda upprepade de två centrala meningarna och isoleringsvägledningen i stället för att testa dem. Upprepade sökningar hittade ingen rapportering i The Register, BleepingComputer, Wired eller TechCrunch, så pressvågen kring detta inlägg var liten och sekundär; ingen oberoende part har publicerat ett test av Microsofts arkitektoniska påstående, och den tillgängliga bekräftelsen bekräftar vad Microsoft sade, inte om det stämmer.

Reläet introducerade också ett fel som är värt att uppmärksamma, eftersom det visar hur snabbt en leverantörsvarning om ett tredjepartsverktyg blir en leverantörsvarning om dess eget. Cybernews rapport inleds med att beskriva OpenClaw som "Microsofts AI-assistent"; det är det inte. OpenClaw är en självhostad runtime som Microsofts Defender-forskare undersökte, och inlägget självt drar skillnaden strukturellt genom att kontrastera självhostade runtimes – där "du ansvarar för skadeomfånget" och värden, plugin och lokalt tillstånd alla ligger innanför förtroendegränsen – mot hanterade assistenter och agentplattformar, där runtimemiljön och uppdateringarna hanteras centralt och kontrollerna kretsar kring identitetsomfång, connector-styrning och datagränser.

Inte fastställt: att någon specifik organisation har komprometterats på det sätt som inlägget beskriver. Microsoft hävdar att offentlig rapportering har dokumenterat skadliga skills i offentliga register, men inlägget anger inget kampanjnamn, inget antal, inget datum och inget offer, och detta underlag innebär därför ingen verklig skada. Inte heller är rekommendationen bindande. Ingen tillsynsmyndighet har utfärdat den, inget standardiseringsorgan har antagit den, och inget i underlaget visar att en kund, revisor eller försäkringsgivare behandlar den som ett krav. Det är en leverantörs åsikt om hur dess egna kunder bör behandla ett verktyg som leverantören inte kontrollerar – ovanligt kategorisk och inte verkställbar.

Det som inlägget faktiskt förändrar är formen på den fråga som ett säkerhetsteam måste besvara. Före den 19 februari 2026 kunde beslutet att köra OpenClaw på en arbetslaptop argumenteras som en fråga om konfiguration och godkännande av pilotprojekt. Efter det måste argumentet föras mot ett dokument som säger att det är körtidens egen design, inte dess inställningar, som utsätter maskinen för risk — och som inte erbjuder någon version att uppgradera till, någon patch att applicera och ingen fix på färdplanen. Dess botemedel är ett driftsättningsmönster: isolera körtiden, begränsa vad den kan nå, övervaka den kontinuerligt och var beredd att bygga om utan dröjsmål.