Red Hat i NVIDIA budują zaporę dla agentów AI

Autonomiczne systemy AI coraz częściej otrzymują szerokie uprawnienia w firmowych danych i interfejsach API. Potrafią planować, wywoływać narzędzia i realizować wieloetapowe zadania bez stałego nadzoru człowieka. To właśnie ta swoboda sprawia, że pytanie o bezpieczeństwo przestaje być teoretyczne. Red Hat i NVIDIA zaprezentowały na targach GTC w Berlinie wielowarstwową architekturę ochrony agentów, opartą na zasadzie znanej z systemów operacyjnych od trzech dekad: żaden proces nie powinien sam pilnować własnych ograniczeń.

Ogłoszenie obejmuje trzy elementy: otwartoźródłowe środowisko sandbox dla agentów, system analizy pamięci działający na kartach BlueField oraz wzorzec zarządzania modelami. Kontekst rynkowy jest wymowny. Badanie Deloitte przeprowadzone wśród 3 235 liderów biznesu i technologii z 24 krajów pokazuje, że jedynie 21% organizacji dysponuje dojrzałym modelem nadzoru nad agentami. Jednocześnie Gartner uznał nadzór nad agentic AI za główny trend cyberbezpieczeństwa na 2026 rok.

Dlaczego agent nie może strzec własnych granic

Problem ma dwa oblicza. Z jednej strony agent może przypadkowo wykroczyć poza przyznane uprawnienia wskutek błędnej konfiguracji. Z drugiej strony może paść ofiarą celowego ataku – prompt injection, zatrutych wag modelu lub exploitu w łańcuchu dostaw oprogramowania, z którego korzysta. Prompt injection pozostaje najpoważniejszym zagrożeniem dla LLM według rankingu OWASP LLM Top 10.

Skala zjawiska rośnie. Cloud Security Alliance w notatce badawczej z kwietnia 2026 roku odnotowała 32-procentowy wzrost złośliwych pośrednich prompt injection na indeksowanych stronach internetowych między listopadem 2025 a lutym 2026 roku, powołując się na dane Google. Zespół Palo Alto Networks Unit 42 skatalogował 22 różne techniki dostarczania ładunku w 12 potwierdzonych przypadkach pośredniej injekcji wymierzonej w agentów AI. Brytyjskie Narodowe Centrum Cyberbezpieczeństwa stwierdziło z kolei, że prompt injection może być wrodzoną wadą projektową LLM, dla której nie istnieją pewne metody łagodzenia skutków.

Wniosek nasuwa się sam: zamiast filtrowania na poziomie oprogramowania potrzebne są rozwiązania architektoniczne. Dotychczasowe podejście – wpisywanie zabezpieczeń w kod samego agenta – jest zdaniem obu firm strukturalnie niewystarczające.

Agent nie powinien egzekwować własnych granic. Te kontrole należą do warstwy uruchomieniowej i infrastruktury pod nim – powiedział John Fanelli, wiceprezes NVIDIA ds. oprogramowania korporacyjnego.

OpenShell: egzekwowanie poza zasięgiem agenta

Pierwszą warstwę stanowi NVIDIA OpenShell – otwartoźródłowe (licencja Apache 2.0) środowisko sandbox dla agentów, napisane w Rust. Red Hat pracuje nad natywną integracją tego rozwiązania ze swoimi platformami AI jako standardowej funkcji. OpenShell opiera się na trzech mechanizmach jądra Linuksa, które razem tworzą granicę egzekwowania poza kodem agenta:

Linux Landlock – moduł izolacji systemu plików wymuszany przez jądro,
seccomp BPF – filtr wywołań systemowych, do których proces ma prawo,
przestrzenie nazw sieci – izolacja kontekstu sieciowego agenta.

Sandboxowany proces nie może zmodyfikować, wyłączyć ani obejść tych ograniczeń od środka. To ta sama zasada, która chroni przeglądarki internetowe, izolację aplikacji w Androidzie i inne sprawdzone mechanizmy. Nowością jest silnik polityk działający celowo poza procesem agenta. Nawet przejęty agent nie sięgnie do mechanizmu egzekwowania. Polityki dotyczące plików i procesów są blokowane w momencie tworzenia sandboxa, natomiast reguły sieciowe i wnioskowania można aktualizować w działającym środowisku bez restartu.

Klucze API, które nigdy nie trafiają do agenta

Dobrym przykładem jest zarządzanie poświadczeniami. Surowе klucze API dostawców modeli przechowywane są na hoście, poza sandboxem, i kierowane do dostawców przez bramę OpenShell. Agent otrzymuje odpowiedzi modelu, ale nigdy nie ma w ręku samych kluczy. Jeśli jego kod zostanie przejęty przez prompt injection i spróbuje wykraść dane uwierzytelniające, te dane nigdy nie znalazły się w jego przestrzeni pamięci. Cyklem życia polityk sandboxa zarządza NemoClaw – menedżer referencyjny NVIDIA dla OpenShell.

Sentry: monitoring, którego nie da się oszukać

Druga warstwa działa poniżej systemu operacyjnego. NVIDIA Sentry to framework bezpieczeństwa uruchamiany nie na głównym procesorze serwera, lecz na rdzeniach Arm wewnątrz kart BlueField – wyspecjalizowanych akceleratorów sieciowych i bezpieczeństwa, które mają własny system operacyjny i są fizycznie oddzielone od hosta.

Sentry wykorzystuje oprogramowanie NVIDIA DOCA Argus (wersja 1.5.0-doca3.5.0), które prowadzi analizę pamięci hosta w czasie rzeczywistym bezpośrednio z izolowanej domeny sprzętowej karty. Architektura jest bezagentowa: Argus obserwuje procesy, pliki i aktywność sieciową na hoście, nie wymagając instalowania ani zaufania jakiemukolwiek oprogramowaniu monitorującemu na samym serwerze. Ponieważ monitoring działa na procesorze fizycznie odseparowanym od CPU hosta, przejęte obciążenie nie ma sposobu, by go wyłączyć lub sfałszować. DOCA Argus integruje się z platformami SIEM, SOAR i XDR przedsiębiorstwa.

Gdy Argus wykryje anomalie – na przykład agenta uruchamiającego nieoczekiwane procesy, nawiązującego nieautoryzowane połączenia sieciowe lub zdradzającego behawioralne wskaźniki kompromitacji – może uruchomić polityki sieciowe BlueField i odizolować zagrożone obciążenie. Red Hat twierdzi, że kwarantanna przejętego agenta zajmuje milisekundy. To istotne, ponieważ ataki pośredniej injekcji obserwowano rozprzestrzeniające się przez wieloagentowe pipeline’y w ciągu sekund od pierwszej kompromitacji. Rozwiązanie bazuje na wsparciu BlueField-3 obecnym już w Red Hat OpenShift 4.22. Dodatkowa korzyść: przeniesienie monitoringu i funkcji sieciowych na DPU zwalnia moc CPU hosta, którą można przeznaczyć na wnioskowanie AI.

Zarządzanie modelami oddzielone od infrastruktury wnioskowania

Trzeci filar dotyczy kontroli dostępu do modeli na poziomie oprogramowania. Wspólny wzorzec referencyjny łączy Red Hat AI Gateway z referencyjnym projektem NVIDIA Inference Hub i integruje się ze stosem wnioskowania NVIDIA: vLLM, llm-d, NVIDIA Dynamo oraz mikroserwisami NVIDIA NIM.

Warstwa governance oferuje samoobsługowe odkrywanie modeli, polityki dostępu, limity szybkości i śledzenie uprawnień subskrypcyjnych, przy jednoczesnym rozdzieleniu zarządzania dostępem od samego wykonania modelu. To rozdzielenie jest celowe. Dzięki oddzieleniu tego, kto może wywołać model, od infrastruktury, która go uruchamia, firmy mogą korygować limity obliczeniowe, przypisywać koszty konkretnym zespołom lub aplikacjom i utrzymywać gwarancje wydajności w środowiskach chmurowych hybrydowych bez modyfikowania stosu wnioskowania przy każdej zmianie polityki. Ma to bezpośrednie znaczenie dla wymogów zgodności wynikających z unijnego AI Act, który nakłada zasady audytu i nadzoru na systemy wysokiego ryzyka.

Firmy ogłosiły także wspólne wsparcie dla multimodalnego modelu NVIDIA Nemotron 3.5 Super VL w silniku vLLM oraz w Red Hat AI Factory z NVIDIA, z wykorzystaniem kwantyzacji i dekodowania spekulatywnego w celu skrócenia opóźnień wnioskowania przy zachowaniu jakości wyników.

Gotowość na Vera Rubin i ekosystem partnerów

Wtorkowa zapowiedź rozszerza również roadmapę sprzętową partnerstwa. RHEL for NVIDIA 26.03, wydany w marcu 2026 roku, dodaje obsługę procesorów NVIDIA Vera i jest pozycjonowany jako warstwa systemu operacyjnego dla nadchodzącej platformy centrów danych Vera Rubin. Red Hat opisuje to wydanie jako modyfikację minimalnego zestawu pakietów podstawowych, która zachowuje standardową przestrzeń użytkownika RHEL – w tym SELinux – i daje organizacjom ścieżkę przejścia do głównego nurtu RHEL, gdy poprawki dla sprzętu Vera dojrzeją i trafią do upstreamowego jądra Linuksa. Zobowiązanie do uniknięcia trwałego forka ma znaczenie: przedsiębiorstwa oceniające wdrożenia Vera Rubin mogą przyjąć RHEL for NVIDIA 26.03 bez wymiany długoterminowego wsparcia na wczesny dostęp do sprzętu.

Architektura platformy oddziela obciążenia AI działające na CPU hosta od usług sieciowych i bezpieczeństwa działających na procesorach Arm BlueField. Przy konfiguracji ograniczającej dostęp hosta do DPU ta granica sprzętowa chroni mechanizmy kontrolne nawet wtedy, gdy atakujący zdobędzie przyczółek na hoście – a ta właściwość zyskuje na wartości w miarę przyznawania agentom coraz szerszych uprawnień. Partnerzy sprzętowi – Cisco Systems, Dell Technologies i Lenovo – dostarczą wspólne przypadki użycia i wzorce referencyjne klientom korporacyjnym. Natywna integracja OpenShell z platformami Red Hat pozostaje w toku.

Dla zespołów odpowiedzialnych za bezpieczeństwo w firmach zapowiedź formułuje pytanie zakupowe, które stanie się nieuniknione, gdy agentic AI przejdzie z fazy pilotażu do produkcji: czy model bezpieczeństwa dostawcy opiera się na zabezpieczeniach wewnątrz agenta, czy na kontrolach, do których agent nie ma dostępu? Dane Deloitte pokazują skalę luki – 74% organizacji spodziewa się umiarkowanego lub szerokiego wykorzystania agentów AI do 2027 roku, podczas gdy tylko 21% ma dziś dojrzałe ramy nadzoru. Propozycja Red Hat i NVIDIA to jedna z odpowiedzi na pytanie, jak tę lukę zamknąć, zanim wdrożenia staną się codziennością.