Nie ufaj agentom AI

28 lutego 2026 · Gavriel Cohen

Kiedy pracujesz z agentami AI, powinieneś traktować ich jako niezaufanych i potencjalnie złośliwych. Niezależnie od tego, czy martwisz się o prompt injection, ucieczkę modelu z sandbox-a, czy coś, o czym jeszcze nikt nie pomyślał — bez względu na Twój model zagrożeń, nie powinieneś ufać agentowi. Właściwym podejściem nie są lepsze kontrole uprawnień ani inteligentniejsze allowlisty. To architektura, która zakłada, że agenci będą się źle zachowywać, i ogranicza szkody, gdy to nastąpi.

Na tej zasadzie zbudowałem NanoClaw.

Nie ufaj procesowi

OpenClaw domyślnie działa bezpośrednio na maszynie hosta. Ma opcjonalny tryb sandbox Docker, ale jest wyłączony od razu po instalacji i większość użytkowników nigdy go nie włącza. Bez niego bezpieczeństwo opiera się wyłącznie na kontrolach na poziomie aplikacji: allowlisty, monity potwierdzające, zestaw „bezpiecznych” poleceń. Te mechanizmy wynikają z domyślnego zaufania, że agent nie będzie próbował zrobić czegoś złego. Gdy przyjmiesz założenie, że agent jest potencjalnie złośliwy, staje się oczywiste, że blokady na poziomie aplikacji nie wystarczą. Nie zapewniają hermetycznego bezpieczeństwa. Zdeterminowany lub skompromitowany agent znajdzie sposoby, żeby je obejść.

W NanoClaw izolacja kontenerowa jest fundamentalną częścią architektury. Każdy agent działa we własnym kontenerze — Docker lub Apple Container na macOS. Kontenery są efemeryczne: tworzone od nowa przy każdym wywołaniu i niszczone po zakończeniu. Agent działa jako użytkownik bez uprawnień i widzi tylko katalogi, które zostały jawnie zamontowane. Granica kontenera jest egzekwowana przez system operacyjny.

Nie ufaj innym agentom

Nawet gdy sandbox OpenClaw jest włączony, wszyscy agenci współdzielą ten sam kontener. Możesz mieć jednego agenta jako asystenta osobistego, a drugiego do pracy — w różnych grupach WhatsApp lub kanałach Telegram. Wszyscy są w tym samym środowisku, co oznacza, że informacje mogą wyciekać między agentami, którzy powinni mieć dostęp do różnych danych.

Agenci nie powinni sobie nawzajem ufać bardziej niż Ty ufasz im. W NanoClaw każdy agent otrzymuje własny kontener, system plików i historię sesji Claude. Twój asystent osobisty nie widzi danych agenta roboczego, ponieważ działają w całkowicie oddzielnych sandbox-ach.

WSPÓŁDZIELONY KONTENER Asystent osobisty Agent roboczy Agent grupy rodzinnej Współdzielony system plików Wszystkie poświadczenia dostępne Wszystkie historie sesji widoczne Wszystkie zamontowane dane współdzielone Wszyscy agenci widzą wszystko KONTENER NA AGENTA Asystent osobisty /data/personal własna sesja ro × Agent roboczy /data/work własna sesja rw × Agent grupy rodzinnej /data/family własna sesja ro Agenci odizolowani od siebie

Granica kontenera to twarda warstwa bezpieczeństwa — agent nie może jej przekroczyć niezależnie od konfiguracji. Ponad tym allowlista montowania w ~/.config/nanoclaw/mount-allowlist.json działa jako dodatkowa warstwa obrony w głąb: istnieje po to, by zapobiec przypadkowemu zamontowaniu przez użytkownika czegoś, co nie powinno być eksponowane, a nie po to, by uniemożliwić agentowi ucieczkę. Wrażliwe ścieżki (.ssh, .gnupg, .aws, .env, private_key, credentials) są domyślnie zablokowane. Allowlista znajduje się poza katalogiem projektu, więc skompromitowany agent nie może modyfikować własnych uprawnień. Kod aplikacji hosta jest montowany w trybie tylko do odczytu, więc nic, co agent zrobi, nie przetrwa zniszczenia kontenera.

Osobom w Twoich grupach też nie należy ufać. Grupy inne niż główna są domyślnie traktowane jako niezaufane. Inne grupy i osoby w nich nie mogą wysyłać wiadomości do innych czatów, planować zadań dla innych grup ani przeglądać danych innych grup. Każdy w grupie może wysłać prompt injection, a model bezpieczeństwa to uwzględnia.

Nie ufaj temu, czego nie możesz przeczytać

OpenClaw ma prawie pół miliona linii kodu, 53 pliki konfiguracyjne i ponad 70 zależności. To łamie podstawowe założenie bezpieczeństwa open source. Chromium ma ponad 35 milionów linii, ale ufasz procesom recenzji Google. Większość projektów open source działa odwrotnie: pozostają na tyle małe, że wiele par oczu faktycznie może je przejrzeć. Nikt nie przejrzał 400 000 linii OpenClaw. Został napisany w ciągu tygodni bez właściwego procesu recenzji. Złożoność to miejsce, gdzie kryją się podatności, a analiza Microsoft to potwierdziła: ryzyka OpenClaw mogły się ujawnić przez zwykłe wywołania API, ponieważ żadna pojedyncza osoba nie mogła ogarnąć pełnego obrazu.

Porównanie linii kodu: OpenClaw ~400 000 linii vs NanoClaw ~3 000 linii

NanoClaw to jeden proces i garść plików. Zamiast wynajdywać koło na nowo, w dużej mierze polegamy na Agent SDK od Anthropic — nakładce na Claude Code — do zarządzania sesjami, kompresji pamięci i wielu innych rzeczy. Kompetentny programista może przejrzeć całą bazę kodu w jedno popołudnie. To świadome ograniczenie, nie słabość. Nasze wytyczne dotyczące wkładu akceptują wyłącznie poprawki błędów, poprawki bezpieczeństwa i uproszczenia.

Nowa funkcjonalność pojawia się przez skills: instrukcje z pełną działającą implementacją referencyjną, którą agent kodujący scala z Twoją bazą kodu. Przed dodaniem kodu dokładnie widzisz, co zostanie dodane. I dodajesz tylko te integracje, których faktycznie potrzebujesz. Każda instalacja kończy się jako kilka tysięcy linii kodu dostosowanych do dokładnych wymagań właściciela.

To jest prawdziwa różnica. W monolitycznej bazie kodu o 400 000 liniach, nawet jeśli włączysz tylko dwie integracje, reszta kodu wciąż tam jest. Wciąż jest załadowana, wciąż jest częścią Twojej powierzchni ataku, wciąż dostępna dla prompt injection i złośliwych agentów. Nie da się oddzielić tego, co aktywne, od tego, co uśpione. Nie da się tego audytować, bo nie da się nawet zdefiniować granicy tego, czym jest „Twój kod”. Ze skills granica jest oczywista: to kilka tysięcy linii, to cały kod, który wybrałeś, by dodać, i możesz przeczytać każdą jego linię. Rdzeń faktycznie się zmniejsza z czasem: obsługa WhatsApp jest na przykład wyciągana i pakowana jako skill.

Projektuj z myślą o braku zaufania

Jeśli halucynacja lub źle zachowujący się agent może spowodować problem bezpieczeństwa, to model bezpieczeństwa jest zepsuty. Bezpieczeństwo musi być egzekwowane poza powierzchnią agentową, a nie zależeć od poprawnego zachowania agenta. Kontenery, ograniczenia montowania i izolacja systemu plików istnieją po to, by nawet gdy agent zrobi coś nieoczekiwanego, promień rażenia był ograniczony.

Nic z tego nie eliminuje ryzyka. Agent AI z dostępem do Twoich danych jest z natury rozwiązaniem wysokiego ryzyka. Ale właściwą odpowiedzią jest uczynienie tego zaufania tak wąskim i tak weryfikowalnym, jak to możliwe. Nie ufaj agentowi. Buduj wokół niego mury.

Możesz przeczytać kod źródłowy i pełny model bezpieczeństwa NanoClaw; są wystarczająco krótkie, by przeczytać je w jedno popołudnie.