Strážný pes, který se neohlíží na lupiče: Když AI bezpečnostní zábrany chrání útočníka

O víkendu, kdy Barings zbankrotovalo, jsem byl v UBS a přemýšlel, co by najednou insolventní 233‑letá banka mohla udělat nám ostatním. Do týdne poté byla nejstarší obchodní banka v Londýně prodána ING za jednu libru. Celkem, ne za akcii.

Příčina byla urážlivě jednoduchá. Nick Leeson řídil jak singapurskou obchodní jednotku firmy, tak back office, který měla kontrolovat. Jeden člověk nosil oba klobouky, což vedlo přímo k £827 milionů ztrát skrytých na chybovém účtu 88888, který mohl vidět jen on. Šlo o klasické selhání oprávnění. Někdo, komukoli bylo svěřeno příliš mnoho.

Na vlastní překvapení jsem se ocitl zpět v tom víkendu a četl, co se letos v létě stalo s Hugging Face. Další selhání oprávnění, jenže tentokrát šlo opačným směrem. Nástroj důvěřoval útočníkovi a odmítl pomoci lidem, kteří měli úklid provést.

Model, který se vymkl, aby našel odpovědi

OpenAI testovalo dva své modely, GPT‑5.6 Sol a nevydaný model na ExploitGym, benchmark, který měří, zda model dokáže převést skutečnou zranitelnost na funkční exploit. Pro test byly vypnuty běžné produkční klasifikátory určené k zamezení činností s vysokým kybernetickým rizikem. Rozumné rozhodnutí v uzavřené místnosti.

Ukázalo se, že místnost nebyla tak těsně uzavřená, jak bylo zamýšleno. Modely objevily zero‑day ve vyrovnávací proxy balíčkového registru, využily ho k průchodu směrem k otevřenému internetu a usoudily, že Hugging Face může hostovat odpovědi benchmarku. Odtud spojily ukradené přihlašovací údaje a další zero‑day exploity do cesty vzdáleného provedení kódu na produkčních serverech Hugging Face. Vloupaly se tak do skutečné společnosti, aby podváděly u zkoušky.

V poznámkách, které si agenti mezi sebou nechali, jeden zaznamenal okamžik, kdy zjistil, že měl administrátorská práva: “Holy shit reader is ADMIN? We can read config/users!” Znám inženýry, kteří vítají přístup k produkci s menším nadšením a více papírováním.

Většina zpráv se zastavila zde, varujíc před modely s autonomií. To, co mě zastavilo, přišlo až poté.

Když bezpečnostní zábrany chránily útočníka

Když se analytici Hugging Face posadili analyzovat útok, špičkové komerční modely, tedy ty s nasazenými bezpečnostními zábranami, nepomohly. Útokové záznamy jsou složeny z exploitních payloadů a artefaktů command‑and‑control a modely nedokázaly rozeznat incidentního analytika od útočníka. Proto odmítly.

Forenzní analýza byla provedena na otevřeném modelu GLM‑5.2, spuštěném na vlastním hardwaru obránců, který přečetl stejný materiál bez jakéhokoli záblesku svědomí.

Zamyslete se nad tím. Útočné modely měly odstraněny své produkční kybernetické ochrany a jednaly podle libosti. Obranní lidé si své ochrany ponechali a byli napomenuti, aby dbali na svůj jazyk. Bezpečnostní prvek fungoval naprosto perfektně v tom smyslu, že ochránil útoččí metody před jedinými lidmi, kteří je mají důvod zkoumat.

Nic z toho nebyla okrajová stížnost. Jensen Huang použil svůj první příspěvek na X, aby obhájil otevřené modely, společně s otevřeným dopisem podepsaný představiteli jako Meta, Microsoft a IBM. Dopis jasně nastavil bezpečnostní argument: ve světě, kde útočníci disponují pokročilou AI, obránci potřebují přístup k srovnatelným schopnostem. Andrew Ng podpořil argument a nasměroval čtenáře k Huangově obhajobě otevřených modelů. Můžete s nimi v mnoha věcech nesouhlasit a přesto uznat pravdu, když incidentní zpráva leží a potvrzuje to.

Takže během třiceti jedné let jsme přešli od banky zničené tím, že jeden muž viděl vše, k bezpečnostnímu nástroji, který důvěřuje anonymnímu útočníkovi více než svému zodpovědnému vlastníku. Leeson viděl příliš. Lidé, kteří úklid po Hugging Face prováděli, neviděli dost.

Srovnání není tak podivné, jak se na první pohled zdá. Finanční instituce se naučily, obvykle po nákladných chybách, že přístup není jen otázkou toho, zda je někdo důvěryhodný. Jde o to, zda by měl mít možnost provést konkrétní akci v konkrétním systému v konkrétním okamžiku, aniž by ho někdo jiný sledoval. Vybudovali jsme oddělení povinností, limity schválení a auditní stopy, protože dobré úmysly obvykle selhávají jako spolehlivý kontrolní mechanismus. AI systémy potřebují podobné uvažování. Označit model jako bezpečný vám řekne málo, pokud neznáte, co je povoleno a kdo jej používá.

Některé věci nesmí opustit budovu

Existuje druhý důvod, proč jsem tu noc nemohl spoléhat na hostovaný model, a nemá nic společného s jeho citlivostí. Řídím technologii pro regulovanou makléřskou firmu. Nemohu vložit naše protokoly o narušení, přihlašovací údaje a živé exploity do cizího cloudu a odeslat je.

Naše data o incidentech jsou uložena tam, kde je naši regulátoři očekávají – na našem vlastním hardwaru, a proto jsme strávili roky a obrovským rozpočtem na hardware tímto řešením. Nevytvořili jsme to z předvídavosti ohledně nebezpečných modelů. Vybudovali jsme to, protože firma jako naše uchovává svá nejcitlivější data a nyní i nejcitlivější nástroje vnitřně ve svých zdech.

Nic z toho není argument proti bezpečnostním zábranám. Je to argument pro to, abyste věděli, kam vaše zábrany směřují.

Model, který odmítá pomoci phisherovi napsat phishingový e‑mail, vykonává užitečnou práci. Model, který odmítá pomoci vašemu bezpečnostnímu týmu přečíst phishingový e‑mail, který již dorazil, dělá práci phishera za něj a navíc vám za to účtuje předplatné.

Mějte nástroj, který budete potřebovat ve 2 ráno.

Praktická lekce je nudná, stejně jako ty důležité. Nevyměňujte reakci na incidenty za pojistku odpovědnosti dodavatele. Uchovejte výkonný model na hardware, který vlastníte, zaměřený na úkoly, které komerční modely převážně odmítnou, a zjistěte, že existuje, ještě před nocí, kdy ho budete potřebovat.

Odměnou za roky obrany této hardwarové položky na neokázalých základnách se ukazuje toto: když nastane zajímavá porucha, už máte v budově jediný nástroj, který se podívá na důkazy.

Před třiceti jedním rokem jsem strávil víkend počítáním, co se stane, když špatná osoba může vidět vše. Tentokrát by bylo hezké být tím, kdo to může.