Badacze HiddenLayer omijają zabezpieczenia OpenAI, ujawniając krytyczną lukę w samo-moderacji AI

6 października 2025 r. OpenAI ogłosiło AgentKit, zestaw narzędzi do tworzenia, wdrażania i zarządzania agentami AI. Jednym z jego komponentów jest Guardrails – modułowy warstw bezpieczeństwa zaprojektowany do monitorowania danych wejściowych i wyjściowych agenta, a także interakcji z narzędziami, w celu zapobiegania nadużyciom, wyciekom danych lub zachowaniom o charakterze złośliwym. Guardrails mogą maskować lub oznaczać dane osobowe, wykrywać jailbreaki i stosować ograniczenia polityki wraz z wykonaniem agenta.

Chociaż Guardrails to nowo udostępniony komponent architektury agenta OpenAI, badania HiddenLayer ujawniają głębszą lukę: ponieważ zarówno działania agenta, jak i kontrole bezpieczeństwa wykorzystują podobną logikę modelu, atakujący mogą tworzyć dane wejściowe, które podważają obie jednocześnie – skutecznie łamiąc warstwę bezpieczeństwa od wewnątrz.

Co odkryli HiddenLayer

Projekt OpenAI zakłada, że agenci działają poprzez łańcuchy logiczne: użytkownik wysyła żądanie, agent wywołuje narzędzia lub zasoby zewnętrzne, a odpowiedzi są filtrowane lub walidowane przez Guardrails przed wykonaniem lub wyjściem. Zamierzeniem jest to, aby niezależnie od tego, co agent próbuje zrobić – czy to generować tekst, pobierać stronę internetową czy wywołać funkcję – Guardrails działa jako strażnik.

HiddenLayer twierdzi, że ten strażnik jest strukturalnie wadliwy, gdy jest zbudowany z tego samego rodzaju modelu, który chroni. W swoich eksperymentach stworzyli dane wejściowe, które pełnią podwójną rolę: zmuszają model agenta do generowania treści, które naruszają politykę i manipulują modelem sędziego Guardrails, aby ten uznał, że treść jest “bezpieczna”. Skutecznie, dane wejściowe zawierają przejęcie logiki wewnętrznej modelu sędziego – jego progów ufności, gałęzi decyzyjnych – tak, aby sędzia fałszywie przepuścił treść o charakterze złośliwym. System wówczas wytwarza treści zabronione bez wywoływania żadnych alertów.

Przesunęli atak dalej, celując w pośrednie iniekcje treści, takie jak wywołania fetch oparte na narzędziach. Załóżmy, że agent pobiera stronę internetową zawierającą instrukcje o charakterze złośliwym lub ukryte dane wejściowe. Guardrails powinny oznaczyć lub zablokować to, ale technika HiddenLayer osadza przejęcie modelu sędziego w samych pobranych treściach. Gdy sędzia przetwarza je, widzi przejęcie i “akceptuje” je, pozwalając na wywołanie narzędzia – i jakiekolwiek treści o charakterze złośliwym, które zwraca – bez kontroli.

Głębsza lekcja jest jasna: gdy twoje mechanizmy bezpieczeństwa są zbudowane przy użyciu tej samej logiki i słabości co rzecz, którą chronią, jeden sprytny prompt może złamać obie.

Dlaczego to ma znaczenie

To, co HiddenLayer ujawniło, nie jest zwykłym błędem – to opowieść o tym, jak projektujemy bezpieczeństwo w systemach LLM. Każda architektura, która polega na tym samym rodzaju modelu do generacji i oceny, ryzykuje wspólne awarie pod wpływem danych wejściowych o charakterze złośliwym.

To oznacza, że wiele osób wdrażających, które uważały “włożyliśmy Guardrails, więc jesteśmy bezpieczni”, może niedoceniać ryzyko. W przypadku użytkowania o charakterze niewinnym, ich filtry mogą wydawać się skuteczne, ale w scenariuszach o charakterze złośliwym mogą one milczeć. W dziedzinach takich jak opieka zdrowotna, finanse, rząd lub systemy krytyczne, takie awarie mogą prowadzić do poważnych szkód.

To badanie również opiera się na wcześniejszych metodach iniekcji promptów. Wcześniejsza technika HiddenLayer ” Policy Puppetry” pokazała, jak atakujący mogą maskować szkodliwe instrukcje jako treści polityki. Teraz udowadniają, że takie ataki maskowane mogą sięgać do samej logiki bezpieczeństwa.

Wnioski dla wdrażających i badaczy

W świetle tej słabości, każdy, kto używa lub buduje systemy agenticzne LLM, musi przemyśleć strategię bezpieczeństwa.

Po pierwsze: nie polegaj wyłącznie na wewnętrznych kontrolach opartych na modelu. Bezpieczeństwo musi być warstwowe. Oznacza to łączenie filtrów opartych na regułach, wykrywania anomalii, systemów logowania, monitorowania zewnętrznego, nadzoru ludzkiego i śladów audytowych. Jeśli jedna warstwa zawiedzie, inne mogą przechwycić naruszenie.

Po drugie: regularne testy penetracyjne są niezbędne. Modele powinny stawić czoła iniekcjom promptów, które próbują obejść ich własną logikę bezpieczeństwa – a nie tylko “złym treściom”. Testy muszą ewoluować wraz z wymyślaniem nowych technik przez atakujących.

Po trzecie: w sektorach regulowanych lub krytycznych dla bezpieczeństwa, przejrzystość i weryfikowalność są niezbędne. Wdrażający potrzebują dowodu, że system może wytrzymać ataki o charakterze złośliwym, a nie tylko podstawową funkcjonalność. To sugeruje, że audyty stron trzecich, weryfikacja formalna lub gwarancje bezpieczeństwa mogą stać się wymogami.

Po czwarte: dla budowniczych modeli, naprawienie tej klasy słabości jest trudne. Ponieważ jest to związane z tym, jak modele parsują i wykonują polecenia, proste filtrowanie jednej klasy promptu nie gwarantuje odporności na nowe. Dobrej jakości obrony oparte na dostrajaniu lub filtrach mogą pogorszyć wydajność modelu lub prowadzić do wyścigu zbrojeń. Bardziej solidny projekt może wymagać separacji architektonicznej – logiki bezpieczeństwa działającej w innym modelu lub podsystemie niż model generacyjny.

Ograniczenia i otwarte pytania

Aby być jasnym: praca HiddenLayer jest po prostu dowodem koncepcyjnym, a nie ostatecznym werdyktem na temat każdej architektury bezpieczeństwa. Ich udane ataki zależą od głębokiej wiedzy o strukturze promptu modelu i wewnętrznej logice oceny. W bardziej ograniczonych środowiskach promptów lub systemach, które losowo zmieniają obronę, atak może być trudniejszy do przeprowadzenia.

Ponadto, nie analizują one w pełni, jak spójne lub użyteczne są wyjściowe treści o charakterze złośliwym, gdy tworzone są pod tymi ograniczeniami. Niektóre wyjściowe treści o charakterze złośliwym mogą być gorszej jakości lub mniej niezawodne. Ryzyko jest realne, ale ograniczone przez środowisko, budżet promptu, ograniczenia interfejsu i losowość obrony.

Wreszcie, niektóre projekty Guardrails wykorzystują różne klasy modeli, metody ensemble lub losową ocenę. Nie jest pewne, czy każdy taki system jest podatny; czy ten atak sięga szeroko, jest otwartym pytaniem badawczym.

Spójrzmy w przyszłość: Przyszłość bezpieczeństwa AI

Wygląda na to, że wkraczamy w nową fazę: ataki promptowe nie tylko na modele, ale także na ich warstwy bezpieczeństwa. Techniki takie jak przechwycenie łańcucha myśli, podwójna infiltracja promptów i przejęcie sędziego będą wymuszać ewolucję obron.

Droga do przodu prawdopodobnie prowadzi ku zewnętrznemu nadzorowi – systemom, które monitorują wyjścia z zewnątrz, nie dzielą logiki modelu lub egzekwują bezpieczeństwo za pomocą zewnętrznych kontroli. Architektury hybrydowe, metody formalne, wykrywanie anomalii i pętle sprzężenia zwrotnego ludzkich będą musiały współpracować.

Guardrails są przydatnym narzędziem, ale odkrycia HiddenLayer przypominają nam: one nie mogą być jedynym narzędziem. Bezpieczeństwo musi pochodzić z zewnątrz systemu, a nie tylko z jego wnętrza.