V říjnu se ukázalo, jak rychle se z pohodlné AI platformy může stát drahá peněženka pro někoho cizího. Nejméně devět AI vývojářských platforem oznámilo incidenty, při nichž útočníci hledali přístupové údaje, klíče a cesty k výpočetnímu výkonu. Nešlo jen o krádež dat. V některých případech se ukradené přístupy proměnily v masivní účty za modelová volání.
Tohle je důležitější než další seznam napadených firem. AI infrastruktura se chová jako nový druh finančního účtu: kdo získá platný klíč, nemusí prorážet model ani přesvědčovat uživatele. Stačí mu utrácet cizí kredit, dokud si někdo nevšimne, že účet začal pracovat pro někoho jiného.
Klíč byl dřív tajemství. Teď je to kredit
Podle analýzy společnosti Wiz se v několika říjnových případech opakovaly krádeže přístupových údajů z vývojářských prostředí, proměnných prostředí a cloudové infrastruktury. Ve dvou sledovaných případech byly kompromitované klíče použity k přibližně 800 tisícům a 1,7 milionu volání do AWS Bedrocku. Wiz odhadl, že jen tyto dvě větve mohly vytvořit více než 100 tisíc dolarů v účtech.
To není drobný účet za omylem spuštěný skript. Je to průmyslově použitelný model zneužití: najít platný přístup, ověřit jeho limity, zjistit, jaký výkon odemyká, a potom ho využít pro vlastní provoz nebo další přeprodej. Wiz tento vzorec popisuje v přehledu říjnových incidentů, ale zároveň není důvod předstírat, že všechny případy mají stejného pachatele nebo jedinou technickou příčinu.
Rozdíl proti běžné krádeži hesla je v tom, že API klíč často neotvírá jen jednu aplikaci. Může otevřít účet poskytovatele, modelové endpointy, úložiště, buildovací prostředí nebo další služby, které jsou na platformu napojené. Útočník tak nemusí hledat jednu cennou databázi. Může si vybrat z celé nabídky oprávnění, která někdo kdysi poskládal kvůli pohodlnějšímu vývoji.
Platforma je součástí AI bezpečnostního perimetru
Největší omyl je dívat se na AI platformu jako na neutrální místo, kam se jen nasadí kód. Ve skutečnosti drží část tajemství zákazníků, překládá jejich oprávnění do cloudových akcí a často má přístup k prostředí, kde vznikají buildy, agenti nebo automatizace. Jakmile se taková služba dostane do problémů, může být zasaženo mnohem víc účtů najednou.
Dobře to ukázal incident na Railway. V předběžné zprávě Railway uvedla, že útočník získal přístup k části interní infrastruktury a dešifrovaným zákaznickým údajům. Firma napsala, že nejvýše 1,85 procenta pracovních prostorů mohlo být zasaženo a že u části účtů došlo k expozici tajných hodnot nebo metadat. To není totéž jako tvrzení, že byly ukradeny všechny zákaznické projekty. Je to ale přesně ten druh mezery, který z lokálního úniku dělá problém platformy.
Zákazník přitom často nemá možnost ověřit, kde přesně se jeho klíč během provozu nachází. Je v proměnné prostředí, v logu, v buildovacím systému, v pomocné službě, v cache nebo v záloze? Pokud odpověď zní „někde v platformě“, pak bezpečnost tohoto klíče nezávisí pouze na týmu, který aplikaci napsal.
U vlastního cloudového účtu jsme už řešili podobnou hranici: vlastnictví účtu může odstranit část závislosti na malém provozovateli, ale neodstraní poskytovatele cloudu ani jeho odpovědnost za infrastrukturu. U AI vývojových platforem je stejná otázka ještě ostřejší, protože v sázce nejsou jen poznámky a databáze, ale také přístup k placenému výpočetnímu výkonu.
Nejdražší útok nemusí nic rozbít
Bezpečnostní týmy jsou zvyklé hledat poškozené soubory, vypnuté služby nebo data zveřejněná na internetu. U AI účtů může být největší škoda mnohem tišší. Útočník nechá službu běžet, posílá do ní vlastní požadavky a čeká, až účet zaplatí výpočet. Provozovatel mezitím vidí jen neobvykle vysokou spotřebu, pokud ji vůbec sleduje.
Označení LLMjacking se pro tento typ zneužití používá právě proto, že útočník nepřebírá model jako takový. Přivlastní si přístup k modelové službě a nechá ji pracovat pro sebe. Získaný účet může sloužit k experimentům, generování obsahu, automatizovanému zpracování nebo k přeprodeji přístupu dalším lidem. Model přitom funguje správně. Chybně funguje účet, který mu otevřel dveře.
Výzkumná poznámka Cloud Security Alliance popisuje řetězec mezi napadenými platformami a poskytovateli inference. Podstatné není, jestli každý incident zapadá do jedné kampaně. Podstatné je, že infrastruktura pro vývoj AI vytváří atraktivní mezistupeň mezi ukradeným tajemstvím a drahým výpočetním výkonem.
To mění i ekonomiku útoku. Dříve bylo potřeba najít účet, který obsahuje něco zajímavého. Teď může stačit účet, který má dobrý limit, důvěryhodný původ a přístup k modelům, jež by se jinak obtížně platily nebo schvalovaly. Útočník nemusí chtít vaše data. Může chtít pouze váš limit.
Tajný klíč není bezpečný jen proto, že ho nikdo nevidí
Říjnové případy znovu ukazují slabinu běžného přístupu k tajemstvím. Klíč se uloží do proměnné prostředí, platforma ho předá buildu a tým předpokládá, že dál už je věc vyřešená. Jenže každý další systém, který s klíčem pracuje, přidává další místo, kde se může objevit v logu, diagnostice, snapshotu nebo paměti procesu.
GitHub proto rozšiřuje secret scanning a blokování známých typů klíčů už při pushi. To je užitečná první vrstva, nikoli důkaz bezpečnosti. Zastaví omylem zveřejněný klíč v repozitáři, ale nepomůže, pokud se tajemství dostane do napadeného buildovacího systému nebo do služby, která má oprávnění číst zákaznickou konfiguraci.
Stejně omezený je i argument, že klíče byly přece šifrované. Šifrování chrání data v určitém stavu. Aplikace je ale musí někdy dešifrovat, aby je mohla použít. Otázka proto není pouze „byl klíč uložen šifrovaně?“, ale také „kdo ho mohl dešifrovat, v jakém procesu, na jak dlouho a s jakým auditem?“.
Co by měla platforma dělat jinak
První změna je nepříjemně prostá: zákazník by neměl dostat jeden univerzální klíč pro celý provoz. Přístupy je potřeba dělit podle projektu, prostředí, modelu a účelu. Klíč pro testovací chatbot nemá mít stejnou moc jako klíč pro produkční službu a žádný z nich nemá automaticky otevírat všechny dostupné modely.
Druhá vrstva jsou limity, které útočník nepřekoná pouhým získáním tajemství. Patří sem rozpočty, rychlostní limity, oddělené kvóty pro jednotlivé projekty, povolené regiony a seznam modelů, ke kterým má aplikace přístup. Rozpočet není náhrada bezpečnosti. Je to pojistka, která může zkrátit dobu mezi kompromitací a zjištěním škody.
Třetí vrstva je detekce chování, ne jen kontrola platnosti klíče. Platforma by měla umět upozornit na náhlý skok v počtu volání, změnu regionu, neobvyklé modely, paralelní používání z různých míst a požadavky, které se vymykají běžnému provozu. Platný token použitý podivným způsobem je stále bezpečnostní událost.
Čtvrtá vrstva se týká samotného provozovatele platformy. Zákazník potřebuje vědět, jak se tajemství izolují mezi pracovními prostory, kdo k nim má administrátorský přístup, jak rychle lze klíče zneplatnit a jaké logy zůstanou po incidentu. Doporučení AWS pro bezpečnost generativní AI připomíná, že ochrana musí stát na více vrstvách identity, sítě, monitoringu a správy dat. Stejná logika platí i pro platformu, která tyto služby zprostředkovává.
Kontejner ani dashboard odpovědnost nepřevezmou
Tady se vyplatí připomenout širší pravidlo z rozboru bezpečnosti MCP serverů: izolace procesu není totéž jako správně navržená pravomoc. Kontejner může oddělit službu od hostitele, ale neřekne, zda má služba právo číst produkční klíče, volat internet nebo měnit databázi. Totéž platí pro AI platformu. Hezký dashboard a šifrovaný secret vault neodpoví na otázku, co se stane, když se kompromituje samotná řídicí vrstva.
Bezpečnostní produkt může zlepšit přehled a zmenšit prostor pro chybu. Nemůže ale za tým rozhodnout, jakou moc má mít jeden token, ani za poskytovatele dokázat, že oddělení zákazníků funguje při skutečném incidentu. Technická funkce není auditní důkaz.
AI účet se musí chovat jako platební účet
Firmy si budou muset zvyknout na nepohodlnou myšlenku: účet u AI poskytovatele není jen vývojářská konfigurace. Je to finanční a provozní aktivum. Má vlastní limity, kredit, identitu, historii spotřeby a možnost způsobit škodu rychleji, než ji člověk stihne ručně prošetřit.
To znamená pravidelně rotovat klíče, oddělovat prostředí, omezovat modely a regiony, nastavovat rozpočty, sledovat anomálie a předem si vyzkoušet nouzové zneplatnění přístupu. Stejně důležité je vědět, která třetí strana smí klíč dešifrovat a zda po incidentu dokáže dodat použitelný audit. Bez toho se zákazník dozví o problému až z faktury.
Říjnová série není důkazem, že jsou všechny AI platformy stejně nebezpečné. Je ale dostatečným varováním, že bezpečnostní model „my hlídáme aplikaci, platforma hlídá zbytek“ přestal stačit. Platforma je součástí perimetru, klíč je zároveň finanční oprávnění a neobvyklá spotřeba může být první stopou útoku.
AI průmysl chce, aby firmy přemýšlely o modelech jako o nové vrstvě infrastruktury. Pak musí přijmout i druhou polovinu té věty: kdo prodává přístup k infrastruktuře, prodává také odpovědnost za její hranice. Ukradený klíč není jen problém zákazníka, který ho někde špatně uložil. Je to test celé platformy, která z něj udělala použitelný účet.
