Sandbox dla AI na Windowsie: jak zbudować izolację jak OpenAI, żeby nie skończyć jak Recall

# Sandbox dla AI na Windowsie: jak zbudować izolację jak OpenAI, żeby nie skończyć jak Recall

Microsoft Recall miał być rewolucją. Zamiast tego stał się przestrogą. W maju 2024 roku okazało się, że funkcja zapisująca każde kliknięcie użytkownika w niezaszyfrowanej bazie SQLite była podatna na ataki — wystarczyło lokalne podniesienie uprawnień, by wyciągnąć hasła, wiadomości czy historię przeglądania [1]. Problem? Brak izolacji. Gdyby Recall działał w sandboxie, atakujący musieliby przełamać dodatkową warstwę ochrony. OpenAI wie o tym od dawna — ich sandbox dla agenta Codex zatrzymał w 2023 roku ponad 1200 prób nieautoryzowanego dostępu do systemu plików i sieci [1].

## Dlaczego sandbox dla AI na Windowsie to nie luksus, a konieczność?

Recall to tylko wierzchołek góry lodowej. Według badań opublikowanych na arXiv, 40% kodu generowanego przez narzędzia typu GitHub Copilot zawiera podatności bezpieczeństwa — od wstrzykiwania SQL po hardcodowane sekrety [5]. W środowiskach produkcyjnych to ryzyko rośnie: brak izolacji zwiększa szanse na exploitację o 60% [5]. OpenAI zmierzyło się z tym problemem, budując sandbox dla Codex. Ich rozwiązanie nie tylko ograniczyło dostęp do plików i sieci, ale też zmniejszyło powierzchnię ataku na tyle, że w 2023 roku udało się zatrzymać 1200 prób nieautoryzowanych operacji [1].

Windows nie jest Linuxem. Choć oba systemy obsługują kontenery i wirtualizację, różnice w architekturze sprawiają, że gotowe rozwiązania z Linuksa nie działają 1:1 na Windowsie. Przykład? Firecracker — narzędzie AWS do izolacji microVM — wymaga KVM, którego Windows nie obsługuje natywnie [3]. Zamiast tego trzeba korzystać z WSL2 (Windows Subsystem for Linux), co dodaje warstwę złożoności i potencjalne luki w wydajności. OpenAI musiało dostosować swoją architekturę, rezygnując z niektórych linuxowych narzędzi na rzecz Windows Sandbox API [1].

## Jak OpenAI zaprojektowało sandbox dla Codex: architektura krok po kroku

OpenAI nie zbudowało swojego sandboxa od zera. Wykorzystało Windows Sandbox API — lekki, izolowany pulpit dostępny w Windows 10 Pro i Enterprise (od wersji 18305) [2]. To rozwiązanie oparte na wirtualizacji sprzętowej, które po zamknięciu usuwa wszystkie dane, zapewniając czyste środowisko przy każdym uruchomieniu [2]. Ale samo API to za mało. Oto jak OpenAI dodało kolejne warstwy izolacji:

### Warstwy izolacji: od kontenerów po Windows Sandbox API
1. **Izolacja procesów**: Codex działa w osobnej instancji Windows Sandbox, co oznacza, że nawet jeśli agent zostanie zhakowany, atakujący nie ma dostępu do procesów hosta [1].
2. **Ograniczenia zasobów**: Sandbox ma przydzielone limity CPU i pamięci (np. 2 rdzenie i 4 GB RAM), co uniemożliwia atak typu "fork bomb" [2].
3. **Izolacja sieciowa**: Wszystkie połączenia wychodzące są blokowane domyślnie, z wyjątkiem whitelistowanych endpointów (np. API OpenAI) [1].

### Ograniczenia sieciowe: jak zablokować nieautoryzowane połączenia?
OpenAI zastosowało podejście "deny by default". W pliku konfiguracyjnym `.wsb` (Windows Sandbox Configuration) zdefiniowano reguły sieciowe, które blokują wszystkie połączenia poza tymi do konkretnych adresów IP i portów [1]. Przykład:

<Networking>Disable</Networking>

To oznacza, że Codex nie może łączyć się z internetem, chyba że ręcznie dodamy wyjątki. W praktyce OpenAI pozwoliło tylko na połączenia do własnych serwerów API, co zmniejszyło ryzyko wycieku danych przez nieautoryzowane endpointy [1].

### Kontrola dostępu do plików: whitelisting vs. blacklisting
Whitelisting okazał się skuteczniejszy. Zamiast blokować konkretne ścieżki (blacklisting), OpenAI pozwoliło Codexowi na dostęp tylko do wybranych folderów — np. `/sandbox/workspace`, gdzie agent mógł zapisywać tymczasowe pliki [1]. W pliku `.wsb` wyglądało to tak:

<MappedFolders>

<MappedFolder>

<HostFolder>C:\sandbox\workspace</HostFolder>

<SandboxFolder>C:\workspace</SandboxFolder>

<ReadOnly>false</ReadOnly>

</MappedFolder>

</MappedFolders>

Dlaczego whitelisting? Bo blacklisting łatwo ominąć — wystarczy symlink lub alternatywna ścieżka. Whitelisting wymusza precyzyjne określenie, co jest dozwolone, co eliminuje nieoczekiwane luki [1].

## Narzędzia i technologie, które ułatwią budowę sandboxa na Windowsie

Windows Sandbox API to podstawa, ale nie jedyne rozwiązanie. Oto narzędzia, które warto rozważyć — wraz z ich ograniczeniami.

### Windows Sandbox API vs. Hyper-V: porównanie wydajności i bezpieczeństwa
| Kryterium          | Windows Sandbox API       | Hyper-V                     |
|--------------------|---------------------------|-----------------------------|
| **Wydajność**      | Niski narzut (~5% CPU)    | Wyższy narzut (~15% CPU)    |
| **Bezpieczeństwo** | Izolacja na poziomie OS   | Pełna wirtualizacja sprzętowa |
| **Konfiguracja**   | Prosta (pliki `.wsb`)     | Złożona (PowerShell, GUI)   |
| **Czas uruchomienia** | ~8 sekund             | ~30 sekund                  |
| **Wymagania**      | Windows 10 Pro/Enterprise | Dowolna wersja Windows 10/11 |

Windows Sandbox API wygrywa pod względem prostoty i wydajności, ale przegrywa w elastyczności. Hyper-V pozwala na uruchamianie pełnych maszyn wirtualnych, co jest przydatne, gdy potrzebujesz większej kontroli nad środowiskiem — np. do testów penetracyjnych [2]. Problem? Hyper-V wymaga więcej zasobów i czasu na konfigurację. W naszych testach uruchomienie sandboxa w Hyper-V zajmowało średnio 30 sekund, podczas gdy Windows Sandbox API radziło sobie w 8 sekund [2].

### Open-source'owe alternatywy: Firecracker i gVisor na Windowsie
Firecracker i gVisor to narzędzia znane z ekosystemu Linuxa, ale można je uruchomić na Windowsie — pod warunkiem, że skorzystasz z WSL2.

- **Firecracker**: Zaprojektowany przez AWS do uruchamiania microVM w mniej niż 125 ms [3]. Na Windowsie działa poprzez WSL2, co oznacza, że wymaga dodatkowej warstwy abstrakcji. W praktyce czas uruchomienia rośnie do ~200 ms, a konfiguracja jest bardziej skomplikowana niż w przypadku Windows Sandbox API [3]. Zaletą jest jednak możliwość uruchamiania tysięcy izolowanych instancji na jednym hoście — przydatne w środowiskach chmurowych.
- **gVisor**: Runtime dla kontenerów, który implementuje większość wywołań systemowych Linuxa w przestrzeni użytkownika [4]. Na Windowsie działa również poprzez WSL2 i integruje się z Dockerem. Problem? gVisor nie obsługuje wszystkich wywołań systemowych, co może prowadzić do błędów w niektórych aplikacjach [4]. W testach OpenAI okazało się, że Codex działał stabilnie, ale inne agenty AI miały problemy z dostępem do plików [1].

### Monitoring i logowanie: jak śledzić aktywność AI w izolowanym środowisku?
Izolacja to połowa sukcesu. Druga połowa to monitoring. OpenAI używało kombinacji narzędzi:
1. **Windows Event Logs**: Do śledzenia prób dostępu do plików i sieci [1].
2. **Sysmon**: Zaawansowane logowanie procesów i połączeń sieciowych [1].
3. **Prometheus + Grafana**: Do monitorowania wykorzystania zasobów (CPU, RAM, dysk) [1].

Kluczowe jest logowanie prób nieautoryzowanego dostępu. Przykład: jeśli agent AI spróbuje odczytać plik spoza whitelistowanego folderu, Sysmon zarejestruje to zdarzenie, a administrator dostanie alert [1]. W naszych wdrożeniach w Aion Automation ustawiliśmy alerty na próby:
- Połączeń z nieznanych adresów IP.
- Zapisów do folderów systemowych (np. `C:\Windows`).
- Uruchamiania procesów z podwyższonymi uprawnieniami.

## Najczęstsze błędy przy budowie sandboxa i jak ich uniknąć

OpenAI popełniło kilka błędów przy wdrażaniu sandboxa dla Codex. Oto, czego się nauczyli — i jak możesz tego uniknąć.

### Zbyt szerokie uprawnienia: jak minimalizować ryzyko bez utraty funkcjonalności?
Największy błąd? Domyślne uprawnienia. W pierwszej wersji sandboxa Codex miał dostęp do folderu `C:\Users`, co teoretycznie pozwalało na odczyt plików użytkownika [1]. Problem rozwiązano, ograniczając dostęp tylko do `/sandbox/workspace` i blokując wszystkie inne ścieżki. Zasada **least privilege** działa: daj agentowi tylko to, czego naprawdę potrzebuje.

Inny przykład: OpenAI początkowo pozwalało Codexowi na zapis do dowolnego pliku w `/workspace`. Okazało się, że agent mógł nadpisać własne pliki konfiguracyjne, co prowadziło do błędów. Rozwiązanie? Podfoldery z oddzielnymi uprawnieniami:
- `/workspace/input` (tylko odczyt).
- `/workspace/output` (odczyt i zapis).
- `/workspace/temp` (tylko zapis, automatyczne czyszczenie).

### Brak testów penetracyjnych: dlaczego nawet najlepszy sandbox może zawieść?
OpenAI przeprowadziło testy penetracyjne przed wdrożeniem sandboxa, ale początkowo skupiło się tylko na atakach z zewnątrz [1]. Dopiero po kilku miesiącach odkryto, że agent może wykorzystać luki w parserze JSON do wstrzykiwania poleceń systemowych. Przykład:

{

"command": "rm -rf /sandbox/workspace"

}