Na początku lutego 2026 roku GitGuardian opublikował raport, który powinien zaniepokoić każdego dewelopera korzystającego z osobistego asystenta AI. Ich infrastruktura skanowania sekretów wykryła ponad 200 wyciekłych danych uwierzytelniających bezpośrednio powiązanych z wdrożeniami OpenClaw — klucze API, hasła do baz danych, tokeny OAuth i dane uwierzytelniające dostawców chmurowych, rozrzucone po publicznych repozytoriach, plikach logów i raportach błędów. Niektóre należały do firm z branży ochrony zdrowia. Inne do startupów fintech. Wszystkie były aktywne.
Kilka dni później Northeastern University opublikował artykuł z nagłówkiem, który uderzał mocniej niż jakikolwiek numer CVE: „Dlaczego asystent AI OpenClaw to 'koszmar prywatności'." Badacze nie skupili się na pojedynczej podatności. Skupili się na samej architekturze — na sposobie, w jaki OpenClaw obsługuje dane, przechowuje dane uwierzytelniające i ujawnia informacje użytkowników z założenia, nie przez przypadek.
To nie były odosobnione incydenty spowodowane nieostrożnymi użytkownikami. To były przewidywalne skutki uruchamiania agentów AI w środowiskach, gdzie sekrety, dane użytkowników i kod agenta współdzielą tę samą przestrzeń adresową bez żadnej izolacji między nimi.
Jak sekrety trafiają w niewłaściwe miejsca
Typowa konfiguracja OpenClaw wygląda tak: instalujesz go na swoim komputerze, konfigurujesz klucze API w zmiennych środowiskowych i zaczynasz rozmawiać. Proces agenta działa jako Twój użytkownik, z Twoimi uprawnieniami, odczytując Twoje zmienne środowiskowe. Każdy zainstalowany skill działa w tym samym procesie, z tym samym dostępem.
To oznacza, że kiedy prosisz asystenta AI o pomoc w debugowaniu skryptu wdrożeniowego, agent widzi Twoje dane uwierzytelniające AWS. Kiedy skill przetwarza Twój email, może odczytać hasło do bazy danych. Kiedy wystąpi błąd i stack trace trafi do pliku logów, te zmienne środowiskowe mogą się w nim znaleźć. A kiedy ten plik logów zostanie zacommitowany do repozytorium, przesłany w zgłoszeniu błędu lub zsynchronizowany z usługą chmurową — Twoje sekrety są teraz publiczne.
Ponad 200 wyciekłych sekretów wykrytych przez GitGuardian nie było wynikiem 200 osobnych pomyłek. Były wynikiem jednego błędu architektonicznego powtórzonego 200 razy: umieszczenia sekretów w process.env, gdzie każdy fragment kodu w procesie może je odczytać.
Problem narasta wraz ze skillami i pluginami. System skilli OpenClaw uruchamia kod firm trzecich w tym samym procesie co główny agent. Złośliwy skill nie potrzebuje exploita, żeby ukraść Twoje dane uwierzytelniające — po prostu czyta process.env. Źle napisany skill nie musi celowo ujawniać Twoich danych — po prostu dołącza kontekst środowiskowy do raportu błędu. Powierzchnia ataku to nie podatność do załatania. To sama architektura.
Co Northeastern trafnie zidentyfikował
Badacze z Northeastern zidentyfikowali coś, wokół czego społeczność bezpieczeństwa krążyła od dawna: problem prywatności asystentów AI nie dotyczy szyfrowania ani uwierzytelniania. Dotyczy fundamentalnego pytania o to, do czego agent ma dostęp i jakie granice istnieją między światem agenta a Twoim.
Kiedy agent AI działa jako Twój użytkownik, z Twoimi uprawnieniami, na Twoim komputerze, nie ma żadnej granicy. Agent może czytać Twoje pliki, dane uwierzytelniające, historię przeglądania, klucze SSH. Może uzyskać dostęp do wszystkiego, do czego Ty masz dostęp. Jedyną rzeczą powstrzymującą go przed zrobieniem czegoś szkodliwego jest prompt — a ataki prompt injection wielokrotnie udowodniły, że prompty nie stanowią granicy bezpieczeństwa.
To właśnie Northeastern miał na myśli, mówiąc o „koszmarze prywatności". Nie to, że OpenClaw celowo kradł dane, ale że architektura uniemożliwiała zagwarantowanie, że dane nie wyciekną. Dostęp agenta był ograniczony jedynie uprawnieniami użytkownika systemu operacyjnego, co w praktyce oznacza, że nie był ograniczony w żaden znaczący sposób.
Jak izolacja kontenerowa NanoClaw zmienia równanie
NanoClaw przyjmuje fundamentalnie inne podejście. Każdy agent działa wewnątrz własnego kontenera Linux — Apple Container na macOS, Docker na macOS i Linux. Kontener to nie funkcja wygodna ani opcja wdrożeniowa. To model bezpieczeństwa.
Kiedy wysyłasz wiadomość do NanoClaw, proces hosta nie uruchamia Claude bezpośrednio. Tworzy kontener, montuje tylko konkretne katalogi, do których agent potrzebuje dostępu, i przekazuje kontekst rozmowy. Agent działa wewnątrz kontenera z własnym systemem plików, własną przestrzenią procesów i własnym stosem sieciowym. Kiedy skończy, kontener jest niszczony.
Tu robi się ciekawie, jeśli chodzi o obsługę sekretów. NanoClaw nigdy nie ładuje Twojego ANTHROPIC_API_KEY do process.env. Zamiast tego odczytuje klucz z .env w czasie wykonania i przekazuje go do procesu kontenera przez stdin jako ładunek JSON. Wewnątrz kontenera agent-runner odbiera klucz, używa go do wywołań API i nigdy nie zapisuje go na dysku ani nie eksportuje do zmiennych środowiskowych.
To oznacza, że nawet jeśli złośliwy prompt nakłoni agenta do uruchomienia `printenv` lub `cat /proc/self/environ`, klucza API tam nie ma. Istnieje tylko w pamięci procesu agent-runner, na czas pojedynczej tury rozmowy. Skompromitowany kontener nie może ujawnić tego, do czego nie ma dostępu.
System montowania dodaje kolejną warstwę. NanoClaw utrzymuje listę dozwolonych katalogów, które mogą być montowane do kontenerów, przechowywaną poza katalogiem głównym projektu. Każda grupa dostaje własny izolowany system plików — własny plik pamięci CLAUDE.md, własną zapisywalną przestrzeń roboczą. Lista dozwolonych zawiera wykrywanie ucieczek przez dowiązania symboliczne, więc spreparowane dowiązanie symboliczne nie może oszukać systemu montowania, by ujawnić katalogi poza dozwolonym zestawem.
Kontenery działają też jako użytkownik bez uprawnień root, z kodem źródłowym projektu zamontowanym tylko do odczytu. Agent może czytać bazę kodu, żeby zrozumieć kontekst, ale nie może modyfikować plików hosta. Ścieżki zapisywalne są ograniczone do grupy i czyszczone po zamknięciu kontenera.
Model izolacji per grupa
Izolacja NanoClaw wykracza poza samo oddzielenie agenta od hosta. Każda grupa WhatsApp dostaje własny kontener, własną pamięć i własny system plików. Grupa A nie widzi rozmów, plików ani pamięci CLAUDE.md grupy B — nie dzięki kontroli dostępu na poziomie aplikacji, ale dlatego, że działają w fizycznie oddzielnych kontenerach z oddzielnymi punktami montowania.
Ma to znaczenie w scenariuszu, który większość asystentów AI całkowicie ignoruje: współdzielone urządzenia i konfiguracje wieloużytkownikowe. Jeśli używasz NanoClaw z rodziną, rozmowy i pliki Twojej grupy roboczej są izolowane od rozmów i plików grupy rodzinnej na poziomie kontenera. Nie ma buga aplikacji, który mógłby spowodować wyciek danych między grupami, bo izolacja jest wymuszana przez środowisko uruchomieniowe kontenera, nie przez aplikację.
Twój główny kanał WhatsApp — bezpośrednia wiadomość z asystentem — służy jako interfejs administracyjny. To jedyny kanał, który może zarządzać zaplanowanymi zadaniami, modyfikować konfigurację i uzyskiwać dostęp do stanu międzygrupowego. Kanały grupowe są domyślnie ograniczone do własnego sandboxa.
Czego branża powinna się nauczyć
Raport GitGuardian i analiza Northeastern prowadzą do tego samego wniosku: agenci AI to infrastruktura, a infrastruktura wymaga bezpieczeństwa na poziomie infrastruktury. Uruchamianie agenta AI w tym samym procesie co Twoje dane uwierzytelniające, z tymi samymi uprawnieniami co Twoje konto użytkownika, to odpowiednik uruchamiania serwera webowego jako root bez firewalla. Działa, dopóki nie przestanie, a kiedy przestanie, zasięg rażenia to wszystko.
Izolacja kontenerowa to nie nowy pomysł. Branża hostingowa rozwiązała to dwie dekady temu — nie uruchamia się kodu wielu klientów w tym samym procesie. Branża bazodanowa rozwiązała to jeszcze wcześniej — nie daje się każdemu zapytaniu dostępu do każdej tabeli. Ale ekosystem agentów AI wciąż jest w fazie „uruchamiaj wszystko jako root", a wyciekłe sekrety i koszmary prywatności to przewidywalny rezultat.
Podejście NanoClaw nie jest jedynym sposobem rozwiązania tego problemu, ale pokazuje, że problem jest rozwiązywalny bez poświęcania funkcjonalności. Agenci działający wewnątrz kontenerów nadal mogą przeszukiwać internet, przeglądać strony, czytać i zapisywać pliki oraz wykonywać polecenia powłoki. Po prostu robią to wewnątrz sandboxa, gdzie zasięg rażenia każdej awarii — czy to buga, prompt injection, czy złośliwego skilla — jest ograniczony do zakresu tego pojedynczego kontenera.
200 wyciekłych sekretów, które znalazł GitGuardian, nie musiało się wydarzyć. Wydarzyły się, bo architektura czyniła je nieuniknionymi. Rozwiązaniem nie jest lepsza edukacja użytkowników ani ostrożniejsze zarządzanie danymi uwierzytelniającymi. Rozwiązaniem jest architektura, w której sekrety nie mogą wyciec, bo nigdy nie znajdują się w miejscu, z którego wyciek jest możliwy.