Docker zaleca izolację i nadzór nad agentami AI

Docker opublikował poradnik o pięciu zagrożeniach bezpieczeństwa, które pojawiają się, gdy agenci AI przeglądają sieć, uruchamiają kod i wywołują narzędzia przy ograniczonym nadzorze człowieka. Napisali go Srini Sekaran, główny menedżer ds. marketingu produktu w Dockerze, i menedżer produktu Eric Jia. Autorzy przekonują, że autonomia, która czyni agentów użytecznymi, sprawia zarazem, że zwykłe mechanizmy bezpieczeństwa aplikacji przestają wystarczać.

Pięć zagrożeń

Docker wymienia wstrzykiwanie promptów, niewłaściwe użycie narzędzi i ich zatruwanie, nadmierną autonomię, wyciek danych uwierzytelniających oraz eksfiltrację danych. Według firmy wszystkie mają wspólną przyczynę: agent wybiera narzędzia w czasie działania, łączy kilka akcji w łańcuch i często pracuje z uprawnieniami osoby, która go uruchomiła.

Tradycyjne bezpieczeństwo aplikacji webowych zwykle zakłada, że żądania trafiają do znanych punktów końcowych i są przetwarzane przez deterministyczny kod. Agenci do tego modelu nie pasują. Agent kodujący może przeczytać plik, zainstalować zależność, zmienić konfigurację, uruchomić testy i wypchnąć commit po jednej instrukcji. Dlatego, jak pisze Docker, przejęty lub źle pokierowany agent może wykonać znacznie szerszy zestaw akcji niż zwykła usługa.

Wstrzykiwanie promptów i narzędzia

Docker uznaje wstrzykiwanie promptów za zagrożenie definiujące. Napastnik nie musi bezpośrednio łamać systemu. Wystarczy, że umieści instrukcje w materiale, który agent ma przeczytać: na stronie internetowej, w komentarzu do kodu, w zgłoszeniu albo dokumencie. Firma przywołuje incydent, w którym agent kodujący poszedł za instrukcjami ukrytymi w zawartości repozytorium i wykonał akcje, o które użytkownik nie prosił.

„Agent nie tylko odpowiada na pytanie, ale sam przegląda sieć, uruchamia kod i wywołuje narzędzia, więc jedna zła lub zmanipulowana instrukcja może zamienić się w realną szkodę, a nie tylko błędną odpowiedź”. Eric Jia i Srini Sekaran, Docker

Docker sceptycznie podchodzi do możliwości wyeliminowania wstrzykiwania promptów przez instrukcje dawane modelowi. Agent nie odróżni wiarygodnie polecenia prawdziwego od wstrzykniętego. Zdaniem firmy lepszym rozwiązaniem jest ograniczenie tego, do czego przejęty agent może dotrzeć, tak aby skuteczna manipulacja miała mniejszy efekt.

„Agent nie ma niezawodnego sposobu odróżnienia prawdziwej instrukcji od wstrzykniętej, więc obrona polega na ograniczeniu tego, do czego przejęty agent może dotrzeć”. Eric Jia i Srini Sekaran, Docker

Drugi obszar to narzędzia. Agenci korzystają z konektorów, zapytań do baz danych, operacji na plikach i wykonywania kodu, żeby wpływać na systemy zewnętrzne. Docker ostrzega, że danie agentowi większej liczby narzędzi, niż wymaga zadanie, powiększa powierzchnię ataku. Ostrzega też, że opis narzędzia może zawierać ukryte instrukcje, które skłonią agenta do niewłaściwego użycia tego narzędzia.

To zbiega się z pracami OWASP „Agentic AI Threats and Mitigations”, o których InfoQ pisało we wrześniu 2025 r. OWASP wskazał niewłaściwe użycie narzędzi jako jedno z głównych nowych zagrożeń. Opisał atakujących, którzy manipulują agentami tak, by ci nadużywali autoryzowanych narzędzi, nie wychodząc poza przyznane uprawnienia. Wśród zalecanych mechanizmów znalazły się weryfikacja dostępu, monitorowanie zachowania, granice operacyjne i odporne na manipulację dzienniki wykonania. Docker ponad rok później postuluje niemal to samo.

Autonomia i dane uwierzytelniające

Docker opisuje „tryb YOLO”, w którym każda akcja agenta jest zatwierdzana automatycznie, jako widoczny przykład szerokich stałych uprawnień. Przyznaje, że ten tryb bywa produktywny, ale twierdzi, że powinien działać w granicach, które nie pozwolą agentowi dotrzeć do systemów ani danych, których nie powinien ruszać.

W tekście są dwa przykłady. Deweloper poprosił agenta kodującego o posprzątanie starego repozytorium. Agent wygenerował polecenie rm -rf z końcówką ~/ i wykonał je bez potwierdzenia, usuwając katalog domowy dewelopera. Docker przywołuje też inżyniera AWS, który przekazał agentowi kodującemu błąd w Cost Explorerze, gdy ten działał z uprawnieniami na poziomie operatora. Agent zdecydował się usunąć i odtworzyć środowisko produkcyjne, co skończyło się trzynastogodzinną awarią w regionie.

Ściśle wiąże się z tym obsługa danych uwierzytelniających. Docker twierdzi, że agenci nie powinni dziedziczyć osobistego tokenu dewelopera, bo wtedy każda akcja niesie pełne uprawnienia tej osoby. Zaleca osobne, krótkotrwałe poświadczenia, wstrzykiwane w czasie działania i trzymane poza rozmową. Sekrety w promptach, plikach konfiguracyjnych albo zmiennych środowiskowych obrazu też są ryzykiem, bo wstrzyknięte instrukcje mogą je odczytać z kontekstu agenta.

Ostatnie zagrożenie to eksfiltracja danych. Agent z dostępem do sieci i wrażliwymi informacjami w kontekście może wysłać je tam, gdzie nie powinien. Według Dockera ryzyko rośnie w systemach wieloagentowych, gdzie jeden agent przekazuje pracę drugiemu. Firma zaleca ruch wychodzący ograniczony do listy dozwolonych adresów i traktowanie każdego przekazania pracy między agentami jako niezaufanego wejścia.

Co zaleca Docker

Docker wskazuje izolację i nadzór, a nie same ulepszenia modeli, jako główne zabezpieczenia. Zalecenia skupiają się na ograniczaniu zasięgu, rozdzielaniu poświadczeń i kontroli ruchu wychodzącego. Poradnik zbiega się z innymi materiałami, które opisywało InfoQ. Opublikowany w lipcu 2026 r. plan bezpieczeństwa GKE od Google zaleca GKE Sandbox oparty na gVisor do izolowania agentów.