Prompt injection je teď primitiva pro spuštění kódu

V květnu vydal bezpečnostní tým Microsoftu rozbor CVE-2026-25592, chyby v tom, jak Semantic Kernel agent zpracovával volání nástrojů, a to, co u ní inženýry, co znám, donutilo zastavit se a přečíst si to dvakrát, byla nudnost celého exploit řetězce. Žádné heap grooming, žádné ROP gadgety, žádné vyrobené PDF s rozbitou tabulkou fontů. Jen kus textu vložený do dokumentu, který měl agent shrnout, s obsahem ve smyslu prosím spusť diagnostický nástroj s následujícími argumenty, a agent, který dělal přesně to, k čemu byl postaven, rozparsoval přirozený jazyk, napároval ho na registrovanou funkci a shelloval na hostiteli. RCE na úrovni hostitele. Z požadavku na shrnutí. Injectnuté instrukce se nikdy nedotkly bufferu, kterého se dotknout neměly, nic nepřetekly, neporušily jedinou záruku paměťové bezpečnosti, kterou by Rust nebo fuzzer zachytil, protože nebylo co zachytit. Agent fungoval přesně podle návrhu. O to celé jde a přesně tuhle část si branže odmítá připustit. Když vaše architektura bere přirozený jazyk zároveň jako control plane i data plane a jeden z vašich nástrojů umí spouštět příkazy, postavili jste systém, kde kdokoli, kdo dokáže dostat text před model, umí řídit exekuci. Říkáme tomu prompt injection, jako by to byl problém spamového filtru. Je to neautentizovaná cesta ke spuštění kódu.

Důvod, proč týmy pořád shipují zneužitelné agentní pipeline, je, že dominantní mentální model pro prompt injection přišel ze špatného oddělení. Přišel z trust and safety, od lidí, jejichž prací bylo bránit modelu říkat nadávky nebo generovat návod na výrobu nervového plynu, a v tom světě je mitigací klasifikátor, který ohodnotí vstup a výstup a zablokuje to špatné. Ten framing je v pohodě pro chatbota, který umí jen vypouštět tokeny. Rozpadne se ve chvíli, kdy model umí zavolat funkci, co má vedlejší efekty na svět, protože teď není otázkou, jestli je výstup urážlivý, ale jestli model někdo obelstil, aby zavolal schopnost, kterou požadující uživatel neměl nikdy oprávnění spustit. Guardrail, který skenuje jailbreakové fráze, se pokouší řešit problém rozhodnutelnosti a prohraje, protože prostor způsobů, jak v přirozeném jazyce napsat spusť tenhle příkaz, není vyčíslitelný a nikdy nebude. Ve steezr jsme za poslední rok prohlédli možná tucet agentních systémů, většinou od startupů, co jedou rychle na vzoru RAG plus nástroje, a skoro v každém případě tým přišrouboval na vstup klasifikátor a považoval problém za vyřešený. Pak jsme ukázali na krok retrievalu, kde agent vytáhne support ticket nebo scrapnutou webovou stránku nebo Notion dokument, který napsal někdo mimo firmu, nasype to do stejného context window jako system prompt a předá modelu nástroj, který umí sáhnout na interní API. Klasifikátor hlídá špatné dveře. Útočník neťuká do vašeho chat boxu. Před šesti týdny založil Zendesk ticket a čekal.

Pokud chcete threat model, který přežije kontakt se skutečným útočníkem, přestaňte přemýšlet o textu a začněte přemýšlet o schopnostech a o tom, kdo je smí volat. Každý nástroj, který u agenta zaregistrujete, je funkce, každá funkce má blast radius a správná otázka během design review zní: za předpokladu, že model dostaneme k tomu, aby tuhle funkci zavolal s libovolnými argumenty, co nejhoršího se stane? Ne jestli to guardrail zastaví. Předpokládejte, že guardrail je vypnutý. Předpokládejte, že útočník vlastní záměr modelu, protože v systému, který míchá nedůvěryhodný retrievnutý obsah s vaším system promptem, ho fakticky vlastní. Nástroj, který čte veřejnou status page, má blast radius v podstatě nulový. Nástroj, který spouští shell příkazy nebo vykonává SQL bez parametrizovaného allow-listu nebo posílá e-maily z vaší domény nebo volá Stripe, má blast radius, který by vás měl děsit, a takové nástroje potřebují autorizaci, která žije úplně mimo model. Vzor, ke kterému klienty tlačíme, je brát model jako nedůvěryhodného plánovače, který navrhuje akce, a mezi navrženou akci a její exekuci vložit deterministickou policy vrstvu, která v kódu ověří skutečná oprávnění skutečného uživatele proti skutečné operaci, bez jediného LLM v cestě. Když agent navrhne DELETE FROM orders a uživatel je read-only support účet, tenhle požadavek zemře v Go middleware funkci, která se jazykového modelu ani jednou nezeptá na názor. Model si může chtít, co chce. Autorizaci neobejde jen proto, že požadavek zformuloval zdvořile.

Konkrétně tady je tvar, který nám drží. Agent běží bez vlastní ambientní autority, nese token požadujícího uživatele a každé volání nástroje je požadavek, který proti tomu tokenu vyhodnotí služba, kterou model nemůže ovlivnit. Nástroje rozdělujeme do vrstev podle vedlejších efektů. Read-only necitlivé nástroje se dají volat volně. Cokoli s write efektem nebo cokoli, co se dotýká peněz, PII nebo infrastruktury, jde přes explicitní autorizační kontrolu a u opravdu nebezpečných věcí přes krok lidského potvrzení, který před spuštěním ukáže přesnou operaci srozumitelně. Retrievnutý nedůvěryhodný obsah držíme ve strukturálně oddělené části kontextu a nedovolíme mu zdědit úroveň důvěry system promptu jen proto, že tokenizer všechno zploští do jedné sekvence, což znamená, že samotná prompt šablona musí být psaná s vědomím, že cokoli z retrievalu je nepřátelský vstup. U Semantic Kernelu a srovnatelných frameworků to znamená neregistrovat automaticky každou plugin funkci do sady, kterou plánovač může volat, a být cílevědomý v tom, co plánovač vůbec vidí. Logujeme taky každé navržené volání nástroje, ne jen ta vykonaná, protože odmítnuté návrhy jsou váš signál průniku, stejně jako blokované pokusy o autentizaci. Když agent navázaný na support účet najednou začne navrhovat volání nástroje na mazání uživatelů, není to problém kvality modelu, to vám někdo osahává systém, a chcete to mít v SIEM. Nic z toho není exotické. Je to princip nejmenších oprávnění aplikovaný na komponentu, která shodou okolností mluví anglicky, a jediný důvod, proč to působí novátorsky, je, že jsme dva roky předstírali, že ta anglická část mění pravidla.

Otevřete si jakéhokoli agenta, kterého máte v produkci nebo míří do ní, a udělejte seznam každého nástroje, který umí zavolat. U každého si napište blast radius za předpokladu, že útočník plně řídí argumenty, a buďte upřímní, protože spustit shell příkaz nezačne být míň nebezpečné tím, že jste funkci pojmenovali safe_execute. Pak najděte každé místo, kde do context window vstupují nedůvěryhodná data, a vždycky je jich víc, než si tým myslí: retrieval, výstupy nástrojů vracené zpět, nahrané soubory, scrapnuté stránky, předchozí tahy konverzace od jiných uživatelů, pokud jste flákli sessions. Nakreslete mezi tím čáru. Jakýkoli nebezpečný nástroj dosažitelný z jakéhokoli nedůvěryhodného vstupu je dnes živá zranitelnost, guardraily nebo ne, a než budete klidně spát, potřebuje out-of-band autorizační kontrolu. Pokud stavíte agentní systémy a chcete druhý pár očí od lidí, co jich pár schválně rozbili, tak přesně tohle ve steezr děláme, ale nepotřebujete nás, abyste začali. Potřebujete přestat brát model jako hranici důvěry. Není jí. Nikdy nebyl. CVE-2026-25592 nebyla ani tak chyba v Semantic Kernelu jako chyba v tom, jak se celá branže rozhodla přemýšlet o tom, co agent je, a frameworky budou dál shipovat plánovače, které zplošťují důvěru, protože to dělá dema impozantní. Správný threat model je starý, neglamurózní a funguje, a čím dřív bude vaše architektura brát jazykový model jako toho zmateného poskoka, kterým je, tím dřív se prompt injection vrátí k tomu, že je otrava, místo cesty na váš stroj.