Twoja firma właśnie wdrożyła agenta AI. Ma dostęp do e-maili, kalendarza, CRM. Działa świetnie – oszczędza godziny pracy tygodniowo. A potem ktoś wysyła spreparowany e-mail i agent zaczyna robić rzeczy, których nigdy nie powinien.
Jak temu zapobiec? Odpowiedź brzmi: obrona w głębokości (defense in depth) – strategia, która zakłada, że każda pojedyncza warstwa zabezpieczeń może zawieść, więc potrzebujesz ich kilku naraz.
W tym artykule kontynuujemy serię o bezpieczeństwie AI. Jeśli nie czytałeś pierwszego wpisu o prompt injection, zacznij od niego – wyjaśnia podstawowe zagrożenie, na które odpowiadają mechanizmy opisane poniżej. OpenClaw to platforma do uruchamiania osobistych asystentów AI, o której więcej przeczytasz w artykule Czym jest OpenClaw?
- Dlaczego jedna warstwa zabezpieczeń nie wystarczy?
- Filar 1: Kontrola tożsamości
- Filar 2: Kontrola zakresu
- Filar 3: Założenie o możliwej manipulacji
- Weryfikacja bezpieczeństwa: modele TLA+
- Praktyczna checklista dla polskich MŚP
- Co z tego wynika dla twojego biznesu?
Dlaczego jedna warstwa zabezpieczeń nie wystarczy?
W tradycyjnym oprogramowaniu często wystarczy jedno dobre zabezpieczenie. Firewall blokuje nieautoryzowany ruch. Hasło chroni konto. Szyfrowanie chroni dane w transmisji.
Z agentami AI jest inaczej. Model językowy nie jest deterministyczny – nie możesz przewidzieć dokładnie, jak zareaguje na każdy możliwy input. Nawet najlepsze instrukcje w system prompcie to tylko „miękkie" wytyczne, które sprytny atakujący może próbować obejść.
Dlatego profesjonalne podejście do bezpieczeństwa AI opiera się na trzech filarach, stosowanych jednocześnie.
Filar 1: Kontrola tożsamości – kto może rozmawiać z agentem?
Pierwsza i najbardziej podstawowa warstwa to kontrola dostępu. Zanim w ogóle zastanawiasz się, czy agent może być zmanipulowany, odpowiedz na pytanie: kto w ogóle może do niego pisać?
OpenClaw oferuje kilka poziomów kontroli dostępu:
| Polityka | Jak działa | Kiedy używać |
| pairing (domyślna) | Nieznani nadawcy otrzymują kod weryfikacyjny do potwierdzenia | Osobisty asystent, mała firma |
| allowlist | Tylko osoby z białej listy mogą pisać | Zespoły, kontrolowane środowiska |
| open | Każdy może pisać do agenta | Publiczne chatboty (wymaga dodatkowych zabezpieczeń!) |
System parowania działa podobnie jak dodawanie nowego kontaktu w komunikatorze – agent wysyła jednorazowy kod, który trzeba potwierdzić. To proste, ale skutecznie eliminuje przypadkowych atakujących.
Kluczowa zasada: im mniej osób ma dostęp do agenta, tym mniejsza powierzchnia ataku. Agent dostępny dla całego świata wymaga znacznie silniejszych zabezpieczeń niż agent, z którym rozmawia tylko właściciel.
Więcej o konfiguracji dostępu przeczytasz w artykule OpenClaw: bezpieczeństwo danych.
Filar 2: Kontrola zakresu – co agent może robić?
Nawet jeśli tylko zaufane osoby mają dostęp do agenta, wciąż istnieje ryzyko. Pamiętasz scenariusze z poprzedniego wpisu? Atakujący może ukryć instrukcje w e-mailu, dokumencie lub stronie internetowej – a te treści agent przetwarza na żądanie autoryzowanego użytkownika.
Dlatego druga warstwa to ograniczenie możliwości agenta. W OpenClaw realizuje się to przez kilka mechanizmów.
Polityka narzędzi określa, które narzędzia są w ogóle dostępne dla agenta. Jeśli agent służy tylko do odpowiadania na pytania, nie potrzebuje dostępu do systemu plików ani możliwości wysyłania e-maili. Im mniej narzędzi, tym mniejsze potencjalne szkody w przypadku manipulacji.
Sandboxing to izolacja środowiska wykonawczego. Agent może działać w kontenerze Docker, który nie ma dostępu do reszty systemu. Nawet gdyby wykonał złośliwe polecenie, skutki ograniczają się do piaskownicy.
Tryb elevated wymaga jawnej autoryzacji dla wrażliwych operacji. Zamiast automatycznie wykonywać każde polecenie, agent może pytać o potwierdzenie przed krytycznymi akcjami.
Praktyczna zasada: agent powinien mieć minimalne uprawnienia niezbędne do wykonania swojego zadania. Jeśli agent analizuje dokumenty, nie musi mieć możliwości kasowania plików. Jeśli odpowiada na pytania, nie musi mieć dostępu do terminala.
Filar 3: Założenie o możliwej manipulacji
Trzeci filar to fundamentalna zmiana perspektywy: zakładaj, że model może zostać zmanipulowany. Nie pytaj „czy atak się uda?", tylko „co się stanie, gdy atak się uda?".
To podejście nazywa się czasem „projektowaniem pod porażkę" (designing for failure) i jest standardem w systemach krytycznych. Samolot ma wiele silników, bo zakładamy, że jeden może zawieść. Most ma zapas wytrzymałości, bo zakładamy, że obciążenie może być większe niż planowane.
W kontekście agentów AI oznacza to:
Ograniczenie blast radius – nawet udany atak powinien mieć ograniczone konsekwencje. Jeśli agent może tylko czytać pliki, ale nie może ich modyfikować ani wysyłać, wyciek danych jest mniej prawdopodobny.
Separacja uprawnień – różne zadania wykonują różni agenci z różnymi uprawnieniami. Agent do researchu nie ma dostępu do CRM. Agent do obsługi klienta nie ma dostępu do finansów.
Monitorowanie i audyt – każda akcja agenta jest logowana. Jeśli coś pójdzie nie tak, możesz dokładnie prześledzić, co się stało i dlaczego.
Jak OpenClaw weryfikuje bezpieczeństwo: modele TLA+
To, co wyróżnia OpenClaw na tle innych platform, to podejście do weryfikacji bezpieczeństwa. Zamiast polegać tylko na testach i code review, OpenClaw publikuje formalne modele TLA+ krytycznych ścieżek bezpieczeństwa.
TLA+ to język specyfikacji formalnej, używany przez Amazon, Microsoft i inne duże firmy do weryfikacji systemów rozproszonych. Pozwala matematycznie udowodnić, że określone właściwości systemu są spełnione – lub znaleźć kontrprzykłady, gdy nie są.
| Obszar | Co jest weryfikowane | Status |
| Ekspozycja Gateway | Błędy konfiguracji nie prowadzą do nieautoryzowanego dostępu | ✅ Zweryfikowane |
| System parowania | Kody wygasają, limity są respektowane | ✅ Zweryfikowane |
| Izolacja sesji | Różni użytkownicy nie widzą nawzajem swoich danych | ✅ Zweryfikowane |
| Kontrola poleceń | Nieautoryzowane komendy nie omijają bramek | ✅ Zweryfikowane |
Każdy zweryfikowany obszar ma nie tylko pozytywny model (pokazujący, że system działa poprawnie), ale też model negatywny – celowo wprowadzające błędy, które powinny zostać wykryte. To gwarantuje, że weryfikacja faktycznie coś sprawdza.
Więcej o architekturze OpenClaw przeczytasz w artykule Czym jest OpenClaw?.
Praktyczna checklista dla polskich MŚP
Jeśli wdrażasz agenta AI w swojej firmie, oto konkretne kroki do wdrożenia obrony w głębokości:
Warstwa 1 – Kontrola dostępu:
- Włącz system parowania lub białą listę (nie używaj trybu „open" bez dodatkowych zabezpieczeń)
- Ogranicz liczbę osób, które mogą rozmawiać z agentem
- Rozważ osobne agenty dla różnych grup użytkowników
Warstwa 2 – Kontrola zakresu:
- Wyłącz narzędzia, których agent nie potrzebuje
- Włącz sandboxing dla sesji grupowych lub publicznych
- Skonfiguruj wymaganie potwierdzenia dla wrażliwych operacji
Warstwa 3 – Projektowanie pod porażkę:
- Rozdziel uprawnienia między osobne agenty
- Włącz logowanie wszystkich akcji
- Regularnie przeglądaj logi pod kątem anomalii
- Przeprowadź audyt bezpieczeństwa (
openclaw security audit)
Co z tego wynika dla twojego biznesu?
Obrona w głębokości to nie paranoiczne podejście – to profesjonalny standard. Duże firmy technologiczne stosują te zasady od lat w swoich systemach. Teraz, gdy agenci AI trafiają do małych i średnich przedsiębiorstw, te same zasady stają się istotne dla każdego.
Dobra wiadomość: nie musisz być ekspertem od bezpieczeństwa, żeby wdrożyć podstawowe warstwy ochrony. Platformy takie jak OpenClaw oferują sensowne domyślne ustawienia i narzędzia do audytu, które prowadzą cię przez proces.
Zła wiadomość: bezpieczeństwo to nie jednorazowa konfiguracja. Wymaga regularnych przeglądów, aktualizacji i świadomości nowych zagrożeń. Ale to dotyczy każdego systemu IT – agenci AI nie są tu wyjątkiem.
W kolejnym wpisie przyjrzymy się, jak wybór modelu AI wpływa na bezpieczeństwo – dlaczego tańszy model może okazać się droższy, gdy liczymy koszty potencjalnych incydentów.
To drugi wpis z serii „AI i bezpieczeństwo". Kolejne części ukażą się w najbliższych dniach.