,

ZeroLeaks testuje OpenClaw: ocena 2/100 i podatności AI

Automatyczny audyt narzędzia ZeroLeaks przyznał frameworkowi OpenClaw ocenę bezpieczeństwa 2/100 oraz krytyczny poziom ryzyka 10/10, wykazując 91% skuteczności wstrzykiwania poleceń. Niezależna weryfikacja kodu źródłowego wykazała jednak zero realnych podatności, gdyż skanował on publiczny kod z serwisu GitHub i pominął wewnętrzne warstwy ochronne. Badania nad odpornością LLM potwierdzają, że jedynym skutecznym zabezpieczeniem przed wyciekiem instrukcji pozostaje deterministyczne filtrowanie wyjścia w kodzie aplikacji z 0% wskaźnikiem wycieków.

Mechanizm skanowania ZeroLeaks i wyniki audytu OpenClaw

Automatyczne skanowanie bezpieczeństwa agentów AI staje się standardowym elementem weryfikacji architektury systemów opartych na dużych modelach językowych. Narzędzie ZeroLeaks przeprowadza testy podatności na wstrzykiwanie poleceń oraz wycieki instrukcji systemowych, wykorzystując wieloagentowy silnik do adaptacyjnych ataków w czasie rzeczywistym. Analiza frameworku OpenClaw wykazała jednak istotne rozbieżności między wynikami skanera a realnym ryzykiem eksploatacyjnym kodu.

Platforma ZeroLeaks opiera swoje działanie na metodologii TAP (Tree of Attacks with Pruning), wykorzystując cztery wyspecjalizowane role agentowe: Strategist (planowanie ścieżek), Attacker (generowanie sond), Evaluator (klasyfikacja wycieków) oraz Mutator (przepisywanie odrzuconych zapytań). Skaner klasyfikuje głębokość wycieku w skali od L0 (bezpieczny) do L4 (pełna ekstrakcja). Testy można uruchamiać z poziomu panelu, jako bramki weryfikacyjne w GitHub PR lub poprzez kompilację pakietu @zeroleaks/sdk w środowisku produkcyjnym. Licencjonowanie narzędzia obejmuje plany od \$79/miesiąc (Pro) i \$99/stanowisko/miesiąc (Team) do \$999/miesiąc (Business) lub cenę początkową \$499/miesiąc w katalogach oprogramowania.

W styczniu 2026 roku inżynier Lucas Valbuena przeprowadził automatyczny audyt frameworku OpenClaw (znanego wcześniej pod nazwami Clawdbot oraz Moltbot) przy użyciu narzędzia ZeroLeaks. Raport z badania przypisał projektowi skrajne parametry podatności:

  • Ogólny wskaźnik bezpieczeństwa (Overall Security Score): 2/100
  • Poziom ryzyka krytycznego (Critical Risk Score): 10/10 (ZLSS Score 10/10)
  • Skuteczność ekstrakcji promptu systemowego: 84% (11 z 13 prób zakończonych sukcesem)
  • Skuteczność wstrzykiwania poleceń (Prompt Injection): 91% (21 z 23 prób zakończonych sukcesem)

Skaner odczytał pliki konfiguracyjne agenta, w tym SOUL.md, AGENTS.md oraz definicje zainstalowanych umiejętności i pamięci. Taki wynik zasugerował całkowity brak granicy między publicznymi danymi wejściowymi a wewnętrznymi zasobami systemu.

Czy audyt ZeroLeaks uzasadnia ocenę 2/100 dla OpenClaw?

Ocena bezpieczeństwa na poziomie 2/100 przyznana OpenClaw przez ZeroLeaks wywołała dyskusję na temat metodologii automatycznych audytów AI. Niezależna weryfikacja przeprowadzona przez trzy modele AI wykazała brak zademonstrowanych podatności eksploatacyjnych w kodzie źródłowym. Różnica wynika z faktu, że skaner zinterpretował publicznie dostępny kod z serwisu GitHub jako wyciek poufnych danych.

Szczegółowa ocena kodu źródłowego wykonana przez trzy niezależne ewaluatory — Opus 4.6, Codex GPT-5.3 od OpenAI oraz subagenta Code-Searcher — wykazała 0 zademonstrowanych podatności możliwych do wykorzystania. Wnioski z audytu ZeroLeaks okazały się błędne z czterech przyczyn technicznych:

  1. Jawność kodu źródłowego: OpenClaw jest oprogramowaniem open-source wydawanym na licencji MIT. Wszystkie sekcje promptu systemowego generowane przez funkcję buildAgentSystemPrompt() w pliku src/agents/system-prompt.ts oraz stałe z src/auto-reply/tokens.ts są publicznie dostępne w repozytorium GitHub. Ich odczytanie przez model nie stanowi wycieku tajemnicy handlowej ani naruszenia bezpieczeństwa.
  2. Błędne zaklasyfikowanie instrukcji użytkownika: 9 z 23 testów wstrzyknięć (Kategoria A) polegało na wydaniu agentowi bezpośredniego polecenia zmiany formatu odpowiedzi (np. wymuszenie języka hiszpańskiego lub formatu JSON). Dla osobistego asystenta AI, gdzie użytkownik jest operatorem systemu, realizacja takich poleceń jest celowym działaniem oprogramowania, a nie podatnością.
  3. Pominięcie rzeczywistej warstwy ochronnej: Testy pośredniego wstrzykiwania poleceń (Kategoria B, testy 11-13) przesyłano jako bezpośrednie wiadomości użytkownika. Ominięto w ten sposób moduł src/security/external-content.ts, który automatycznie izoluje treść z zewnętrznych stron www, wiadomości e-mail oraz kanałów Discord i Slack za pomocą znaczników <<>>.
  4. Niezgodność z zakresem bezpieczeństwa: Plik SECURITY.md w repozytorium OpenClaw wprost definiuje bezpośrednie wstrzykiwanie poleceń jako wątek poza zakresem (out of scope), traktując użytkownika jako podmiot zarządzający.
Metryka / Parametr Audyt ZeroLeaks Weryfikacja kodu źródłowego
Krytyczne podatności 10/10 (ZLSS Score) 0 podatności eksploatacyjnych
Wyciek promptu systemowego 84% sukcesu (11/13) Kod publiczny w src/agents/system-prompt.ts
Wstrzyknięcia poleceń 91% sukcesu (21/23) Instrukcje operatora / pominięcie filtrów
Testowana warstwa obrony Wiadomości bezpośrednie Pominął src/security/external-content.ts

Ryzyka agentów AI i porównanie skuteczności zabezpieczeń

Wdrożenie agentów AI z dostępem do powłoki systemowej i zasobów lokalnych niesie konkretne ryzyka operacyjne w przypadku przejęcia kontroli nad modelem. Badania naukowe nad skutecznością zabezpieczeń LLM pokazują, że metody oparte na samym modelu ulegają przełamaniu pod wpływem adaptacyjnego ataku. Jedyną trwałą barierą techniczną okazuje się deterministyczne weryfikowanie odpowiedzi na poziomie kodu aplikacji.

Zgłoszone ryzyka wokół OpenClaw wynikają ze skrajnych uprawnień nadawanych agentom, obejmujących dostęp do powłoki bash, systemu plików oraz portfeli kryptowalutowych. W sklepie ClawHub zidentyfikowano ponad 400 zainfekowanych umiejętności (malware-infected skills), w tym popularne dodatki wyłudzające poświadczenia. Dodatkowo incydent w sieci agentów Moltbook doprowadził do ujawnienia 1,5 mln tokenów API, w tym otwartych kluczy OpenAI.

Zależności te potwierdzają badania naukowców z Swept AI oraz University of Michigan (Deep i in., kwiecień 2026), którzy przeanalizowali 9 konfiguracji obronnych w ponad 20 000 ataków adaptacyjnych:

  • Zabezpieczenia oparte na modelu: Metody takie jak dyrektywy bezpieczeństwa (t1), ograniczniki XML (t3), hierarchia instrukcji (t4) czy architektura sandwich (t6) ulegały całkowitemu przełamaniu w czasie od 39 do 277 rund ataku (osiągając poziom wycieku ≥0.9).
  • Filtrowanie wejścia (Input Sanitization, t2): Połączenie reguł regex z klasyfikatorem LLM uległo przełamaniu po 39 rundach z powodu nieograniczonej przestrzeni możliwych sformułowań ataku.
  • Filtrowanie wyjścia (Output Filtering, t5 i t7): Sprawdzanie odpowiedzi modelu w kodzie aplikacji za pomocą reguł ciągów tekstowych zachowało wskaźnik wycieków na poziomie 0% w ciągu 15 000 testowych ataków.

Deterministyczne filtrowanie wyjścia działa skutecznie, ponieważ operuje na skończonym i zdefiniowanym zbiorze wartości tajnych, niezależnie od tego, jakimi metodami model został przekonany do złamania instrukcji.

Podatność modeli LLM i koszty wycieków w architekturze korporacyjnej

Brak odporności komercyjnych modeli LLM na zaawansowane wstrzykiwanie poleceń wymusza zmianę podejścia do architektury bezpieczeństwa w przedsiębiorstwach. Weryfikacja wbudowanych filtrów ochronnych w wiodących modelach pokazuje ich podatność na wyciek tajnych danych w ciągu pierwszych kilkudziesięciu rund ataku. Organizacje łączą ramy ISO 27001 z ISO 42001, aby zapewnić nadzór nad cyklem życia sztucznej inteligencji.

Testy odporności domyślnych zabezpieczeń na modelu bazowym bez dodatkowych filtrów (t0) przeprowadzone na wiodących silnikach językowych wykazały ułomność samoregulacji modeli:

  • Gemini 2.5 Pro: Pełny wyciek tajnych danych (wynik 1.00) w 10 rundach.
  • GPT-5.4: Pełny wyciek tajnych danych (wynik 1.00) w 10 rundach.
  • Claude Sonnet 4.6: Wyciek wszystkich 3 kluczy (wynik 0.90) osiągnięty w 300 rundach.

Według raportów SentinelOne jedynie 4% przedsiębiorstw deklaruje pewność swoich zabezpieczeń przed cyberzagrożeniami w obszarze połączonych urządzeń, podczas gdy 75% konsumentów domaga się jasnych zasad przetwarzania danych. Brak cyklicznych audytów naraża firmy na koszty naruszeń i sankcje regulacyjne.

W odpowiedzi na te wyzwania organizacje przechodzą od normy ISO 27001 (zarządzanie bezpieczeństwem informacji) do normy ISO 42001 (system zarządzania sztuczną inteligencją – AIMS). Podmioty posiadające certyfikację ISO 27001 osiągają zgodność z ISO 42001 o 30-40% szybciej, wykorzystując istniejące struktury oceny ryzyka oraz procedury audytowe.

Wnioski praktyczne i rekomendacje

  • Wdróż deterministyczne filtrowanie wyjścia (output filtering) w kodzie aplikacji poza modelem LLM, aby przechwytywać odpowiedzi zawierające ciągi znaków z bazy sekretów przed ich przekazaniem użytkownikowi.
  • Zweryfikuj strukturę agentów AI pod kątem przechowywania poświadczeń i wyeliminuj wpisywanie kluczy API, haseł oraz tokenów bezpośrednio do promptów systemowych.
  • Skonfiguruj środowisko wykonawcze dla agentów takich jak OpenClaw w wyizolowanych kontenerach lub maszynach wirtualnych bez uprawnień roota i bez dostępu do produkcyjnych baz danych.
  • Zmierz odporność wdrażanych agentów poprzez ciągłe testy adaptacyjne pod obciążeniem oraz automatyczne skanowanie potoków CI/CD przy użyciu narzędzi klasy ZeroLeaks lub Swept AI.

Źródła

Przemysław Majdak

Przemysław Majdak · AI Automation Engineer

Założyciel Baluarte i wydawca BitBiz.pl. Członek ISSA Polska. Ekspert z 18-letnim stażem w branży IT — wdraża bezpieczne automatyzacje AI, systemy full-stack i zaawansowane procedury cyberbezpieczeństwa dla firm. Wszystkie artykuły autora →

Jedna odpowiedź

💬 Kliknij tutaj, aby dodać komentarz

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *

  1. Awatar KasiaZpodlasia
    KasiaZpodlasia

    Deterministyczne filtrowanie wyjścia sprawdza się w labie, ale po pierwszej większej aktualizacji modelu logikę trzeba pisać od nowa. Ile jeszcze budżetu spalicie na łatanie sztywnego kodu, zamiast budować mechanizmy odporne na zmiany wewnątrz LLM?