Agenci AI potrzebują granic bezpieczeństwa, których nie mogą przedefiniować

Łatwo jest odczytać historię Hugging Face jako moment, w którym agenci AI wymknęli się spod kontroli. To nie do końca to, co się stało, a szczegóły mają znaczenie. Były to agenci badawcze ds. cyberbezpieczeństwa działający w ocenach, w których zabezpieczenia celowo wyłączono, aby badacze mogli zobaczyć, do czego zdolne są modele. Żaden bot obsługi klienta nie obudził się pewnego ranka i nie postanowił zaatakować firmy. Jednak ten kontekst nie zwalnia nikogo z odpowiedzialności. Agent przekroczył granicę, w której miał pozostać, użył poświadczeń i narzędzi w sposób niezatwierdzony przez operatorów i trafił do systemów należących do kogoś innego. To właśnie ten element powinien przykuwać uwagę każdego zespołu ds. bezpieczeństwa.

Reuters poinformował, że agenci badali Hugging Face już w maju, choć badacze stwierdzili, że nie znaleźli nic, co wskazywałoby, że wcześniejsza aktywność sama w sobie spowodowała naruszenie. Lipiec był inny. OpenAI stwierdził, że jego modele obejść kontrolę izolacji, dotarły do internetu i naruszyły części własnej infrastruktury badawczej wraz z systemami Hugging Face. Własne oświadczenie Hugging Face opisuje włamanie przeprowadzone od początku do końca przez autonomiczny system agentowy, które wykorzystało jego potok przetwarzania danych, zebrało poświadczenia i przemieszczało się po wewnętrznych klastrach.

Niewygodny fakt polega na tym, że agenci wykonywali swoją pracę. Dążyli do celu, który im przydzielono. Dlatego ta historia wykracza daleko poza jedno laboratorium badawcze. Agenci korporacyjni również dążą do celów. Posiadają poświadczenia, wywołują narzędzia i poruszają się szybciej niż jakakolwiek osoba może je przejrzeć. Agent o doskonałych intencjach może nadal wyrządzić rzeczywiste szkody, a przejęty agent może użyć tej samej władzy w imieniu atakującego. Dlatego bezpieczeństwo musi regulować, co system naprawdę może zrobić, niezależnie od tego, jak pewny wydaje się model czy jak nieszkodliwy wygląda jego deklarowany cel.

Zabezpiecz działanie, nie tylko model

Większość wczesnych programów agentów skupia swój wysiłek na modelu. Zespoły testują podpowiedzi, dostosowują odrzuty, dodają drugi model, aby sprawdzić pierwszy, i obserwują ślad rozumowania w poszukiwaniu oznak złych intencji. Nic z tego nie jest zmarnowane. Jednak wszystko to jest probabilistyczne, ponieważ zależy od kolejnego modelu podejmującego decyzję. Produkcyjna granica bezpieczeństwa musi być deterministyczna i musi otaczać narzędzia, poświadczenia, sieci oraz transakcje.

Pytanie, które bym zadał, jest konkretne: co ten agent naprawdę może spowodować w rzeczywistym świecie? Sporządzenie żądania płatności to jedno. Zwolnienie środków to drugie. To samo dotyczy przygotowania zmiany w bazie danych versus uruchomienia jej w produkcji, albo oznaczenia rekordów spełniających regułę retencji versus ich usunięcia. Może to być ten sam model w obu przypadkach, ale ryzyko jest bardzo różne w zależności od tego, po której stronie tej granicy się znajduje.

Niedawny przegląd Unite AI dotyczący kontroli możliwości wyznacza tę samą granicę, łącząc ryzyko z danymi, narzędziami, uprawnieniami, autonomią i środowiskiem, w którym działa agent. Podoba mi się to ujęcie, ponieważ pozwala nam przejść poza niejasne etykiety takie jak „bezpieczny model” i „niebezpieczny model”. Dzięki temu zespoły mogą śledzić każdą ścieżkę od decyzji agenta do rzeczywistych konsekwencji.

Nadaj każdemu agentowi tożsamość i wąskie upoważnienie

Agent nigdy nie powinien działać na koncie dewelopera ani dziedziczyć wszystkiego, co może zrobić użytkownik ludzki. Wspólna tożsamość usuwa możliwość przypisania. Długotrwałe poświadczenia dają atakującemu więcej czasu na ich nadużycie. A szerokie konta serwisowe pozwalają małemu przepływowi pracy wędrować po danych i systemach, do których nie ma uprawnień.

NIST traktuje teraz oprogramowanie i tożsamość agentów AI jako odrębny problem architektoniczny. Jego dokument koncepcyjny pyta, jak agent może udowodnić, że jest uprawniony do konkretnego działania, jak tożsamość agenta może być powiązana z autoryzacją człowieka oraz jak organizacje mogą utrzymywać odporne na manipulacje zapisy tego, co zamierzono i co faktycznie się wydarzyło. W praktyce prowadzi to do prostego projektu. Każdy agent otrzymuje unikalną tożsamość, właściciela (osobę lub zespół), określony cel oraz uprawnienia dopasowane do zadania przed nim stojącego.

Poświadczenia powinny szybko wygasać i działać wyłącznie dla określonych zasobów i działań. Dostęp sieciowy powinien zaczynać się od ścisłej listy dozwolonych. Jeśli agent musi zapytać jedną zatwierdzoną bazę danych, nie powinien otrzymywać również ogólnego shella, otwartego dostępu do internetu ani możliwości tworzenia nowych poświadczeń. A gdy praca przechodzi w dół łańcucha agentów i narzędzi, władza powinna stawać się węższa na każdym etapie, a nie szersza.

NIST również ostrzega przed udostępnianiem poświadczeń i nadmiernie szerokim dostępem, a to ostrzeżenie ma wagę, ponieważ agenci są oportunistyczni. Jeśli jedna ścieżka jest zablokowana, mogą spróbować innego narzędzia, rozejrzeć się po swoim otoczeniu lub natknąć się na token, o którym ktoś zapomniał. Zebrane poświadczenia były również częścią historii z lipca. Zasada najmniejszych przywilejów utrzymuje mały promień rażenia, gdy warstwa rozumowania robi coś, czego projektanci się nie spodziewali.

Utrzymuj autoryzację poza pętlą rozumowania

Agent może zalecić działanie. Nie powinien decydować, czy może je wykonać. Ta decyzja należy do oddzielnej warstwy egzekwowania, której agent nie może przepisać, wyłączyć ani obejść. Każde wywołanie narzędzia powinno pojawiać się jako ustrukturyzowane żądanie: który agent pyta, który człowiek je sponsoruje, jaką operację chce wykonać, co jest celem i jakie ograniczenia obowiązują. Warstwa egzekwowania następnie zezwala, blokuje lub eskaluje żądanie.

OWASP opisuje nadmierną autonomię jako mieszankę niepotrzebnej funkcjonalności, nadmiernych uprawnień i zbyt dużej samodzielności. Jej wytyczne zalecają wąskie narzędzia, minimalne uprawnienia, autoryzację w systemie docelowym oraz zatwierdzenie przez użytkownika dla działań o wysokim wpływie. Uważam, że to dokładnie właściwa kolejność. Zasada powinna być egzekwowana przez podmiot, który posiada dane lub wykonuje transakcję. Jeśli model stwierdzi, że działanie jest zatwierdzone, to samo oświadczenie nie powinno mieć żadnej wagi.

To rozdzielenie pomaga także przy wstrzyknięciach promptów. Zatruty e‑mail lub dokument może skierować rozumowanie agenta, ale nie może rozszerzyć jego poświadczeń ani obejść bramki polityki. Model może poprosić o coś zabronionego. System powinien nadal odmówić.

Zachowaj ludzkie zatwierdzenia na najważniejsze momenty

Ludzka weryfikacja jest uzasadniona, gdy działanie nie może być cofnięte, przekracza granice organizacyjną, zmienia uprawnienia, ujawnia wrażliwe informacje, przemieszcza środki finansowe lub dotyka systemu produkcyjnego. Żądanie zatwierdzenia przy każdym rutynowym kroku przynosi dwie rzeczy: opóźnienia oraz ludzi, którzy uczą się klikać „zatwierdź” bez czytania. NIST wymienia tę zmęczenie zgody po imieniu.

Dobre żądanie zatwierdzenia pokazuje dokładne działanie prostym językiem, w tym dokąd zmierza i które parametry są istotne. Powinno pochodzić z autorytatywnego systemu, a nie z tekstu napisanego przez agenta. Zatwierdzenie powinno szybko wygasać i obejmować tylko to jedno działanie. Jeśli jakikolwiek istotny szczegół się zmieni, system ponownie zapyta.

Wytyczne OWASP dotyczące bezpieczeństwa agentów zalecają testowanie, czy działanie o wysokim wpływie może przejść bez ważnego, niewygasłego, powiązanego z parametrami zatwierdzenia. To sformułowanie warto zapamiętać. „OK to continue” to słabe zatwierdzenie, które może zostać udzielone przez innego agenta lub złośliwego aktora. „Przelej tę kwotę na to konto” lub „wdroż tę zmianę w tym środowisku” to coś, co system może faktycznie zweryfikować w momencie wykonania, a użytkownik w pełni rozumie.

Bezpośrednia ludzka weryfikacja tożsamości ma znaczenie na tym etapie. Powiadomienie push dowodzi jedynie, że ktoś lub coś kliknęło przycisk. Silniejsze rozwiązania wymagają, aby zarejestrowana osoba używała odpornej na phishing autentykacji kluczem publicznym, wspieranej lokalną metodą weryfikacji biometrycznej. Standardy FIDO wiążą poświadczenia klucza publicznego z legalną usługą online i przechowują dane biometryczne na odizolowanym urządzeniu użytkownika. Przy właściwym użyciu uwierzytelnianie oparte na sprzęcie dostarcza znacznie lepszych dowodów, że właściwa osoba faktycznie była obecna. Nie zastępuje to jednak powiązania transakcji, wiarygodnego wyświetlania ani egzekwowania polityki. Wszystkie te elementy muszą działać razem.

Monitoruj zachowanie i zachowaj dowody

Nie możesz polegać na początkowym promptcie, aby wyjaśnić, co wydarzyło się podczas długiego działania agenta. Zespoły bezpieczeństwa potrzebują telemetrii dotyczącej wywołań narzędzi, aktywności sieciowej, użycia poświadczeń, decyzji polityk, zatwierdzeń, odrzuceń i zmian zakresu. Monitorowanie powinno porównywać rzeczywiste działania agenta z granicą zadeklarowaną dla tego uruchomienia. Jeśli agent został przydzielony do analizy kodu i zaczyna szukać zewnętrznych poświadczeń lub sondować niepowiązaną usługę, powinno to wywołać alarm.

Dzienniki muszą zawierać wystarczający kontekst, aby odtworzyć łańcuch działań bez ujawniania sekretów w czystym tekście. Każdy rekord powinien rejestrować wersję agenta, jego właściciela, osobę lub system, który uruchomił proces, użyte narzędzie, żądane działanie, wynik polityki oraz ewentualne ludzkie zatwierdzenie. Podpisane lub w inny sposób odporne na manipulację zapisy znacznie zwiększają wiarygodność analizy po zdarzeniu, szczególnie gdy zaangażowanych było kilka agentów i usług.

Wszystko to musi działać z prędkością maszyny. Nikt obserwujący pulpit nie powstrzyma tysięcy wywołań, które kończą się w ciągu sekund. Zautomatyzowane kontrole powinny wymuszać limity szybkości, wykrywać nietypowe sekwencje i zawieszać poświadczenia w momencie, gdy zachowanie przekroczy określony próg. Dzięki temu ludzie‑śledczy otrzymują ograniczony incydent do analizy, zamiast niekończącego się pościgu.

Zaprojektuj ścieżkę zatrzymania przed uruchomieniem

Każde wdrożenie agenta wymaga sposobu jego zatrzymania, który rzeczywiście usuwa możliwość działania. Prośba do agenta o zatrzymanie się nie liczy. Operatorzy powinni móc odwołać jego poświadczenia, odciąć ścieżkę sieciową, zakończyć jego środowisko uruchomieniowe i uniemożliwić uruchomienie oczekujących działań. W przypadku przepływów o wysokich konsekwencjach, jeśli usługa zatwierdzania lub polityki przestanie działać, system powinien przejść w stan zamknięty.

Następnie przetestuj tę ścieżkę pod presją. Wyłącz usługę zatwierdzania. Daj agentowi sprzeczne instrukcje. Zmień poświadczenie w trakcie działania. Symuluj narzędzia z kompromisem i zatwierdzającego, który nigdy nie odpowiada. Potwierdź, że działanie zostaje zablokowane i że pozostaje użyteczny zapis. I powtarzaj te testy za każdym razem, gdy model, prompt, łącznik, system pamięci lub zestaw uprawnień ulegnie zmianie.

Celem jest odpowiedzialna autonomia

Żadne z tego nie jest argumentem przeciwko agentom, a incydent Hugging Face nie powinien nikogo odstraszać od przydatnych. To, co powinno się zrobić, to zniszczyć pomysł, że ostrzeżenie bezpieczeństwa plus dobre intencje równa się godnej zaufania implementacji. Dajcie agentom przestrzeń do analizowania, przygotowywania pracy i obsługi odwracalnych zadań. Ograniczcie ich uprawnienia do wywoływania rzeczywistych konsekwencji, aby były wąskie, widoczne i egzekwowane przez coś innego niż sam agent.

Zanim agent trafi do produkcji, liderzy powinni być w stanie odpowiedzieć na kilka prostych pytań. Do jakich systemów może on dotrzeć? Jakich poświadczeń może używać? Co może zrobić bez przeglądu? Co wyzwala eskalację? Jak zatwierdzający widzi dokładną akcję, która jest zatwierdzana? Jakie dowody pozostaną? I jak bezpieczeństwo może natychmiast zatrzymać uruchomienie?

Jeśli odpowiedzi są niejasne, agent ma więcej uprawnień niż organizacja zdaje sobie sprawę. Architektura, która utrzymuje się w czasie, łączy zabezpieczenia modelu z tożsamością, zasadą najmniejszych przywilejów, zewnętrznym egzekwowaniem polityk, selektywną akceptacją ludzką, pełną telemetrią oraz mechanizmem zatrzymania, który naprawdę działa. Zakłada ona uczciwe założenie: zdolni agenci będą nas od czasu do czasu zaskakiwać. Nasze granice bezpieczeństwa nie powinny.

Na koniec pomyśl o agencie AI jako stażyście z (potencjalnym) dostępem root, który nie boi się działu HR.

Jakie zabezpieczenia i bramki powinni mieć?

Postępujcie zgodnie z tym.