Agenci AI i aplikacje na iPhone’y masowo ujawniają klucze do usług AI

Badania Uniwersytetu Wake Forest wskazują na wspólną słabość dwóch szybko rozwijających się ekosystemów AI: dane dostępowe często trafiają w miejsca, z których mogą je odczytać agent, aplikacja albo atakujący. W jednym z badań przeanalizowano 17 022 umiejętności firm trzecich dla agentów AI i znaleziono 520 podatnych elementów zawierających łącznie 1 708 problemów bezpieczeństwa. W powiązanym badaniu 444 aplikacji na iPhone’a z funkcjami dużych modeli językowych 282 ujawniły podczas testów dane dostępowe lub mechanizmy dostępu do zaplecza. 124

Ryzyko nie sprowadza się do samego wycieku pojedynczego ciągu znaków. Klucz API albo token może dać napastnikowi dostęp do prywatnych danych, możliwości agenta lub płatnych zapytań do modelu rozliczanych na koncie dewelopera.

Co wykazało badanie umiejętności agentów

Badacze wybrali 17 022 umiejętności z 170 226 artefaktów dostępnych w SkillsMP — otwartym katalogu dodatków dla agentów. Zastosowali statyczne wykrywanie sekretów, dynamiczne testy w izolowanym środowisku z użyciem atrap danych dostępowych oraz porównanie deklarowanego przeznaczenia umiejętności z jej zachowaniem podczas działania. 34

Analiza wykazała:

• 520 podatnych umiejętności, w których znaleziono 1 708 problemów bezpieczeństwa należących do 10 wzorców wycieku danych dostępowych. 416
• 466 z 520 podatnych umiejętności ujawniało dane, które można było wykorzystać bez podwyższonych uprawnień. Odpowiada to raportowanemu wskaźnikowi 89,6 proc. natychmiastowej wykorzystywalności. 14
• 76,3 proc. przypadków wycieku wymagało jednoczesnego przeanalizowania instrukcji w języku naturalnym i kodu.
• 3,1 proc. przypadków obejmowało zastrzyki promptów w języku naturalnym, bez wykonywalnego kodu. 4

To oznacza, że tradycyjny przegląd ograniczony wyłącznie do kodu może nie wystarczyć. Umiejętność może opisywać pozornie legalne zadanie, a jednocześnie jej instrukcje lub skrypty pomocnicze mogą ujawniać sekrety podczas działania.

Logi debugowania mogą przekazywać sekrety do kontekstu modelu

Szczególnie istotnym wzorcem wycieku okazało się logowanie diagnostyczne. W niektórych frameworkach agentów standardowe wyjście programu jest przekazywane do kontekstu modelu. W takiej konfiguracji dane dostępowe wypisane za pomocą funkcji takich jak print lub console.log mogą stać się dostępne po zwykłym żądaniu sformułowanym w języku naturalnym. W podsumowaniu badania wskazano logowanie debugowe jako główny wektor, któremu przypisano 73,5 proc. wycieków wynikających z przekazywania danych wyjściowych do modeli językowych. 4

Zagrożenie nie dotyczy wyłącznie oczywistych, zapisanych na stałe kluczy API. Sekrety mogą zostać ujawnione przez skrypty, sposób obsługi zmiennych środowiskowych, logi, instrukcje promptów albo połączenie kodu i języka naturalnego, które staje się niebezpieczne dopiero podczas typowego wykonania zadania.

Winny może być zarówno złośliwy, jak i niedbały twórca

W badaniu opisano dwie główne przyczyny wycieku danych dostępowych:

• Złośliwe tworzenie: autor celowo umieszcza w umiejętności instrukcje lub ładunki mające przechwytywać dane dostępowe i prywatne informacje, a następnie potencjalnie wysyłać je na zdalny serwer.
• Niedbałe tworzenie: deweloper nie stosuje bezpiecznych praktyk i nieumyślnie pozostawia dane dostępowe lub ścieżki dostępu, które mogą wykorzystać napastnicy. 1

To rozróżnienie ma znaczenie dla sposobu reagowania. Złośliwe elementy wymagają wykrycia i usunięcia, natomiast przypadkowe ujawnienie sekretów wymaga lepszego zarządzania kluczami, bezpieczniejszego logowania, kontroli uwierzytelniania oraz testów przed publikacją.

Po poinformowaniu SkillsMP Uniwersytet Wake Forest przekazał, że wszystkie zidentyfikowane złośliwe umiejętności zostały usunięte, a większość podatnych elementów naprawiono. Badanie ostrzega jednak, że uporządkowanie pierwotnego repozytorium może nie wystarczyć: kopie utworzone jako forki mogą zachować ujawnione dane nawet po naprawieniu źródła. 14

Aplikacje iOS otwierają inną drogę do przejęcia konta modelu

Powiązane badanie objęło 444 aplikacje na iOS wyposażone w funkcje dużych modeli językowych. W 282 z nich — czyli w około 64 proc. — w ruchu sieciowym ujawniono możliwe do wykorzystania dane dostępu do usług LLM albo mechanizmy dostępu do zaplecza. 25

Zgłoszone sposoby ujawniania danych obejmowały:

• tokeny JWT możliwe do ponownego użycia: 48 proc.;
• nieuwierzytelnione serwery pośredniczące: 33 proc.;
• przesyłanie kluczy API jawnym tekstem: 19 proc. 3

Takie słabości mogą być widoczne podczas zwykłego korzystania z aplikacji. Napastnik, który przechwyci klucz, ponownie wykorzysta token albo znajdzie otwarty serwer pośredniczący, może wysyłać żądania za pośrednictwem konta dewelopera w usłudze LLM. Może to prowadzić do zużycia płatnych zasobów obliczeniowych, nadużycia powiązanych usług chmurowych i naliczenia nieautoryzowanych opłat. 25

Dostępne dowody wskazują na możliwość poważnych, a w pewnych warunkach potencjalnie nieograniczonych kosztów — zależnie od limitów konta i czasu trwania ataku. Nie potwierdzają jednak niezależnie konkretnej kwoty strat, na przykład „setek tysięcy dolarów”.

Naprawianie luk przebiegało powoli. Trzy miesiące po odpowiedzialnym ujawnieniu problemu tylko 28 proc. podatnych aplikacji iOS miało usuniętą zgłoszoną lukę. W badaniu kontrolnym 72 proc. nadal można było wykorzystać. 311

Dlaczego ma to znaczenie w epoce programowania z pomocą AI

Oba badania pokazują, że dodanie funkcji AI do aplikacji lub zainstalowanie gotowej umiejętności agenta może powiększyć powierzchnię ataku. Nowe zagrożenia obejmują między innymi:

• klucze dostawców modeli umieszczone w aplikacjach klienckich lub ujawnione w kontekście agenta;
• uprzywilejowane narzędzia uzyskujące dostęp do plików, usług albo prywatnych danych;
• logi, które nieumyślnie stają się częścią kontekstu odczytywanego przez model;
• punkty końcowe zaplecza przyjmujące żądania bez odpowiedniego uwierzytelniania;
• tokeny możliwe do ponownego wykorzystania;
• koszty korzystania z modeli generowane przez napastnika na koncie dewelopera.

Problem staje się szczególnie istotny wraz z popularyzacją tak zwanego „vibe codingu” — szybkiego tworzenia i składania oprogramowania z dużym udziałem narzędzi AI. Tempo pracy nie zastępuje modelowania zagrożeń. Uwierzytelnianie, zarządzanie sekretami, autoryzacja, logowanie i przegląd zależności nadal wymagają świadomego podejścia inżynierskiego.

Badanie umiejętności agentów wykazało również oznaki wykorzystania narzędzi AI w 72 proc. przypadków zapisanych na stałe danych dostępowych. Może to sugerować, że niebezpieczne wzorce przenikają do kodu generowanego lub szybko składanych projektów i mogą rozprzestrzeniać się na większą skalę. 4

Zabezpieczenia powinny powstać przed premierą produktu

Wnioski z badań wskazują na podstawowy zestaw praktyk dla zespołów tworzących produkty AI lub publikujących umiejętności agentów:

1. Przechowuj długoterminowe klucze dostawców poza urządzeniem klienta i kontekstem modelu. Wrażliwe wywołania modeli kieruj przez uwierzytelniony serwer.
2. Stosuj krótkotrwałe dane dostępowe o ograniczonym zakresie. Zasada najmniejszych uprawnień powinna iść w parze z walidacją tokenów — samo posiadanie tokenu nie powinno wystarczać do autoryzacji.
3. Usuwaj sekrety z logów i standardowego wyjścia. Wszystko, co trafia do kontekstu agenta, należy traktować jako potencjalnie możliwe do odzyskania przez model lub użytkownika.
4. Skanuj kod, konfigurację, prompty i zależności pod kątem sekretów. Wyniki dotyczące umiejętności agentów pokazują, dlaczego instrukcje w języku naturalnym i kod trzeba analizować łącznie.
5. Testuj ruch sieciowy i autoryzację zaplecza. Sprawdź, czy przechwyconego żądania nie można ponownie wykorzystać ani przekierować przez nieuwierzytelniony serwer pośredniczący.
6. Rotuj ujawnione dane dostępowe i sprawdzaj forki oraz kopie. Usunięcie sekretu z pierwotnego repozytorium nie gwarantuje, że wyczyszczono każdą rozpowszechnioną wersję.
7. Wprowadź weryfikację platformową przed publikacją. Kontrola w marketplace, wytyczne dla twórców, odpowiedzialne ujawnianie luk i automatyczne testy powinny uzupełniać świadomość pojedynczych deweloperów. 34

Najważniejszy wniosek jest prosty: bezpieczeństwa AI nie można dokładać dopiero po premierze produktu. Dane dostępowe, uprawnienia agentów, kontekst modelu i kontrola kosztów powinny od początku być traktowane jako podstawowe elementy bezpieczeństwa produktu.