Nejtěžší problémy bezpečnosti AI nyní existují mimo model

Přehled 2026 OWASP Top 10 for LLM Applications poskytuje kritický pohled na zralost produkční AI. Zachycuje zásadní posun: odvětví přechází mimo sandbox a potýká se s komplexitou reálné integrace.

Když připojíte LLM k podnikovým nástrojům a pracovním tokům, povrch hrozeb se zásadně mění. Rizika spojená s autoritou a využíváním zdrojů se stávají výrazně obtížnějšími k omezení. Současně se ztrácejí z popředí zranitelnosti, jako je nesprávná manipulace s výstupem, nikoli proto, že jsou vyřešeny, ale protože jiné problémy se dostaly do popředí.

Žebříček OWASP Top 10 odráží tento vývoj. „Excessive Agency“ postoupilo ze šestého na třetí místo, zatímco „Unbounded Consumption“ se vyšplhalo na šesté místo. Naopak „Improper Output Handling“ kleslo na desáté místo.

To nesnižuje riziko manipulace s výstupem. Pokud odpověď LLM dorazí do shellu nebo databáze bez důkladné validace, tradiční chyby injekce přetrvávají. Paradigma se však posunulo. V agentním systému není odpověď modelu cílem; je vstupem nesoucím autoritu. Když model drží přihlašovací údaje nebo komunikuje s API, jeho výstup funguje jako vektor, který může spouštět akce napříč různými systémy.

Bezpečnostní výzva již není jen vyhodnocení modelu; jde o definování hranic toho, co se stane po inferenci. Vaše architektura určuje, zda halucinace zůstane v textu, nebo se projeví jako neautorizovaná změna v databázi.

Pořadí odráží škodu

OWASP leveraged 7,714 incidents, 75% driven by community consensus, and 25% by empirical incident data. Tento důkazový základ vynutil skutečné přeuspořádání priorit.

„Excessive Agency“ vzrostlo, protože realita produkčních prostředí dohnala teorii. Organizace urychlují nasazení autonomních schopností rychleji, než zavádějí potřebné řídící vrstvy. Kritická zranitelnost není jen odpověď, kterou model poskytuje, ale autorizační kontext, ve kterém je tato odpověď vykonána.

Zatímco „Improper Output Handling“ zůstává problémem, DevOps týmy se zlepšily v zabezpečení downstream komponent pomocí validace schémat a parametrizovaných dotazů. Jedná se o osvědčené postupy v oblasti zabezpečení aplikací.

Agentura je však odlišná třída problému. Volání nástroje může být strukturálně platné, ale kontextově nelegitimní. Model může vyvolat schválenou funkci pro nevhodný úkol nebo zamířit na nesprávný zdroj. Statická sanitizace nedokáže posoudit záměr. To vyžaduje sofistikovanou, kontextově uvědomělou autorizaci, kterou by model nikdy neměl provádět samostatně.

Považujte každý nástroj za vystavenou schopnost

Mnoho týmů považuje definice nástrojů jen za integrační potrubí. To je poměrně směšná a zásadní chyba. Každý nástroj, konektor nebo koncový bod API rozšiřuje sféru vlivu AI aplikace.

Zvažte agenta navrženého k sumarizaci poštovní schránky. Pokud implementace používá široký konektor, který zahrnuje možnosti zápisu nebo mazání, zavádíte nadměrnou funkčnost ještě před tím, než je zpracován první prompt.

Musíte uplatnit princip nejmenších oprávnění:

• Zúžte rozhraní: Poskytněte agentovi nástroje jen pro čtení místo obecně použitelných konektorů.
• Rozsahovaný kontext: Provádějte požadavky v rámci OAuth-rozsahu uživatele.
• Policy Enforcement Points (PEP): Implementujte autorizační logiku jako povinný middleware mezi modelem a downstream systémy. Každá akce musí být před provedením ověřena vůči politice.
• Human-in-the-loop (HITL): Vyžadujte explicitní schválení pro operace, které jsou obtížně reverzovatelné nebo mají vysoký materiální dopad.

Tento přístup vyžaduje posun v dodavatelském řetězci. Váš revizní proces se musí rozšířit mimo model a zahrnout změny ve schématech nástrojů, identitách služeb a rozsazích oprávnění. Aktualizace modelu může vypadat neškodně, ale změna autorizačního kontextu konektoru může vytvořit katastrofální zranitelnost.

Viditelnost je nevyjednatelná. Musíte zaznamenat konkrétní spuštění nástroje, autorizující identitu a výslednou změnu v cílovém systému. Tento řetězec odpovědnosti je zásadní pro reakci na incidenty, umožňuje přerušit aktivní proces a po incidentu rekonstruovat auditní stopu.

Každý autonomní běh potřebuje pevné zastavení

„Unbounded Consumption“ vzrostlo, protože objem požadavků je nedostatečným měřítkem pro riziko zdrojů. Jeden stručný prompt může spustit rekurzivní, zdroje náročný řetězec volání nástrojů. Měřič se nezastaví, dokud agent nedokončí.

Jednoduché upozornění není dostačující, když rychlost provádění převyšuje lidskou reakci. Potřebujete deterministické, pevné limity, které zůstávají mimo kontrolu agenta. Implementujte přísné limity pro spotřebu tokenů, uplynulý čas, hloubku rekurze a kumulativní provozní náklady. Pokud vykonání překročí tyto parametry, systém musí běh ukončit nebo zpomalit.

Rozsah operací vyžaduje podobnou přísnost. Určete maximální počet záznamů, které může agent upravit, a definujte hranice šíření úkolů. Pokud vaše architektura postrádá deterministický mechanismus „stop“, v podstatě delegujete pravomoc bez definování jejího okraje.

Stavět pro špatnou odpověď

Systémové inženýrství se již dlouho spoléhá na odolnou architekturu k zabezpečení inherentně nespolehlivých komponent. Očekáváme selhání komponent a nestabilitu sítě; bezpečnost vychází z tohoto předpokladu, nikoli z iluze dokonalosti. LLM vyžadují stejnou architektonickou disciplínu.

Nezakládejte svou bezpečnostní strategii na předpokladu dokonalého zarovnání modelu. Předpokládejte selhání, ať už jde o neškodné nedorozumění nebo škodlivé zneužití. Omezte schopnosti agenta na absolutní minimum potřebné a udržujte přísné kontexty uživatelských oprávnění pro všechny následné volání. Klíčové je, aby vynucování politiky existovalo mimo model a zabránilo tak injekci promptu nebo chybám v uvažování obejít vaše kontroly.

Prompt Injection nyní vnímáme spíše jako zákon fyziky než jako zranitelnost. Vždy bude přítomna. Faktem je, že samotné modely nemohou být efektivními rozhodčími u otázek kritických pro bezpečnost. V reálném agentním projektu, který buduji, máme asi 100 automatizovaných testů „červeného týmu“. Dbáme na to, abychom je všechny prošli. Děláme to tím, že stavíme pevné kontroly mimo model. Můžeme je vypnout a sledovat míru úspěšnosti jen modelu. Nejstarší, nejslabší model, který testujeme, selže 17 % času. Nejnovější, největší model selže 2 % času. Skvělý pokrok, že? Ale je 98 % dostatečné, když každé selhání znamená únik citlivých dat? V žádném případě.

Operace s vysokým dopadem musí být pozorovatelné, auditovatelné a ideálně reverzibilní. Každé autonomní provedení vyžaduje neměnné ohraničení, které zůstává mimo dosah modelu.

Žebříčky z roku 2026 skutečně osvětlují, kde selhání AI přecházejí do hmotných důsledků. Model může chybu iniciovat, ale architektura určuje dosah výbuchu. Pro produkční AI probíhá nejkritičtější bezpečnostní práce v post‑inferenčním pipeline.