Jak zapobiegać niekontrolowanym kosztom poświadczeń API AI

Klucz API AI to nie tylko ciąg logowania. Jest drogą do rozliczanej mocy obliczeniowej, a skopiowany klucz może nadal autoryzować żądania długo po tym, jak atakujący opuści aplikację, w której został ujawniony. Kontrola kosztów należy więc do projektu bezpieczeństwa każdego systemu AI, w tym tymczasowych narzędzi badawczych i wewnętrznych prototypów.

Ujawnienie METR z 2026 roku nadaje temu ryzyku konkretny kształt. Dostępny z Internetu pulpit agenta miał błąd uwierzytelniania typu fail-open, co oznacza, że aplikacja pozostawała dostępna, gdy jej kontrola dostępu zawiodła. METR poinformował, że atakujący dotarł do pulpitu, skłonił agenta do ujawnienia poświadczenia dostawcy modeli, dodał klucz SSH dla trwałego dostępu do hosta i używał skradzionego poświadczenia przez trzy tygodnie. Wykorzystane kredyty wyceniono na około 600 000 USD, choć METR nie zapłacił tej kwoty, ponieważ dostawca przekazał kredyty bez opłaty.

Użyteczna lekcja nie dotyczy wartości z nagłówka ani stylu tworzenia jednej aplikacji. Kilka niezależnych mechanizmów kontroli nie zatrzymało tej samej ścieżki. Trwały plan zapobiegania zakłada, że interfejs, host lub klucz może w końcu zostać przejęty, i ogranicza to, co może wydarzyć się dalej.

Określ promień rażenia przed wdrożeniem agenta

Klasyfikuj aplikację AI według tego, do czego nieufny użytkownik mógłby przez nią dotrzeć, a nie według tego, czy zespół nazywa ją prototypem. Eksperyment staje się istotny operacyjnie, gdy przyjmuje ruch internetowy, może wywołać płatny lub rzadki model, może dotrzeć do niepublicznych danych albo może uruchamiać narzędzia mające skutki poza własnym procesem. Krótki czas życia nie zmniejsza tych możliwości.

Przed wystawieniem utwórz mały rejestr wdrożenia. Wpisz właściciela, publiczne punkty końcowe, konto chmurowe, modele, poświadczenia, magazyny danych, uprawnienia narzędzi, oczekiwany zakres użycia, datę wygaśnięcia i procedurę wyłączenia. Ten spis pozwala odnaleźć zapomniane eksperymenty i daje osobie reagującej na incydent wiarygodną mapę. Usługi publiczne powinny działać w środowisku architektonicznie oddzielonym od systemów wewnętrznych, aby wada przeglądarki lub pulpitu nie tworzyła drogi do wrażliwej infrastruktury.

Ujawnienie METR opisało drugi błąd w publicznej przeglądarce transkrypcji: mechanizm SQL tylko do odczytu można było zmanipulować, aby ujawnić nieopublikowane dane ewaluacyjne, a część wrażliwych wyników trafiła do bazy danych, która miała zawierać wyłącznie wyniki modeli publicznych. METR stwierdził, że dostępne dowody nie wskazywały, iż atakujący odkryli exploit lub uzyskali dostęp do niepublicznych informacji. Epizod nadal pokazuje, dlaczego zamierzona klasyfikacja danych nie wystarcza. Izolacja musi obejmować miejsce przechowywania rekordów, zakres zapytań oraz to, czy ograniczony materiał może zostać umieszczony w magazynie danych dostępnym publicznie.

Ustal jedną łatwą do egzekwowania zasadę: wystawienie na Internet lub dostęp do aktywnych poświadczeń automatycznie wywołuje podstawowy przegląd bezpieczeństwa. Przegląd może być lekki, ale powinien potwierdzać uwierzytelnianie z domyślną odmową, zarządzany hosting, nazwaną odpowiedzialność, rejestrowanie, granice poświadczeń i datę zakończenia.

Trzymaj surowe sekrety poza zasięgiem agenta

Aplikacja może potrzebować uprawnienia do wywołania modelu, lecz model nie musi odczytywać poświadczenia wielokrotnego użycia. Przechowuj sekrety poza promptami, transkrypcjami, narzędziami inspekcji środowiska, plikami, które agent może otworzyć, oraz wynikami poleceń, które agent może zwrócić. Instrukcje takie jak „nigdy nie ujawniaj tego klucza” nie są granicą bezpieczeństwa, ponieważ model językowy przetwarza nieufne instrukcje i można nim manipulować tak, aby ujawnił dostępne informacje.

Umieść brokera lub wąsko zdefiniowaną usługę między agentem a dostawcą. Agent żąda dozwolonej operacji; broker przechowuje poświadczenie, sprawdza żądanie, stosuje politykę, rejestruje użycie i zwraca tylko niezbędny wynik. Ogranicz brokera do zatwierdzonych modeli i operacji. Tam, gdzie pozwalają na to funkcje dostawcy, wydawaj odrębne poświadczenia dla każdej aplikacji i środowiska, ograniczaj zakresy uprawnień i używaj krótkich okresów życia.

Oddzielne tożsamości ułatwiają zarówno powstrzymanie, jak i dochodzenie. Jeśli jeden klucz obsługuje wiele eksperymentów, duże użycie ma wiele wiarygodnych wyjaśnień, a unieważnienie zakłóca niepowiązaną pracę. Klucz przeznaczony dla jednego obciążenia ma mniejszy zakres zachowania, jasnego właściciela i praktyczny wyłącznik awaryjny. Krótkotrwałe poświadczenia skracają też okres, w którym skopiowana wartość pozostaje użyteczna, a wąsko ograniczone uprawnienia ograniczają to, co atakujący może zrobić w tym okresie.

Dostęp do hosta potrzebuje własnej granicy. Atakujący METR dodał klucz SSH po wejściu do wystawionego systemu, więc rotacja samego poświadczenia dostawcy nie usunęłaby trwałości. Monitoruj zmiany konfiguracji zdalnego dostępu, ogranicz, kto może dodawać klucze, i traktuj nową metodę trwałego dostępu jako incydent, nawet gdy zużycie API nadal wygląda zwyczajnie.

Zamień budżety w egzekwowane limity bezpieczeństwa

Alert wydatków jest użyteczny, ale alert jest tylko prośbą, by człowiek zbadał sprawę. Preferuj twardy limit dostawcy lub brokera, który odrzuca dalsze użycie po wyczerpaniu zatwierdzonego budżetu. Stosuj limity na wielu poziomach, gdy są dostępne: organizacji, projektu, poświadczenia aplikacji i okna czasowego. Sam miesięczny limit konta może nadal pozwolić na szkodliwy skok na początku okresu.

Niektórzy dostawcy lub konfiguracje kont mogą nie udostępniać bezpośredniego limitu wydatków. METR powiedział, że w tamtym czasie nie mógł ustawić go dla dotkniętego klucza, a darowane kredyty usunęły rosnącą fakturę, która w przeciwnym razie mogłaby przyciągnąć uwagę. W takiej sytuacji odtwórz granicę w warstwie wywołującej. Broker poświadczeń może liczyć żądania lub tokeny, wymuszać dzienne i na-jedno-uruchomienie przydziały, ograniczać współbieżność oraz zawieszać dostęp po przekroczeniu progu. Przyznaną lub przedpłaconą pojemność należy traktować jako aktywo o wartości odtworzeniowej, nawet gdy bieżące rozliczenie gotówkowe wynosi zero.

Wybieraj progi na podstawie zadeklarowanego celu poświadczenia. Zaplanowana ewaluacja, interaktywny pulpit i zadanie wsadowe nie powinny dzielić tych samych limitów. Określ oczekiwane maksimum dla jednego uruchomienia, kroczący limit godzinowy lub dzienny oraz maksymalny wskaźnik żądań nieudanych lub odrzuconych. Udokumentuj, kto może zatwierdzić tymczasowe zwiększenie i kiedy ten wyjątek wygasa. W przeciwnym razie awaryjne obejścia po cichu stają się normalnym zakresem działania.

Egzekwowanie musi działać w trybie fail-closed. Jeśli usługa uwierzytelniania, kontrola polityki, licznik użycia lub wyszukiwanie zatwierdzenia są niedostępne, system powinien odmówić chronionej operacji albo mocno ją ograniczyć. Zdegradowana usługa monitorowania nie powinna po cichu zamieniać ograniczonego poświadczenia w nieograniczone.

Wykrywaj zachowanie, którego rachunek nie pokaże

Duża liczba tokenów nie jest automatycznie podejrzana w pracy badawczej lub ewaluacyjnej. METR wyjaśnił, że legalne eksperymenty mogły generować znaczne użycie, odpowiedzi ograniczenia szybkości i błędy dostawcy. Jego wewnętrzny pulpit podczas incydentu nie pokazywał też każdego żądania ograniczonego szybkością każdego użytkownika. Ta kombinacja pozwoliła nieautoryzowanej aktywności zlać się ze znajomym szumem operacyjnym.

Buduj linie bazowe wokół tożsamości i celu zamiast obserwować tylko całkowity wolumen konta. Dla każdego poświadczenia aplikacji zachowuj czas żądania, model, wynik, ilość tokenów lub użycia, źródłowe obciążenie i odpowiedzialnego właściciela, jeśli te sygnały są dostępne. Uwzględnij nieudane i ograniczone szybkością próby, ponieważ rozpoznanie i próba konsumpcji mogą nigdy nie pojawić się w sumach udanego użycia. Nie umieszczaj surowego sekretu w logach.

Użyteczne reguły anomalii porównują bieżące zachowanie z rejestrem wdrożenia. Przykłady obejmują aktywność poza harmonogramem obciążenia, utrzymujące się użycie po zakończeniu planowanego eksperymentu, nieznane źródło, model, którego aplikacja nie miała prawa wywołać, niezwykły stosunek błędów do sukcesów lub nagłą zmianę tempa żądań. Sygnały te są bardziej użyteczne niż ogólny alert „duże użycie”, ponieważ wyjaśniają, które oczekiwanie zostało naruszone.

Dostrajaj alerty bez usuwania ważnych dowodów. Hałaśliwe komunikaty o ograniczeniu szybkości należy grupować i podsumowywać, a nie pomijać na pulpicie. Celem jest możliwy do obsłużenia strumień alertów wsparty kompletnymi, przeszukiwalnymi zdarzeniami. Każdy alert potrzebuje nazwanego respondenta, ważności, terminu dochodzenia i automatycznej ścieżki eskalacji. Ostrzeżenie bez właściciela to tylko zapisana telemetria.

Zaprojektuj pulpit agenta do podejmowania decyzji

Użyteczny pulpit operacyjny powinien szybko odpowiadać na cztery pytania: które poświadczenie zmieniło zachowanie, co może robić, jaka wartość jest obecnie zagrożona i jakie działanie je powstrzyma. Pokazuj użycie i błędy według poświadczenia, aplikacji, modelu i okna czasowego zamiast tylko jako sumę organizacji. Pokaż zużycie twardego limitu, tymczasowe wyjątki, wiek poświadczenia, ostatnią rotację, właściciela oraz to, czy powiązane wdrożenie nadal jest zatwierdzone.

Umieść razem sygnały bezpieczeństwa i kosztu. Skok błędów dostawcy, nowy klucz SSH, błąd uwierzytelnienia i ciągłe użycie API mogą wyglądać nieistotnie w osobnych narzędziach, ale po skorelowaniu tworzą jasny łańcuch incydentu. Zachowaj dość historii, aby porównać bieżące zachowanie z normalnym wzorcem tego samego obciążenia i później odtworzyć sekwencję.

Pulpit powinien udostępniać lub bezpośrednio łączyć z przetestowanymi działaniami powstrzymującymi: wyłączeniem poświadczenia aplikacji, zatrzymaniem obciążenia, usunięciem dostępu publicznego i kontaktem z dostawcą. Destrukcyjne kontrolki wymagają właściwego upoważnienia, ale nie powinny zależeć od znalezienia nieudokumentowanego polecenia podczas aktywnego incydentu. Zapisuj, kto wykonał każde działanie i kiedy.

Przećwicz ćwiczenie reakcji na poświadczenie

Przeprowadź ćwiczenie stolikowe lub kontrolowane wokół skopiowanego klucza. Zacznij od wiarygodnego sygnału, takiego jak utrzymujący się ruch poza harmonogramem oraz powtarzające się błędy ograniczenia szybkości. Poproś osobę dyżurną o zidentyfikowanie właściciela, potwierdzenie dotkniętego konta dostawcy, wyłączenie poświadczenia, zatrzymanie lub odizolowanie obciążenia i sprawdzenie hosta pod kątem trwałości. Zespół powinien następnie obrócić powiązane poświadczenia, zachować logi i obraz kryminalistyczny, gdy jest to właściwe, powiadomić dostawcę i ustalić, czy dane lub inne systemy były osiągalne.

Unieważnienie jest pierwszym krokiem powstrzymania, a nie końcem dochodzenia. Reakcja METR obejmowała zatrzymanie przejętej instancji, utworzenie obrazu kryminalistycznego, rotację poświadczeń, zbadanie i wyczyszczenie laptopa badacza, poinformowanie firmy modelowej oraz skorzystanie z zewnętrznej pomocy bezpieczeństwa. Dokładna kolejność będzie się różnić, lecz zasada jest stała: usuń bieżący dostęp, zachowując dostateczne dowody, by ustalić, jak doszło do przejęcia i co jeszcze musi się zmienić.

Mierz ćwiczenie upływem czasu i brakującymi informacjami. Jak długo trwało wykrycie, wyszukanie właściciela, unieważnienie, izolacja hosta i kontakt z dostawcą? Które logi były niepełne? Czy respondenci mogli odróżnić przyznane kredyty od rozliczonego użycia? Po każdym ćwiczeniu zaktualizuj szablon wdrożenia, pulpit i podręcznik operacyjny.

Lista kontrolna wdrożenia

• Zinwentaryzuj każdą usługę agenta wystawioną na Internet, jej właściciela, datę wygaśnięcia, środowisko chmurowe, poświadczenia, dane i narzędzia.
• Wymagaj uwierzytelniania z domyślną odmową i przeglądu bazowego dla ekspozycji publicznej lub dostępu do aktywnych poświadczeń.
• Trzymaj sekrety dostawcy poza kontekstem czytelnym dla modelu, transkrypcjami, narzędziami i możliwymi do odzyskania plikami.
• Używaj poświadczeń na aplikację o najwęższym dostępnym zakresie i praktycznym czasie życia.
• Kieruj wywołania przez brokera, gdy bezpośrednie kontrole dostawcy nie mogą wymusić wymaganej polityki.
• Ustaw limity użycia na uruchomienie i kroczące; dodaj twarde zatrzymanie wszędzie, gdzie dostawca lub broker je obsługuje.
• Monitoruj udane, nieudane i ograniczone szybkością żądania według poświadczenia i oczekiwanego obciążenia.
• Alarmuj o niezgodnościach zachowania, nie tylko o zagregowanym koszcie lub liczbie tokenów.
• Koreluj użycie modeli ze zdarzeniami uwierzytelniania i trwałości hosta na pulpicie agenta.
• Zapewnij każdemu alertowi respondenta, termin, drogę eskalacji i przetestowane działanie powstrzymujące.
• Ćwicz unieważnianie klucza, izolację obciążenia, zabezpieczanie dowodów, powiadamianie dostawcy i odzyskiwanie.
• Wycofaj poświadczenia i publiczne punkty końcowe po zakończeniu eksperymentu, a następnie sprawdź, czy ruch ustał.

Nie kontrolowanym kosztom API najlepiej zapobiegają nakładające się limity. Izolacja sekretów blokuje łatwe wydobycie, wąskie tożsamości zmniejszają promień rażenia, egzekwowane budżety ograniczają zużycie, monitorowanie zachowania skraca wykrywanie, a ćwiczenia reakcji czynią unieważnianie rutyną. Żaden z tych środków nie zależy od poprawnego odgadnięcia, jak wejdzie następny atakujący. Razem zmieniają skradziony klucz z zasobu bez otwartego końca w ograniczony, obserwowalny incydent.