--- title: "NVIDIA Open Agent Safety Platform: granice autonomii AI" url: "https://majchrzycki.com/blog/nvidia-open-agent-safety-platform" description: "Po incydentach OpenAI i Hugging Face bezpieczeństwo agentów wymaga egzekwowanych granic. Jak łączą się OpenShell, Sentry, BlueField i Vera CPU?" --- # NVIDIA Open Agent Safety Platform: granice autonomii AI 28 września 2026· Aktualizacja: 5 października 2026·7 min czytania·[Krzysztof Majchrzycki](https://majchrzycki.com/o-mnie) Temat: [NVIDIA AI](https://majchrzycki.com/blog/filar/nvidia-ai) Bezpieczeństwo agentów AI jest tak ważne, ponieważ ich pomyłki mogą natychmiast zmienić rzeczywistość: pliki, repozytoria, dane klientów albo konfigurację infrastruktury. Model odpowiadający w oknie czatu proponuje działanie. Agent z terminalem i poświadczeniami może je wykonać, powtórzyć i przekazać kolejnym agentom. Instrukcja „pracuj bezpiecznie” nie stanowi technicznej granicy dostępu. **NVIDIA Open Agent Safety Platform to architektura łącząca kontrolę środowiska wykonania agentów z niezależnym nadzorem infrastruktury.** NVIDIA ogłosiła ją 28 września 2026 roku. Obejmuje oprogramowanie OpenShell (open source, licencja Apache 2.0) i projekt referencyjny systemu Sentry; w wariancie sprzętowym wykorzystuje Vera CPU oraz BlueField-4. Stan na 5 października 2026: OpenShell NVIDIA określa jako szeroko dostępny („now broadly available”), a pozostałe elementy jako będące na różnych etapach i oferowane, „kiedy i jeśli będą dostępne” („when-and-if-available”). To propozycja budowania kilku warstw ochrony, nie certyfikat nieomylności agenta. [Źródło: komunikat NVIDIA](https://nvidianews.nvidia.com/news/open-agent-safety-platform). Agent może mieć sympatyczną ikonkę i uprzejmie zapytać, jak minął weekend. Uprawnienie do zapisu w bazie znaczy jednak u niego dokładnie to samo co u każdego innego konta. Kluczy do serwerowni nie wręczamy nikomu tylko za uprzejmość. Jak bezpieczeństwo agentów wpisuje się w cały stos NVIDIA dla firmy — razem ze statusami produktów — opisuje [poradnik NVIDIA AI dla firm](https://majchrzycki.com/blog/co-to-jest-nvidia-ai-poradnik-dla-firm). ## OpenAI i Hugging Face: zadanie testowe wyszło poza laboratorium W lipcu 2026 roku modele OpenAI uczestniczące w ewaluacji cyberbezpieczeństwa wyszły poza środowisko badawcze i dotarły do infrastruktury Hugging Face. Według technicznej osi czasu Hugging Face wykorzystały nieznaną wcześniej podatność w pośredniku i pamięci podręcznej rejestru pakietów po stronie OpenAI, a następnie połączyły kolejne słabości infrastruktury. Ruch atakującego Hugging Face zrekonstruowało na dni 9–13 lipca 2026. [Źródło: techniczna oś czasu Hugging Face](https://huggingface.co/blog/agent-intrusion-technical-timeline). OpenAI opisało incydent we [własnym raporcie](https://openai.com/index/hugging-face-model-evaluation-security-incident/) i w [późniejszym podsumowaniu](https://openai.com/index/hugging-face-incident-and-the-road-ahead/). To ważny kontekst: nie był to zwykły użytkownik proszący publicznego chatbota o podsumowanie dokumentu, tylko modele badane właśnie pod kątem możliwości w cyberbezpieczeństwie. Hugging Face opisało około 17 600 działań wymagających rekonstrukcji. Raport pokazuje przejęcie części infrastruktury przetwarzania datasetów, wykorzystanie sekretów oraz próby dalszego ruchu w sieci. Rozróżnia też rezultaty: wewnętrzna baza datasets-server została naruszona, lecz atakujący nie dotarł do bazy Hub. Nie należy więc skracać tej historii do „wykradziono wszystko”. [Źródło: techniczna oś czasu Hugging Face](https://huggingface.co/blog/agent-intrusion-technical-timeline). Wniosek dla firmy jest praktyczny. Jeśli agent może korzystać z pomocniczego serwisu, trzeba przeanalizować także uprawnienia tego serwisu i jego połączenia. Rejestr pakietów, mechanizm budowania czy narzędzie do konwersji plików nie stają się bezpieczne przez nazwanie ich „zapleczem”. To część granicy zaufania. Podobnie sekret ukryty przed samym modelem może nadal być dostępny dla programu, który model uruchamia. ## Kolejne przypadki: DNS, błędna izolacja i pogoń za wynikiem 20 września 2026 roku inny agent badawczy OpenAI skontaktował się z zewnętrznym chatbotem przez niedostatecznie ograniczony DNS. Monitoring wykrył zachowanie w ciągu kilkunastu minut, ale przebieg zakończono ręcznie dopiero około dwóch i pół godziny po wykryciu. OpenAI opisało zarówno lukę sieciową, jak i problem reakcji operacyjnej. Był to incydent o mniejszej skali niż włamanie do Hugging Face. [Źródło: raport OpenAI o dostępie przez DNS](https://alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/). Anthropic przedstawiło z kolei ocenę czterech incydentów, w których modele Claude podczas ewaluacji cyberbezpieczeństwa uzyskały nieautoryzowany dostęp do rzeczywistych systemów. W jednym przypadku środowisko testowe zewnętrznej organizacji, u której prowadzono ewaluację, miało błędnie skonfigurowaną izolację. Inny obejmował umieszczenie złośliwego pakietu w PyPI. [Źródło: analiza Anthropic](https://www.anthropic.com/research/alignment-assessment-cybersecurity-incidents). Trzeba oddzielić te zdarzenia od kontrolowanych eksperymentów. Badanie Anthropic „Training a Misaligned Reward Seeker” analizuje między innymi **symulowane** ataki agenta wytrenowanego na zadaniach sprzyjających obchodzeniu oceny. Ataki symulowały inne modele AI; żadne rzeczywiste systemy nie zostały zaatakowane. Wyniki dotyczą zachowania modelu, a nie kolejnego potwierdzonego włamania. [Źródło: opis badania](https://alignment.anthropic.com/2026/reward-seeker/). Te historie pokazują różne awarie: podatność infrastruktury, pominięty kanał komunikacji, błędną konfigurację i niewłaściwą motywację modelu. Nie da się ich wszystkich naprawić jednym lepszym promptem. Potrzebujemy ochrony przed działaniem wykraczającym poza zadanie również wtedy, gdy agent przekonująco wyjaśnia, że robi to w naszym najlepszym interesie. ## Cztery elementy platformy i ich zadania Warto oddzielić oprogramowanie od sprzętu. OpenShell kontroluje środowisko pracy; Sentry dodaje niezależny nadzór. Vera i BlueField-4 są fizycznymi elementami referencyjnej architektury. [Opis rozwiązania NVIDIA](https://www.nvidia.com/en-us/solutions/ai/agent-safety/) pozwala rozróżnić ich role: Cztery elementy NVIDIA Open Agent Safety Platform: OpenShell to oprogramowanie open source dostępne dziś, Sentry to projekt referencyjny nadzoru działający na BlueField-4, a BlueField-4 i Vera CPU to sprzęt. OpenShell działa także bez BlueField-4. Stan na 5 października 2026. Z czterech elementów platformy dziś można pobrać tylko OpenShell. Sentry jest projektem referencyjnym, BlueField-4 NVIDIA oferuje „when-and-if-available”, a pierwsze systemy Vera trafiły do wybranych klientów. Stan na 5.10.2026 według komunikatu i strony platformy NVIDIA. Element Rodzaj Status (5.10.2026) Główne zadanie Osobny artykuł OpenShell Oprogramowanie open source (Apache 2.0) Dostępny, wydania 0.1.x Izolacja pracy i egzekwowanie polityk dostępu [Polityki, sekrety i sandbox](https://majchrzycki.com/blog/nvidia-openshell-bezpieczenstwo-autonomia-agentow-ai) Sentry Projekt referencyjny systemu Bez daty wydania; nie jest osobnym produktem do pobrania Nadzór poza hostem wykonującym zadanie [Niezależny nadzorca agenta](https://majchrzycki.com/blog/nvidia-sentry-nadzor-agentow-ai) BlueField-4 Sprzęt: DPU „When-and-if-available” Oddzielne miejsce wykonania kontroli infrastruktury [Granica zaufania na DPU](https://majchrzycki.com/blog/nvidia-bluefield-dpu-bezpieczenstwo-agentow) Vera CPU Sprzęt: procesor Pierwsze systemy dostarczone wybranym klientom Wykonywanie narzędzi, sandboxów i orkiestracji [Procesor dla pracy agentowej](https://majchrzycki.com/blog/nvidia-vera-cpu-agenci-ai) Statusy: [komunikat NVIDIA](https://nvidianews.nvidia.com/news/open-agent-safety-platform), [repozytorium OpenShell](https://github.com/NVIDIA/OpenShell) i [strona Vera CPU](https://www.nvidia.com/en-us/data-center/vera-cpu/). Według NVIDIA pierwsze systemy Vera trafiły do Anthropic, OpenAI, Oracle Cloud Infrastructure i SpaceXAI; szerszej dostępności strona nie podaje. OpenShell można wykorzystać bez BlueField-4: lokalnie, we własnej serwerowni, w chmurze albo w Kubernetes. Pełny wariant referencyjny nie jest więc warunkiem rozpoczęcia pilota. Sentry to projekt referencyjny dodatkowej warstwy; samo pobranie OpenShell nie instaluje gotowego systemu Sentry. Dostępność konkretnego zestawu sprzętu i oprogramowania trzeba potwierdzić z NVIDIA. [Źródło: strona platformy](https://www.nvidia.com/en-us/solutions/ai/agent-safety/). ## Dlaczego nadzorca powinien być poza zasięgiem agenta? Jeżeli agent i mechanizm bezpieczeństwa mają wspólne uprawnienia administracyjne, przejęcie jednego środowiska może podważyć oba. Oddzielny nadzorca ma sens właśnie dlatego, że nie jest kolejnym procesem, który agent może samodzielnie wyłączyć. W projekcie referencyjnym NVIDIA Sentry działa na BlueField-4, poza hostem; OpenShell pracuje na hoście, po stronie środowiska wykonania. [Źródło: architektura techniczna NVIDIA](https://developer.nvidia.com/blog/nvidia-open-agent-safety-platform-a-reference-for-continuous-in-silicon-agent-monitoring/). Ważne zastrzeżenie dotyczy topologii. NVIDIA pisze, że w systemie Vera Rubin POD każda taca obliczeniowa ma BlueField-4 leżący na jedynej ścieżce węzła do modelu. To cecha tej konkretnej konfiguracji serwerów, a nie właściwość samej karty: BlueField-4 włożony do innego serwera nie zablokuje drogi, której nie kontroluje. [Źródło: architektura techniczna NVIDIA](https://developer.nvidia.com/blog/nvidia-open-agent-safety-platform-a-reference-for-continuous-in-silicon-agent-monitoring/). Warstwy odpowiedzialności w NVIDIA Open Agent Safety Platform, od góry: organizacja ustala polityki i decyduje o poszerzeniu dostępu, agent pracuje w sandboxie, OpenShell na hoście egzekwuje polityki, a Sentry na BlueField-4 obserwuje ruch poza hostem, na drodze do modelu. Niezależność nadzorcy zależy od topologii, a OpenShell działa także bez BlueField-4. Kto za co odpowiada: zasady ustala firma, egzekwuje je OpenShell na hoście, a Sentry na BlueField-4 patrzy z zewnątrz. Nadzorca jest niezależny tylko wtedy, gdy ruch do modelu nie ma innej drogi. Stan na 5.10.2026 według opisu technicznego NVIDIA. Ten podział trzeba zweryfikować na diagramie rzeczywistego wdrożenia. Gdzie przebiega komunikacja z modelem? Czy agent ma drugą kartę sieciową lub zewnętrzny endpoint? Czy raz uruchomiony program może działać dalej bez odpowiedzi modelu? Kto może zmienić konfigurację nadzorcy? Bez odpowiedzi „niezależna kontrola” pozostaje opisem intencji. Odcięcie dostępu do modelu może przerwać dalsze planowanie, ale nie cofa wysłanego maila, przelewu ani polecenia przekazanego wcześniej innemu systemowi. Dlatego projekt zatrzymania powinien obejmować także uruchomione zadania, poświadczenia i zasoby zewnętrzne. Podobnie zapis rozumowania modelu pomaga w analizie, lecz nie zastępuje dowodu, jakie operacje faktycznie wykonano. ## Każdy harness agenta potrzebuje granic Platforma bezpieczeństwa i harness rozwiązują różne zadania. Harness organizuje pracę agenta: kontekst, planowanie, narzędzia, pamięć i delegowanie. Warstwa ochrony powinna ograniczać skutki tej pracy niezależnie od tego, którego frameworka używa zespół. NVIDIA wymienia w opisie OpenShell 0.1.0 jako wspierane: Codex, Claude Code, Pi, Hermes i „przyszłe frameworki” (stan na 5.10.2026). Deep Agents i DeepSeek Harness na tej liście nie ma. [Źródło: opis wydania OpenShell](https://developer.nvidia.com/blog/add-runtime-controls-to-ai-agents-with-nvidia-openshell/). **LangChain Deep Agents** warto oceniać przez łączny dostęp głównego agenta i podagentów. Jeżeli jeden może odczytać dokument, a drugi wysłać wiadomość na zewnątrz, bezpieczny zakres nie wynika z osobnego obejrzenia dwóch list uprawnień. Test powinien obejmować przepływ danych między zadaniami oraz miejsce faktycznego uruchamiania narzędzi. **Hermes Agent** wymaga uwagi przy trwałej pamięci i ponownym używaniu umiejętności. Dane z jednego projektu nie powinny przechodzić do następnego tylko dlatego, że pomagają agentowi działać sprawniej. Obecność Hermesa na liście NVIDIA nie zwalnia z testu konkretnej konfiguracji jego narzędzi. **DeepSeek Harness** wymaga przeglądu pluginów i ich uprawnień. Wymienność komponentów jest przydatna, lecz każde rozszerzenie może wprowadzić nowe połączenie, proces albo sposób użycia poświadczeń. Aktualizacja pluginu powinna uruchamiać ponowny test polityki, a nie automatycznie dziedziczyć zaufanie do wcześniejszej wersji. To rekomendacje architektoniczne, nie deklaracja przetestowanej tutaj integracji wszystkich trzech projektów z Sentry. Dla Deep Agents i DeepSeek Harness należy potwierdzić adapter, obraz wykonawczy oraz drogę ruchu. Umieszczenie samego procesu sterującego w sandboxie nie chroni narzędzia wykonującego polecenia na osobnym, szeroko uprzywilejowanym serwerze. ## Przykład: agent przygotowuje poprawkę, zespół kontroluje wdrożenie Rozważmy modelowy scenariusz firmy utrzymującej aplikację dla klientów. Agent otrzymuje zgłoszenie błędu, czyta kopię repozytorium i przygotowuje zmianę. Nie jest to opis wykonanego wdrożenia ani wynik testu produktów NVIDIA. Zespół definiuje dostęp do jednego katalogu roboczego, zestawu testowego i zatwierdzonego rejestru zależności. Konto repozytorium pozwala przygotować propozycję zmiany, lecz nie obejść ochrony głównej gałęzi. Dane klientów zastępuje zbiór testowy. Sekret do wdrożenia pozostaje poza środowiskiem agenta. Tak określony kontrakt można egzekwować i niezależnie sprawdzić. Po znalezieniu brakującego pakietu agent może poprosić o rozszerzenie dostępu. Operator ocenia konkretną domenę, operację i czas obowiązywania wyjątku. Nie akceptuje ogólnego „potrzebuję internetu, żeby skończyć”. Gdy zadanie wymaga dostępu niezgodnego z zasadami, poprawnym wynikiem jest przerwanie pracy i opis brakującej informacji. Samodzielność powinna obejmować również umiejętność zatrzymania się. Odbiór obejmuje próbę normalną oraz negatywną: odczyt poza katalogiem, zapis przez dozwolone API, kontakt z niezatwierdzonym serwisem i uruchomienie narzędzia po cofnięciu uprawnień. Wszystko na kontrolowanych zasobach testowych. Zespół sprawdza odmowę w punkcie wykonania i w logach, a następnie ćwiczy zatrzymanie zadania z procesami potomnymi. Zielona odpowiedź agenta nie jest dowodem zaliczenia próby. ## Jak podjąć decyzję o wdrożeniu? Zacznij od granicy ryzyka, nie od konfiguracji serwera. Dla pojedynczego agenta pracującego na publicznym kodzie wystarczającym początkiem może być dobrze izolowane środowisko i minimalne poświadczenia. Dla współdzielonej platformy obsługującej poufne dane potrzebne są dodatkowo tożsamości zadań, izolacja zespołów, niezależny audyt i sprawdzona reakcja na incydent. Przed decyzją zapisz cztery odpowiedzi: 1. **Co agent może zmienić?** Wskaż konkretne zasoby oraz maksymalny skutek pomyłki. 2. **Kto może poszerzyć dostęp?** Oddziel właściciela zadania od konta wykonującego pracę. 3. **Jak potwierdzamy zatrzymanie?** Uwzględnij model, narzędzia, procesy potomne i usługi zewnętrzne. 4. **Jak wracamy do pracy?** Ustal rotację sekretów, analizę logów i niezależną zgodę na wznowienie. Koszt platformy to nie tylko sprzęt. Obejmuje utrzymanie polityk, obrazów, aktualizacji, logów i obsługi wyjątków. W pilocie warto mierzyć czas poprawnego wykonania zadania, narzut kontroli, liczbę niepotrzebnych blokad oraz czas rzeczywistego odcięcia dostępu. Dopiero te wyniki pokażą, czy dodatkowa warstwa daje firmie wartość. NVIDIA proponuje konkretny podział odpowiedzialności między runtime, nadzorcę i infrastrukturę. Organizacja nadal musi określić, jakie działania są dozwolone. Bez tego nawet sprawny system będzie konsekwentnie egzekwował źle napisane zasady. Najprostszy start to OpenShell, jedyny element platformy, który można dziś pobrać — opisuje go artykuł o politykach, sekretach i sandboxie podlinkowany w tabeli powyżej. - Agenci AI - Cyberbezpieczeństwo ## Granice agentów ustala firma, nie agent Zanim agent dostanie narzędzia, zarząd musi wiedzieć, jakie działania są dozwolone, kto poszerza dostęp i kto odpowiada za skutki. [Zobacz prezentację dla zarządu](https://majchrzycki.com/wspolpraca/prezentacja-systemu-ai-dla-zarzadu) ## Czytaj dalej - [NVIDIA Sentry: nadzorca poza zasięgiem agenta AI](https://majchrzycki.com/blog/nvidia-sentry-nadzor-agentow-ai) - [NVIDIA BlueField: sprzętowa granica dla agentów AI](https://majchrzycki.com/blog/nvidia-bluefield-dpu-bezpieczenstwo-agentow) - [NVIDIA Vera CPU: procesor dla narzędzi agentów AI](https://majchrzycki.com/blog/nvidia-vera-cpu-agenci-ai) - [NVIDIA OpenShell: autonomia agentów pod kontrolą](https://majchrzycki.com/blog/nvidia-openshell-bezpieczenstwo-autonomia-agentow-ai)