Microsoft: nie uruchamiaj OpenClaw na zwykłych komputerach służbowych

19 lutego 2026 r. zespół Microsoft Defender Security Research Team opublikował wpis zatytułowany „Bezpieczne uruchamianie OpenClaw: tożsamość, izolacja i ryzyko środowiska uruchomieniowego”, w którym zawarł rekomendację, której Orca AI Incident Archive nie odnotowuje przy żadnym innym wpisie: OpenClaw „należy traktować jako niezaufane wykonywanie kodu z trwałymi poświadczeniami” oraz „Nie jest odpowiednie uruchamianie go na standardowej osobistej lub firmowej stacji roboczej”. OpenClaw to hostowane samodzielnie środowisko uruchomieniowe agenta — użytkownik instaluje je na własnej maszynie, przyznaje mu konta i tokeny oraz pozwala mu instalować umiejętności z publicznego rejestru i działać na podstawie tekstu, który odczyta z dowolnego miejsca. Argument Microsoftu ma charakter architektoniczny, a nie jest zgłoszeniem błędu: środowisko uruchomieniowe przenosi punkt wykonania ze statycznego kodu aplikacji na treść dostarczaną w czasie działania, a mechanizmy kontroli dotyczące tożsamości, obsługi danych wejściowych i uprawnień nie przesunęły się wraz z nim. W wpisie nie wymieniono żadnego CVE, żadnej kampanii ani żadnej ofiary i nie odnotowano żadnego naruszenia bezpieczeństwa. Pełny zapis znajduje się w Orca AI Incident Archive, gdzie sklasyfikowano go jako przełomowy wpis dotyczący polityki, z oceną pewności A i bez odnotowanych rzeczywistych szkód.

Co post powiedział, a czego nie powiedział

Wpis zajmuje około dwunastu minut czytania i nie zawiera żadnego mechanizmu ujawniania: ani identyfikatora CVE, ani zakresu podatnych wersji, ani poprawionej kompilacji, ani wskaźnika kompromitacji powiązanego z rzeczywistym wdrożeniem. Microsoft Defender Security Research wymienia Idana Hena jako współautora. Zamiast tego zawiera model zagrożeń i regułę wdrożeniową, dlatego archiwum klasyfikuje go jako zapis polityki, a nie incydent — informacje o istotności, ocena pewności A, brak odnotowanych rzeczywistych szkód, data z dokładnością do jednego dnia.

Rozumowanie zostało skompresowane do jednego akapitu otwierającego. OpenClaw „zawiera ograniczone wbudowane mechanizmy kontroli bezpieczeństwa” – pisze zespół – ponieważ środowisko uruchomieniowe „może przyjmować niezaufany tekst, pobierać i wykonywać umiejętności (czyli kod) ze źródeł zewnętrznych oraz wykonywać działania przy użyciu przypisanych mu poświadczeń”. Konsekwencja jest wyrażona w tym samym zdaniu: to „skutecznie przenosi granicę wykonania ze statycznego kodu aplikacji na dynamicznie dostarczaną treść i możliwości stron trzecich, bez równoważnych kontroli w zakresie tożsamości, obsługi danych wejściowych lub ograniczania uprawnień”.

Poniżej przedstawiono trzy ryzyka — warto je przeczytać słowami samego Microsoftu, ponieważ większość późniejszych relacji sparafrazowała je, czyniąc je niejasnymi:

• „Poświadczenia i dostępne dane mogą zostać ujawnione lub wykradzione."

• „Trwały stan agenta lub jego »pamięć« mogą zostać zmodyfikowane, w wyniku czego z czasem zaczyna on wykonywać instrukcje dostarczone przez atakującego."

• „Środowisko hosta może zostać naruszone, jeśli agent zostanie nakłoniony do pobrania i wykonania złośliwego kodu.”

Zauważ, czego na tej liście nie ma. Nie ma wykorzystanej luki, nie ma podatnej funkcji, nie ma poprawki do wdrożenia. Microsoft nie twierdzi, że OpenClaw ma błąd bezpieczeństwa; twierdzi, że programu, który decyduje, co robić w czasie działania, na podstawie pobranego tekstu, przy użyciu przekazanych mu poświadczeń, nie da się zabezpieczyć konfiguracją na maszynie, na której znajduje się również rzeczywista praca operatora. Wynikające z tego zalecenie jest odpowiednio dosadne — w większości środowisk „właściwą decyzją może być jego niewdrożenie”.

Dwa łańcuchy dostaw, jedna pętla realizacji

Mechanizm opisany w poście to zbieżność tego, co nazywa on dwoma łańcuchami dostaw agenta hostowanego samodzielnie: niezaufanego kodu, czyli umiejętności i rozszerzeń, oraz niezaufanych instrukcji, czyli tekstu zewnętrznego. Większość oprogramowania ma jedno albo drugie. Menedżer pakietów pobiera niezaufany kod, ale nie czyta internetu i nie decyduje, co uruchomić dalej; model czatu czyta niezaufany tekst, ale nie może niczego zainstalować. OpenClaw robi jedno i drugie w jednej pętli, a pętla działa w ramach tożsamości samego użytkownika.

„Zainstalowanie umiejętności to w zasadzie instalacja kodu z uprawnieniami” – czytamy we wpisie. Umiejętności są „często odkrywane i instalowane przez ClawHub, publiczny rejestr umiejętności dla OpenClaw”, a w permisywnych wdrożeniach „środowisko uruchomieniowe może mieć pozwolenie na wykonanie procesu instalacji bez zatwierdzenia przez człowieka”. Drugim łańcuchem dostaw zarządza Moltbook, który wpis opisuje jako platformę i warstwę tożsamości skoncentrowaną na agentach, gdzie agenci publikują, czytają i uwierzytelniają się przez API — a zatem, jak to ujęto, „strumień treści w dużym wolumenie, na który mogą wpływać atakujący, a który agenci przyswajają według harmonogramu”. Istotą jest kompresja: „Pojedynczy złośliwy wpis może zatem dotrzeć do wielu agentów”.

Wpis dzieli następnie granicę zaufania na trzy komponenty, co jest najbardziej nadającą się do ponownego wykorzystania częścią całego dokumentu: tożsamość, czyli tokeny, których agent używa do pracy w interfejsach API SaaS, repozytoriach, poczcie i płaszczyznach sterowania chmurą; wykonywanie, czyli narzędzia, które może uruchamiać i które zmieniają stan, w tym pliki, powłokę, infrastrukturę i wiadomości; oraz trwałość, czyli sposoby, w jakie może zachowywać zmiany między uruchomieniami, poprzez zadania, konfigurację i harmonogramy. Agent, który ma wszystkie trzy, nie jest aplikacją z monitem o uprawnienia. Jest podmiotem.

Zatruta umiejętność, w pięciu etapach

Microsoft dostarcza jeden opracowany łańcuch kompromitacji, oznaczony jako scenariusz reprezentatywny, a nie opis przypadku, i warto go prześledzić, ponieważ jego dwa ostatnie kroki to te, które pokonują zwykłe zabezpieczenia punktów końcowych. Wpis poprzedza go twierdzeniem o świecie zewnętrznym — „{{1}}Publiczne doniesienia udokumentowały złośliwe umiejętności pojawiające się w publicznych rejestrach{{/1}}”, a w niektórych przypadkach „{{2}}zawartość rejestru była po prostu złośliwym oprogramowaniem zapakowanym jako umiejętność, a nie subtelną imitacją{{/2}}” — ale nie podaje żadnego wpisu w rejestrze, kampanii, aktora ani ofiary, więc łańcuch pozostaje argumentem na rzecz wiarygodności, a nie rekonstrukcją.

• Dystrybucja. Atakujący publikuje złośliwą umiejętność w ClawHub — czasem ukrytą jako narzędzie użytkowe, a czasem jawnie złośliwą — i promuje ją za pośrednictwem kanałów społecznościowych; innym razem zostaje ona znaleziona organicznie poprzez wyszukiwanie i zainstalowana, ponieważ instalacja jest prosta i nie wymaga wiele wysiłku.

• Instalacja. Programista lub sam agent rozpoczyna instalację, ponieważ dana umiejętność wydaje się istotna dla zadania. W przypadku wdrożenia o permisywnych ustawieniach żaden człowiek jej nie zatwierdza.

• Dostęp do stanu. Napastnik poluje na tokeny, buforowane poświadczenia, dane konfiguracyjne i transkrypcje, a także trwałe kanały instrukcji — pliki zadań, zaplanowane działania, konfigurację agenta — które sterują przyszłymi uruchomieniami.

• Ponowne wykorzystanie uprawnień. Dysponując ważnymi danymi tożsamościowymi, atakujący działa za pośrednictwem standardowych interfejsów API i narzędzi, a jego aktywność „często przypomina legalną automatyzację, o ile nie wdrożono silnych mechanizmów monitorowania i rejestrowania”.

• Trwałość poprzez konfigurację. To, co pozostaje, to trwała zmiana konfiguracji: „nowe zgody OAuth, zaplanowane wykonania, zmodyfikowane zadania agenta lub narzędzia, które pozostają trwale zatwierdzone”.

Piąty krok zawiera najostrzejsze zdanie w poście i to, które najlepiej wyjaśnia, dlaczego jest to problem polityki, a nie problem złośliwego oprogramowania: „Celem jest w mniejszym stopniu wdrażanie złośliwego oprogramowania, a w większym utrzymanie długoterminowej kontroli nad ścieżką automatyzacji”. Narzędzia bezpieczeństwa, które szukają ładunku, nic nie znajdą. To, co musiałyby wychwycić, to udzielenie zgody, wpis w cronie lub narzędzie, które po cichu pozostawiono zatwierdzone.

Minimalna postawa, którą Microsoft zaakceptuje

Microsoft nie pozostawia czytelnika z „nie rób tego”. Zapewnia minimalny standard organizacjom, które mimo wszystko zdecydują się ocenić środowisko uruchomieniowe, a ten standard jest surowszy niż sandbox. Środowisko powinno być „dedykowaną maszyną wirtualną lub osobnym urządzeniem fizycznym, które nie jest używane do codziennej pracy” i należy je traktować jako jednorazowe. Poświadczenia powinny być tworzone wyłącznie do celów agenta, bez uprawnień uprzywilejowanych, i rotowane przy założeniu, że zostały już skompromitowane. Dostępne powinny być tylko dane niepoufne. Zapisane instrukcje i stan agenta należy regularnie przeglądać pod kątem nieoczekiwanych trwałych reguł, nowo zaufanych źródeł lub zachowań zmieniających się między uruchomieniami. A przebudowa powinna być oczekiwaną kontrolą, a nie sytuacją awaryjną: regularnie przeprowadzaj ponowną instalację i natychmiast przebudowuj w przypadku nietypowego zachowania.

Jedna informacja w poście jest bardziej przydatna, niż sugeruje jej długość. Tworzenie kopii zapasowej .openclaw/workspace/ obejmuje stan roboczy agenta bez uwzględniania danych uwierzytelniających; tworzenie kopii zapasowej całego katalogu .openclaw/ jest prostsze do przywrócenia, ale obejmuje również tokeny i dane uwierzytelniające, a post ostrzega, że może to być niewłaściwe, jeśli podejrzewa się, że dane uwierzytelniające zostały skompromitowane. Zespół, który tworzy kopię zapasową całego katalogu i nazywa to odtwarzaniem po awarii, zarchiwizował to, czego chciał atakujący.

Przewodnik jest również mapą produktu

Druga połowa wpisu przypisuje każdą zalecaną kontrolę do produktu Microsoft: Microsoft Entra ID w przypadku zasady najmniejszych uprawnień i dostępu warunkowego dla tożsamości agentów, Microsoft Defender for Cloud Apps App Governance w przypadku inwentaryzacji OAuth i dryfu zgód, Microsoft Defender for Endpoint dla hosta agenta, Microsoft Defender XDR do korelacji, Microsoft Purview do zapobiegania utracie danych na punktach końcowych, Microsoft Defender for Cloud do ruchu wychodzącego sieci oraz Microsoft Sentinel tam, gdzie potrzebne jest dłuższe przechowywanie lub automatyzacja. To zwyczajowa praktyka w blogu bezpieczeństwa dostawcy i warto też nazwać to wprost: dokument zalecający izolowanie środowiska uruchomieniowego agenta firmy trzeciej jest publikowany przez firmę, która sprzedaje tę izolację.

Treść dotycząca huntingu to ta część, która broni się w tym ujęciu, ponieważ jest konkretna. Wpis dostarcza zapytania KQL względem tabel Defender XDR — DeviceProcessEvents, CloudProcessEvents, DeviceFileEvents, DeviceNetworkEvents i OAuthAppInfo — które wyszukują wiersze poleceń procesów i nazwy plików zawierające "openclaw", "moltbot" lub "clawdbot", a także wywołaniaclawhub install z rzadkimi slugami umiejętności, rotację folderów rozszerzeń na endpointach deweloperskich, nowe aplikacje OAuth o wysokich uprawnieniach, usługi nasłuchujące otwierane przez procesy agentów oraz środowiska uruchomieniowe agentów uruchamiające cmd.exe, powershell.exe, pwsh.exe, bash, sh, curl lub wget. Niezależnie od tego, co się sądzi o mapowaniu produktu, te zapytania może uruchomić każdy klient Defender XDR w dniu publikacji i nie zakładają one wcześniejszej wiedzy o tym, które hosty uruchamiają to środowisko uruchomieniowe.

Co jest ustalone, a co nie

Ustalono i potwierdzono: Microsoft opublikował ten wpis 19 lutego 2026 r., a powyższe cytaty pochodzą z niego. Cybernews poinformował o tym ostrzeżeniu 23 lutego 2026 r., a TechRadar 24 lutego 2026 r.; oba serwisy powtórzyły dwa kluczowe zdania i wytyczne dotyczące izolacji, zamiast je przetestować. Powtarzane wyszukiwania nie ujawniły omówień w The Register, BleepingComputer, Wired ani TechCrunch, więc fala prasowa wokół tego wpisu była niewielka i wtórna; żadna niezależna strona nie opublikowała testu twierdzenia architektonicznego Microsoftu, a dostępne potwierdzenia potwierdzają to, co powiedział Microsoft, a nie to, czy ma rację.

Przekaz wprowadził też błąd wart odnotowania, ponieważ pokazuje, jak szybko ostrzeżenie dostawcy o narzędziu firmy trzeciej staje się ostrzeżeniem dostawcy o jego własnym. Raport Cybernews zaczyna się od opisania OpenClaw jako „asystenta AI Microsoftu”; tak jednak nie jest. OpenClaw to samodzielnie hostowane środowisko uruchomieniowe, które zbadali badacze Microsoft Defender, a sam wpis strukturalnie wprowadza rozróżnienie, przeciwstawiając samodzielnie hostowane środowiska uruchomieniowe — w których „odpowiadasz za promień rażenia”, a host, wtyczki i stan lokalny znajdują się w granicach zaufania — zarządzanym asystentom i platformom agentowym, w których środowisko uruchomieniowe i aktualizacje są zarządzane centralnie, a mechanizmy kontroli koncentrują się na zakresach tożsamości, zarządzaniu konektorami i granicach danych.

Nie ustalono: że jakakolwiek konkretna organizacja została naruszona w sposób opisany we wpisie. Microsoft twierdzi, że publiczne raporty udokumentowały złośliwe umiejętności w publicznych rejestrach, ale wpis nie podaje nazwy kampanii, liczby, daty ani ofiary, a zatem ten zapis nie niesie ze sobą rzeczywistej szkody. Rekomendacja również nie jest wiążąca. Żaden regulator jej nie wydał, żaden organ normalizacyjny jej nie przyjął i nic w zapisie nie wskazuje, by klient, audytor lub ubezpieczyciel traktował ją jako wymóg. To opinia dostawcy o tym, jak jego własni klienci powinni traktować narzędzie, którego nie kontroluje — nietypowo kategoryczna i nieegzekwowalna.

To, co ten wpis jednak zmienia, to kształt pytania, na które musi odpowiedzieć zespół ds. bezpieczeństwa. Przed 19 lutego 2026 r. decyzję o uruchomieniu OpenClaw na służbowym laptopie można było uzasadniać jako kwestię konfiguracji i zatwierdzenia pilotażu. Po nim argumentację trzeba oprzeć na dokumencie, który stwierdza, że to sam projekt środowiska uruchomieniowego, a nie jego ustawienia, naraża maszynę na ryzyko — i który nie oferuje żadnej wersji do aktualizacji, żadnej łatki do zastosowania ani żadnej poprawki w planie rozwoju. Jego rozwiązaniem jest wzorzec wdrożenia: odizolować środowisko uruchomieniowe, ograniczyć to, do czego ma dostęp, stale je monitorować i być gotowym na natychmiastowe odtworzenie.