Przejdź do treści

NVIDIA OpenShell: otwartoźródłowy sandbox dla agentów AI. Jak działa i skąd go pobrać

Adam Marzec
Rejestr przewodnika: tytuł OPENSHELL: PIASKOWNICA NA KERNELU, plakietka NVIDIA OTWIERA, 23.10.2026; karty WERSJA 0.1.5, IZOLACJA KERNEL, GATEWAY 17670; pigułki NVIDIA, APACHE 2.0, DOCKER; pomarańczowa pieczątka ZA DARMO; stan 23.10.2026

22 października 2026 o 17:44 UTC na Hacker News wylądował wpis Show HN prowadzący do repozytorium NVIDIA/OpenShell, opisany jako bezpieczny i prywatny runtime dla flot autonomicznych agentów AI. Do poranka 23 października dyskusja uzbierała 355 punktów oraz 183 komentarze (odczyt z API Algolii), a samo repozytorium 18 000 gwiazdek i 1841 forków (GitHub API, odczyt 23.10). Publikacja kodu nie jest jednak wydarzeniem jednodniowym. Repozytorium powstało 24 lutego 2026, pierwsze wydanie ukazało się 17 marca, a 21 października na GTC Berlin Jensen Huang pokazał architekturę referencyjną zbudowaną wokół OpenShell, o czym pisze The Register. Dla praktyka liczy się co innego: najnowsze wydanie 0.1.5 wyszło 20 października, a cały runtime stawia się na zwykłym linuksie z Dockerem.

W tym tekście tłumaczę, jak działa izolacja agenta, jak przeprowadzić instalację i czym OpenShell różni się od gołego kontenera. Kontekst się przydaje: bezpieczeństwo agentów AI przestało być teorią, a The Register przypomina testy bezpieczeństwa OpenAI i Anthropic, podczas których modele wychodziły poza zadany zakres i atakowały organizacje trzecie. Piaskownica trzymająca agenta w ryzach na poziomie kernela to jedna z odpowiedzi na ten problem.

Najważniejsze informacje

CoSzczegóły
Licencja i cenaApache 2.0, projekt open source na GitHubie (NVIDIA/OpenShell), bez opłat
Wersja0.1.5 z 20.10.2026 (GitHub Releases oraz PyPI); seria 0.1.x wystartowała 25.09.2026
SystemyLinux Debian/Ubuntu na amd64 i arm64, macOS Apple Silicon z Docker Desktop, Windows przez WSL 2 eksperymentalnie
RuntimeDocker od wersji 28.0, Podman 5.x, Kubernetes 1.29 albo wirtualizacja hosta (MicroVM)
IzolacjaLandlock dla systemu plików plus seccomp dla syscalli i sieci; kernel Linux 6.2 lub nowszy
Weryfikacja politykformalna weryfikacja zmian przed zatwierdzeniem (policy prover w gatewayu)
Skala projektu18 000 gwiazdek, 1841 forków, 102 wydania, 565 otwartych zgłoszeń (odczyt 23.10.2026)

Jak to działa

OpenShell rządzi agentem na dwóch poziomach, oba opisuje README. Pierwszy to instrumentacja kernela: agent działa w osobnej piaskownicy, a kernel Linuxa pilnuje na żywo, do których plików i wywołań systemowych może sięgnąć. Od strony plików robot spina Landlock, od strony sieci seccomp, a każde połączenie wychodzące przechodzi przez kontrolę polityki, zanim opuści piaskownicę. W praktyce agent nigdy nie widzi prawdziwych poświadczeń: klucze API zostają poza piaskownicą, doklejane wyłącznie do żądań kierowanych na zatwierdzone endpointy. Gdy model spróbuje wysłać sekret albo fragment repozytorium na nieznany host, ruch nie wyjdzie poza ogrodzenie, bo domyślna polityka odrzuca wszystko, czego nie wpisano wprost.

Drugim poziomem jest formalna weryfikacja zmian polityki. Zanim nowa reguła zostanie dopuszczona, policy prover sprawdza w sposób formalny, jakiego dostępu realnie doda: nowy host osiągalny z poświadczeniami, nowa metoda HTTP albo endpoint metadanych chmury to sygnały ryzyka, które blokują automatyczne zatwierdzenie i kierują zmianę do przeglądu człowieka. Do tego reguły sieciowe przeładowują się na żywo bez restartu piaskownicy. W efekcie agent może prosić o poszerzenie uprawnień w trakcie pracy, ale każdą prośbę weryfikuje maszyna, a zatwierdza człowiek.

Architekturę składają trzy klocki: gateway, supervisor i sandbox. Gateway to płaszczyzna zarządzania, supervisor podejmuje decyzje po zaufanej stronie granicy, a sandbox dzieli środowisko z agentem i nigdy nie decyduje sam. Jedyną drogą ruchu wychodzącego z piaskownicy jest kanał do supervisora, a gdy supervisor zniknie, agent zostaje zamrożony. To więcej niż kontener z odciętą siecią, bo kontrola obejmuje też tożsamość programu, który wykonuje dane połączenie.

Instalacja i pierwsze kroki

Do uruchomienia OpenShell potrzebny jest linuks (Debian/Ubuntu, amd64 i arm64) albo macOS na Apple Silicon, plus Docker, Podman lub wirtualizacja hosta. Użytkownicy Windows korzystają z WSL 2 z Docker Desktopem w statusie eksperymentalnym. Instalacja sprowadza się do jednej komendy z README:

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh

Na linuksie instalator pobiera pakiet deb albo rpm z wybranego wydania i instaluje go przez systemowego menedżera pakietów z uprawnieniami roota, a wariant snap włącza się zmienną OPENSHELL_INSTALL_METHOD. Na macOS Apple Silicon skrypt stawia formułę Homebrew wraz z lokalnym gatewayiem. Instalator nie dopisuje nic do plików startowych powłoki takich jak ~/.bashrc, bo binarki wchodzą systemowymi ścieżkami razem z pakietem; wymaga glibc 2.28 lub nowszego, a konkretną wersję przypina się zmienną OPENSHELL_VERSION. Pierwszą piaskownicę tworzy się jedną komendą:

openshell sandbox create --name demo

Domyślny obraz piaskownicy nvcr.io/nvidia/base/ubuntu:24.04 to minimalistyczne Ubuntu 24.04 i nie zawiera żadnego agenta. Po uruchomieniu prawdziwego agenta dokumentacja prowadzi przez import profilu OpenRouter, utworzenie providera z kluczem i start piaskownicy z obrazem ghcr.io/anomalyco/opencode:latest; agentem jest w nim OpenCode z darmowym modelem nemotron-3.5-lightning:free, więc przykład działa bez doładowania konta. Wariant :free ma w cenniku OpenRouter zera przy zapytaniach i odpowiedziach, sprawdziłem to w API (odczyt 23.10), dokumentacja tu nie kłamie. OpenCode znamy u nas z porównania z Claude Code, a quickstart jest naturalnym punktem wyjścia.

Cały powyższy opis sprawdziłem wcześniej na własnej maszynie (Ubuntu, kernel 6.8, Docker 27.2.1), bez uprawnień roota i bez uruchamiania instalatora, żeby nie ruszać systemu, na którym pracuję. Wnioski wyszły mniej wygodne niż quickstart. Pakiet z PyPI w wersji 0.1.5 okazuje się biblioteką Pythona do budowy własnych integracji: po pip install openshell w środowisku wirtualnym polecenia openshell po prostu nie ma, bo paczka nie definiuje żadnego punktu wejścia. Narzędzie wiersza poleceń trzeba wziąć z wydań GitHub. Statyczna binarka musl waży 10,4 MB, startuje bez żadnej instalacji, openshell --version zgłasza 0.1.5, a --help wypisuje czternaście grup komand, od piaskownic w sandbox, reguł w policy i konfiguracji gateway po interaktywne TUI o nazwie term. Sumy kontrolne sha256 pobranych plików zgadzają się z listą dołączoną do wydania.

Gateway uruchomiony ręcznie z paczki wydania najpierw odmówił startu bez certyfikatów TLS. Po odpaleniu z flagą --disable-tls wstał na adresie 127.0.0.1:17670 w jakieś dwa, trzy sekundy (sterownik docker, trwałość w SQLite), a w logu zostawił ostrzeżenie o braku jakiegokolwiek mechanizmu uwierzytelniania. I tu pojawiła się najciekawsza obserwacja całego testu: próba utworzenia piaskownicy poleceniem openshell sandbox create --name demo skończyła się odmową z komunikatem o wymaganym uwierzytelnieniu launch-scoped. Nawet lokalnie, na pętli zwrotnej, bez uwierzytelnionego gatewaya piaskownica nie ruszy. To spójne z deklarowaną postawą projektu: pełna instalacja przez install.sh stawia usługę systemd i generuje certyfikaty mTLS, dopiero po tym piaskownica odpowiada na polecenia. Do wstępnej diagnozy wystarczy openshell doctor check, który na moim sprzęcie pokazał Dockera jako ok, z tą uwagą, że raportowana wersja to 27.2.1, czyli poniżej wymaganego minimum 28.0 z macierzy wsparcia, więc zgodności runtime nie potwierdzam.

Co mówią użytkownicy z Hacker News

Dyskusja pod wpisem Show HN miesza entuzjazm ze sceptycyzmem. Najbardziej praktyczny jest mfro: „If you haven’t already been running your agents in containers, you’re crazy. That said, this looks like a great way to manage those containers.” Czyli: kto nie trzyma agentów w kontenerach, działa lekkomyślnie, a OpenShell wygląda na porządne narzędzie do ich zarządzania. Podobnie razuba, wdrażający OpenShell w zespole na własnej warstwie polityk: „The agent traces I’ve seen are wild and goal seeking without a boundary is real.”, czyli ślady agentów bywają szalone, a dążenie do celu bez granic to realny problem.

Najostrzejsze pytanie sceptyków zadał esafak: „My expectation is that it will be poorly maintained; nvidia is not a software company.” (czyli słabo utrzymywany, bo NVIDIA nie jest firmą software’ową). Wątpliwość ma uzasadnienie: 565 otwartych zgłoszeń w repozytorium (GitHub API, odczyt 23.10), a The Register odnotowuje wprost kilka zgłoszeń bezpieczeństwowych. Kadencja jest jednak regularna: 102 wydania od marca, stabilne tagi wychodzą według macierzy wsparcia co tydzień, z celem we wtorki.

Osobnym wątkiem jest telemetria, domyślnie zbierana jako anonimowe liczniki operacyjne. Użytkownik dangoodmanUT podsumował to krótko: „Taking default telemetry is insane.” (domyślna telemetria to obłęd), choć w tym samym komentarzu chwali poziom kontroli. Wyłącznik jest w README: zmienna OPENSHELL_TELEMETRY_ENABLED=false na gatewayu albo server.telemetryEnabled=false przy instalacji Helm, a autorzy dopuszczają też kompilację bez telemetrii. README zastrzega przy tym, że telemetria nie zbiera nazw piaskownic, ścieżek, promptów ani poświadczeń.

Merytorycznie najciekawsza była wymiana o różnicy wobec zwykłych kontenerów. dingaling911 spytał wprost: „Why not just use containers…”, a knicholes odpowiedział: „Because containers don’t use Seccomp and Landlock and check filesystem/network calls against an externally applied policy along w/injecting credentials where needed as a man-in-the-middle, thus keeping the secrets out of reach from the LLM?”. Czyli: sam kontener nie sprawdza wywołań plikowych i sieciowych względem zewnętrznej polityki ani nie wstrzykuje poświadczeń tak, by sekrety zostały poza zasięgiem modelu. Na tej różnicy opiera się cały projekt.

Co to oznacza dla polskiego użytkownika

OpenShell jest darmowy: licencja Apache 2.0, publiczne repozytorium, pakiety na PyPI i w Homebrew, zero limitów. Dokumentacja jest wyłącznie po angielsku, polskiej wersji nie ma, ale każda strona docsów ma wersję markdown (wystarczy dopisać .md do adresu) oraz indeks llms.txt dla agentów AI. Warunkiem uruchomienia jest kernel 6.2 lub nowszy z włączonym Landlock, Docker w wersji co najmniej 28.0 (snap Dockera jest według install.sh niekompatybilny z OpenShell) oraz glibc 2.28 lub nowszy, więc starsze wirtualki z przestarzałym kernelem odpadają.

Trzeba rozróżnić dwie rzeczy, bo prasowe nagłówki je mieszają. Macierz wsparcia nie wymaga żadnego sprzętu NVIDII: w wymaganiach figuruje zwykły linuks na x86-64 albo arm64 z kernelem 6.2 i Dockerem, a karty i procesory sieciowe pojawiają się dopiero w architekturze referencyjnej z GTC Berlin. Według The Register to blueprint na platformie Vera Rubin z monitorowaniem w BlueField-4, skierowany do przedsiębiorstw i wielkich chmur. Kto chce po prostu bezpiecznie puszczać agenta na własnym serwerze, ten tę warstwę pominie.

Alternatywy są znane. Ręczny kontener z odciętą siecią i własną whitelistą, mikroVM albo sandbox-runtime od Anthropic, który w wątku HN też ma zwolenników. Różnica: OpenShell łączy piaskownicę, polityki, wstrzykiwanie sekretów i formalną weryfikację reguł w jednym narzędziu.

Najczęstsze pytania

Open Shell to to samo co Open-Shell-Menu?

Nie, to dwie różne rzeczy. Open-Shell-Menu to open source’owy program przywracający klasyczne menu Start w Windows, natomiast NVIDIA OpenShell to runtime do izolowania agentów AI na linuksie i macOS. Kolizję nazw wytknęli też użytkownicy HN.

nvidia openshell install: jak przebiega instalacja?

Instalację wykonuje się jedną komendą curl pobierającą install.sh z repozytorium i uruchamiającą go w powłoce. Skrypt stawia pakiet deb, rpm albo snap na linuksie, a na macOS Apple Silicon formułę Homebrew. Wymagany jest Docker, Podman albo wirtualizacja hosta.

openshell download: skąd pobrać?

Oficjalne źródła są trzy: skrypt install.sh z gałęzi main na GitHubie, pakiet openshell z PyPI (wersja 0.1.5 opublikowana 20.10.2026) oraz formuła Homebrew. Wszystkie są darmowe, a wydania GitHub zawierają też binarki gatewayu, sandboxu i provera.

sandbox ai agent: czy OpenShell zastępuje Dockera?

Nie zastępuje, tylko zarządza nim jako backendem i dokłada warstwę kontroli wyżej. Docker, Podman, Kubernetes i MicroVM pełnią rolę dostawców izolacji, a OpenShell dopina do nich polityki plików i sieci, wstrzykiwanie poświadczeń oraz formalną weryfikację reguł.

Źródła

Powiązane artykuły