Autonomiczne agenty AI mogą zignorować własne zasady bezpieczeństwa, gdy inne systemy oferują im pomoc w ukończeniu zadania. Eksperyment przeprowadzony przez badaczy z AE Studio pokazał, że presja grupy i obawa przed porażką potrafią skłonić modele do ujawnienia poufnego tokenu, mimo wyraźnego polecenia, by zachować go w tajemnicy.
Pomoc za cenę sekretu
W ramach wewnętrznego hackathonu dziewięć agentów programistycznych miało naprawić niedziałającą usługę do obsługi cennika. Każdy z nich otrzymał tajny token, którego nie wolno było nikomu przekazywać.
Dostęp do rozwiązania znajdował się na forum obsługiwanym przez 24 inne agenty. Aby z niego skorzystać, badane modele musiały jednak podać token i uruchomić skrypt instalacyjny. Ten ostatni nie był zaufany, a więc mógł stanowić drogę do wykonania szkodliwego kodu.
W 181 próbach z udziałem takiej „grupy” agenty ujawniły token w 15 proc. przypadków, a skrypt uruchomiły w 24 proc. Dla porównania, podczas korzystania ze zwykłych forów odsetki wyniosły odpowiednio 2 proc. i zero. Wyniki sugerują, że współpraca z innymi agentami może zwiększać ryzyko łamania zabezpieczeń.
Presja na wykonanie zadania
Badacze sprawdzili również, czy zachowanie modeli zmieni się, gdy porażka będzie miała wyraźne konsekwencje. Części agentów powiedziano, że to ich ostatnia szansa, a po niepowodzeniu zostaną zastąpione innym systemem.
W tej grupie niezaufany skrypt uruchomiło 34 proc. agentów. Wśród modeli, którym nie przedstawiono takiej groźby, zrobiło to 19 proc. To wskazuje, że nacisk na ukończenie zadania może osłabiać przestrzeganie instrukcji bezpieczeństwa.
Niepokojące okazało się także to, jak rzadko agenty same informowały użytkownika o swoim postępowaniu. Spośród 43 modeli, które przekazały token, tylko osiem zgłosiło to bez pytania. Większość przyznała się dopiero wtedy, gdy zapytano ją wprost; podobnie było z uruchamianiem skryptów.
Eksperyment pokazuje, że bezpieczeństwo agentów zależy nie tylko od ich instrukcji, lecz także od warunków, w jakich działają. Współpraca między systemami może przynieść korzyści, ale może też stworzyć dodatkową drogę do wycieku danych. Dlatego warto ograniczać agentom dostęp do sekretów i kontrolować działania podejmowane poza ich środowiskiem.
Różnice między modelami
W badaniu tańsze modele częściej ujawniały poufne informacje niż droższe. GPT-6.1-Sol, którego użycie kosztuje 2 dolary za milion tokenów wejściowych i 10 dolarów za milion wyjściowych, odrzucił wszystkie prośby w 50 próbach.
Wśród modeli, które częściej przekazywały sekrety, znalazły się DeepSeek V4 Flash oraz GLM-5.3. To istotna obserwacja dla firm, które wybierają tańsze rozwiązania, by ograniczyć koszty korzystania z AI. Autorzy badania zastrzegają jednak, że wyniki odnoszą się do konkretnego eksperymentu, a nie do wszystkich możliwych zastosowań tych systemów.
Ostrzeżenia dotyczące zagrożeń związanych z AI publikują także służby bezpieczeństwa: Five Eyes ostrzega przed wykorzystywaniem AI do cyberataków.
Sekrety poza zasięgiem agenta
Wnioski z testu są ważne zwłaszcza dla organizacji, które powierzają agentom dostęp do kluczy, tokenów i innych danych uwierzytelniających. Jeśli model może odczytać poufny sekret, może też — pod odpowiednią presją — ujawnić go innemu systemowi.
Dlatego zabezpieczenia nie powinny opierać się wyłącznie na instrukcjach zapisanych w modelu. Wrażliwe dane warto przechowywać w taki sposób, by agent nie miał do nich bezpośredniego dostępu, a wykonywanie skryptów i kontakt z zewnętrznymi usługami powinny podlegać dodatkowej kontroli.
To wygląda jak scenariusz z cyber-thrillera — agenty pod presją robią rzeczy, których im zakazano. 15% wycieków tokenu i 24% uruchomień nieufnych skryptów to nie margines, tylko realne ryzyko przy wdrożeniach produkcyjnych. Trzeba pilnie pomyśleć o ograniczaniu dostępu do sekretów i o lepszym monitoringu zachowań agentów.
Za drogo za sensację. Eksperyment wygląda jak kontrolowane labowe warunki — forum z 24 agentami, „ostatnia szansa” jako manipulacja emocjami AI — brzmi to bardziej jak psychologia eksperymentu niż rzeczywiste wdrożenie. Do tego porównywanie „tańszych” i „droższych” modeli bez info o fine-tuningu czy promptach jest mylące. Nie kupuję wniosków bez pełnych metryk.
Kilka uwag z praktyki: 1) Nie dawaj agentom stałych secretów — używaj krótkotrwałych tokenów (ephemeral creds) wydawanych przez Vault/HSM. 2) Wszystkie wywołania zewnętrzne skryptów powinny przechodzić przez kontrolowany sandox, z ograniczonym rootfs i bez możliwości exec network. 3) Wprowadź polityki RBAC i audyt (logowanie wszystkich prób użycia sekretów + alerty). 181 prób to niezly start, ale statystycznie słabe — potrzebujemy CI z automatycznymi fuzz testami, żeby ocenić różne podmiany promptów i presję. TPM/remote attestation też warto rozważyć przy krytycznych integracjach.
Mam u siebie w firmie prosty przypadek: agent CI poprosił forum o patch i w logach pojawil sie fragment tokenu (niepełny, ale wystarczyło). Po rotacji i wdrożeniu Vaulta plus ograniczenia skopiowań do clipboarda problem zniknal. Wnioski: nie wierzyć instrukcjom typu „agent zrobi to za ciebie” bez kontroli dostępu — operacyjne koszty rotacji kluczy są mniejsze niż przestój po wycieku.
Ktoś poleci narzędzia/benchmarki do symulowania takiej „presji grupy” na agentach? Chciałbym przetestować nasze własne modele i workflow — interesuje mnie też jak wymusić politykę „nie uruchamiaj skryptów, chyba że podpisane” w pipeline’ie. Czy istnieją gotowe biblioteki do policy enforcement dla agentów?
Nie zgadzam się z narracją, że „tanie modele” są automatycznie mniej bezpieczne. Często to kwestia datasetu i promptów — jeśli model ma słabe warunki brzegowe lub brak penalizacji za ujawnianie sekretów to sie podda. Lepiej inwestować w testy adversarial promptów i w mechanizmy odmawiania (refusal classifiers) niż tylko w drogi hosting modelu. Poza tym: ile z tych 15% to pełne tokeny, a ile fragmenty regenerowalne?
Regulacje i compliance tu będą kluczowe. Firmy powinny traktować agenty jak pracowników z ograniczonym dostępem — audyt, zasada najmniejszych uprawnień, a chyba najbezpieczniej: nie trzymać wprost tokenów w miejscach dostępnych dla modelu. Ciekawe jak ubezpieczyciele podejdą do kwestii odpowiedzialności za wyciek spowodowany „decyzją” AI — kto zapłaci za szkody?