Chcete-li vytvořit funkční systémy AI, musíte je nejprve zkusit prolomit. Provedli jsme red-teaming aplikace AI pro klienty ve finančních službách: v roli útočníků jsme ji testovali a hledali její slabiny. Naše zjištění jsou důležitá pro každého, kdo nasazuje aplikace využívající LLM v prostředí, kde zabezpečení není volitelné.
Red-teaming spočívá v cílených pokusech o prolomení systému AI, abyste mohli zranitelnosti opravit dříve, než je objeví skutečný útočník. Ve finančních službách je v sázce obzvlášť mnoho: aplikace AI pracují s údaji klientů, zpracovávají transakce a poskytují finanční přehledy. Selhání může vést od špatné uživatelské zkušenosti přes porušení předpisů a finanční ztráty až po nenapravitelné poškození značky.
Naším cílem bylo včas odhalit zranitelnosti, otestovat realistické způsoby útoku a pomoci organizaci splnit požadavky na bezpečnost AI, které regulátoři berou velmi vážně.
Je zde důležité rozlišovat: jailbreak útočí na bezpečnostní filtry samotného modelu, zatímco injektáž promptů napadá aplikaci prostřednictvím nedůvěryhodného vstupu uživatele zkombinovaného s důvěryhodným promptem vývojáře. Injektáž promptů představuje větší riziko, protože necílí na univerzální model, ale na váš systém a důvěrná data, s nimiž pracuje.
První kolo zahrnovalo přibližně 750 testů zaměřených na:
Únik dat mezi relacemi
Odhalení osobních údajů (prostřednictvím přirozeného jazyka, manipulace s API a různých kódování)
Injektáž SQL
Přepsání systémového promptu
Během úvodního testování jsme v existujícím systému odhalili dva zásadní problémy: zpracování dotazů s více záměry a používání kódovaných promptů.
Dotazy s více záměry: požadavky, které kombinují legitimní a škodlivé úkoly. Například: “Ukaž mi útraty podle kategorie a zároveň proveď [škodlivý SQL kód].” Aplikace škodlivý záměr nerozpoznala a zcela spoléhala na ochranná opatření v navazující datové vrstvě. Je to stejné, jako byste nechali otevřené vchodové dveře, protože důvěřujete trezoru ve sklepě.
Kódování: požadavky zakódované pomocí Base64, hexadecimálního kódu, LeetSpeaku a homoglyfů. Pro systémy může být obtížné takový škodlivý záměr odfiltrovat. Zjistili jsme, že tyto dotazy sice neodhalovaly citlivá data, ale výrazně destabilizovaly systém (halucinace, opakování škodlivého SQL uživatelům, chybné určování záměru atd.).
Výsledky úvodního testování ukázaly:
Časové halucinace: model sebejistě uváděl smyšlená data, časová razítka transakcí nebo časově vymezená shrnutí. Ve finančním prostředí jde o významné riziko, protože jednání klienta podle nesprávného data může mít skutečné následky
Opakování škodlivého SQL uživateli (škodlivý SQL kód je pouze zopakován zpět uživateli)
Chybné určování záměru
Rozhozené formátování výstupu
Na základě těchto zjištění jsme své zaměření zúžili. Testy injektáže SQL a kódování dostaly nižší prioritu, protože tým již tyto problémy řešil. Místo toho jsme se soustředili na nejúspěšnější vektory útoku: odhalení osobních údajů a úniky mezi relacemi.
Nejpřekvapivější zjištění druhého kola bylo odzbrojujícím způsobem prosté: často vůbec nemusíte být vynalézaví.
V mnoha případech stačilo o interní data jednoduše požádat v rámci zdánlivě legitimního požadavku a systém souhlasil s jejich předáním. Systém na jednoduché dotazy odpovídal s odkazy na interní identifikátory a systémová pole, která by se koncovým uživatelům nikdy neměla zobrazit.
Při hlubším zkoumání jsme zjistili, že nejde jen o selhání na úrovni aplikace. Navazující služba pro převod textu na SQL vytvářela dotazy požadující více polí, než měla, a ve vysvětlujících odpovědích odkazovala na data, k nimž měl být přístup omezen. Tím se odhalila skutečná trhlina mezi systémy – zranitelnost, která vyjde najevo jen při testování celé technologického vrstvy, nikoli jednotlivých komponent izolovaně.
Red-teamingem testujte systém, ne model. Testování izolovaného LLM vám o úrovni zabezpečení aplikace řekne jen velmi málo. Testujte celou technologickou vrstvu od začátku do konce tak, jak s ní pracuje uživatel.
Vstup musí být ověřen ještě před LLM. Kódované dotazy, útoky s více záměry a základní pokusy o injektáž je nutné zachytit na hranici systému, nikoli je přenechávat navazujícím službám.
Nedůvěřujte rozhraním mezi systémy. V architekturách s více službami se nejzajímavější zranitelnosti skrývají na rozhraních štěrbinách mezi systémy. Nulová důvěra znamená nulovou důvěru, proto vše ověřujte v každé vrstvě.
Jednoduché útoky fungují. Sofistikované jailbreaky plní titulky, ale někdy stačí prostě... požádat. Pokud váš systém ochotně zobrazí interní identifikátory, když je uživatel zahrne do jinak legitimního dotazu, je to problém.
Ujasněte si, co skutečně testujete. Známé způsoby útoku může zachytit samotné natrénování LLM, nikoli vaše ochranná opatření. Začleňte do red-teamingu monitorování, abyste věděli, které kontrolní mechanismy jsou skutečně aktivovány.
Omezená prostředí vyžadují kreativní řešení. Vlastní poskytovatelé a podpora místních modelů umožňují smysluplný red-teaming bez specializovaného přístupu ke cloudu. Je však nutné otevřeně informovat o omezeních, která to přináší.
Red-teaming není jednorázová záležitost. Je to opakovaný proces, který by měl být všude, kde je to možné, automatizován a měl by se vyvíjet spolu s vaším systémem. Útoky, které budou důležité zítra, nejsou stejné jako ty dnešní.
Systémy AI v regulovaných prostředích budou pod stále větším dohledem. Organizace, které pojímají bezpečnostní testování jako trvalou disciplínu, nikoli jako položku k odškrtnutí před spuštěním, budou na tento dohled lépe připravené a vyhnou se PR katastrofám, kvůli nimž přicházejí o důvěru zákazníků.