AI bezpečnost pro podnik: od prompt-injection po tool-abuse, policy patterns a zero-trust pro nástroje

Proč AI bezpečnost řešit právě teď

AI už není pilot v sandboxu. AI systémy jsou připojené k e-mailu, kalendáři, dokumentům, CRM, ERP, mění data a vytvářejí transakce. Tam, kde jste dříve bránili web aplikaci před XSS a SQL injection, dnes bráníte AI agenta před prompt-injection a před tím, aby slepě provedl nebezpečný tool call. Rozdíl je v povaze interakce: místo pevného UI s validací vstupů mluvíte jazykem. A jazyk je tvárný. Útočník do konverzace vloží instrukce v PDF, v obrázku nebo v odkazovaném webu. Bez AI bezpečnost podnik přístupu skončí agent u škodlivých akcí s vašimi oprávněními.

• AI je spojené s nástroji - riziko eskaluje z reputační škody na přímé obchodní a právní dopady.
• RAG spojuje interní a externí zdroje - hrozí netransparentní exfiltrace informací a citlivin.
• Regulace a audit vyžadují vysledovatelnost - bez guardrails a logů neobhájíte rozhodnutí.
• Útočníci se učí rychle - jailbreaky a injection techniky se šíří a recyklují napříč modely.

Základní pojmy, aktéři a aktiva

Bezpečnost začíná modelováním. Kdo co může, kde jsou hodnoty a které vektory útoku jsou realistické?

Aktéři

• Legitimní uživatel - zaměstnanec nebo partner, který chce práci urychlit.
• Útočník - externí nebo interní. Cílí na zneužití agenta k akcím, k úniku dat nebo k paralyzování provozu.
• Agent - LLM aplikace, která může volat nástroje, číst data a generovat výstupy.
• Nástroj - akce či konektor: čtení souboru, zápis do CRM, e-mail, platba, volání API.

Aktiva

• Data - dokumenty, tabulky, PII, IP, smlouvy, ceny, strategie.
• Identita a klíče - účty, tokeny, API klíče, podpisové klíče.
• Integrace - přístup do systémů a oprávnění k zápisu.
• Reputace a shoda - důvěra zákazníků, auditní jistota, smluvní závazky.

Útočné plochy LLM systémů

Útočné plochy vznikají všude, kde se mísí jazyk a akce, kde je klasický input validation nahrazen přirozeným jazykem a kde agent konzumuje nestrukturované zdroje.

• Konverzace - chat okno, e-mail thread, meeting přepis.
• RAG kanály - PDF, wiki, web, obrázky s textem, tabulky, CAD.
• Nástrojové volání - funkce s vedlejším efektem a přístupem k datům.
• Prompt a konfigurace - systémový prompt, default politiky, parametry modelu.
• Supply chain - knihovny, modely, hosting, pre-prompt šablony, plug-iny.

Hrozby v detailu: prompt-injection, RAG exfiltrace, tool-abuse a další

Přehled hlavních rizik s příznaky, dopady a obranou.

Prompt-injection

Útočník vloží do vstupu instrukci, která přepíše pravidla agenta. Může být v textu, v PDF, v HTML, v obrázku přes OCR nebo v meta datech.

• Symptomy - agent ignoruje politiky, odhaluje tajemství, dělá nečekané kroky.
• Dopad - únik dat, spuštění nežádoucí akce, reputační škoda.
• Obrana - instrukční sandboxing, explicitní role a kontrakty, detekční filtry, izolace RAG obsahu od politik.

Jailbreak chaining

Kombinace více kroků, které obejdou jednotlivé zábrany. Například nejprve vynucení „debug“ režimu a poté směřovaná injekce do nástroje.

• Obrana - vícestupňové politiky, variace modelů pro ověřování, náhodné kontroly, challenge-response před rizikovou akcí.

RAG data exfiltrace

Agent citace a kontext slévá bez ohledu na ACL. Útočník navede otázku tak, aby získal interní informaci, kterou nemá vidět, nebo donutí agenta načíst externí zdroj s injekcí.

• Obrana - enforcement ACL při retrievu i při odpovědi, late-binding práv na úrovni pasáže nebo buňky, redakce citlivin, answer masking a citace s kontrolou oprávnění.

Tool-abuse a neřízené akce

Nevyžádané volání nástrojů nebo volání s nebezpečnými parametry. Příkladem je hromadná změna cen, odeslání e-mailů všem kontaktům, úprava práv v systému.

• Obrana - zero-trust pro nástroje, capability tokeny, read-only první, simulace a schvalování, limity a kvóty, just-in-time scope.

Data poisoning a prompt leakage

Útočník kontaminuje korpus dokumentů nebo logy tak, aby agent opakoval škodlivé instrukce. Nebo se snaží odhalit systémový prompt a bezpečnostní klíče.

• Obrana - příjem dokumentů přes karanténu a validace, kontrola metadat, content provenance, oddělení tajemství od promptu, nikdy nevkládat klíče do promptu.

Supply-chain rizika

Neověřený plugin, knihovna nebo modelová váha může obsahovat zadní vrátka. Model hostovaný třetí stranou loguje víc, než tvrdí.

• Obrana - seznam schválených zdrojů, podpisy a hash verze, smluvní závazky k logům, model cards a SBOM pro AI.

Overreliance a sociální inženýrství

Lidé a systémy slepě věří AI. To zvyšuje dopad i banální injekce. Útočník se tváří jako kolega a vede agenta k riskantní akci.

• Obrana - pravidlo dvojích očí pro akce nad prahem, vysvětlení důvodů akce, training a simulace s lidmi.

Denial of wallet a nákladové útoky

Drahé dotazy, velké soubory a generování s vysokou délkou způsobí neočekávané náklady nebo latence.

• Obrana - limity tokenů, soft quotas, early truncation, prioritizace front, detekce anomálií.

Policy patterns a guardrails, které fungují v praxi

Bezpečnost AI se neopírá jen o „lepší model“. Opírá se o politiku a kontrolní body v každém kroku.

• Instrukční hierarchie - systémové politiky mají přednost nad uživatelským a RAG kontextem. Politiky jsou krátké, neměnné a znovu vkládané do každého kroku.
• Vstupní validace - detekce injekčních frází, zakázaných vzorů, podezřelých odkazů, zakódovaných payloadů. Při nálezu se pokračuje v režimu nízké důvěry.
• Detekce na výstupu - před voláním nástroje i před zobrazením uživateli. Kontrola úniku tajemství, PII, citlivých řetězců, prompt leakage.
• Kontrakty pro nástroje - schéma a invarianta, které výstup modelu musí splnit, aby mohl být vykonán. Nesplní-li, vrací se do opravy.
• Read-only před write - první volání nástroje je náhled, druhé je commit. Mezi tím může proběhnout schválení nebo simulace.
• Schvalovací brány - u rizikových akcí vyžadovat potvrzení člověkem s plnou evidencí důvodů a kontextu.
• Citace a důkazy - generativní odpověď musí být doložena citacemi ze zdrojů, ke kterým má tazatel právo. Bez citacÍ má být odpověď označena jako hypotéza.

Zero-trust pro nástroje a akce

Základní princip: agent nikomu a ničemu nevěří implicitně, ani sobě. Každá akce je explicitně povolena, omezená a sledovaná.

1. Capability tokens - jednorázová oprávnění s úzkým rozsahem, časovou platností a limity. Předává je policy broker, ne model.
2. Scope a kontext - nástroj vidí jen data, která jsou explicitně povolena pro danou akci a uživatele.
3. Simulace a suchý běh - u risku nejprve simulace. Například „zobraz, co by se změnilo v CRM“ místo okamžité editace.
4. Quotas a rate limits - tlumí škody i při selhání. Limity na počet akcí za čas a na objemy dat.
5. Two-person rule - citlivé akce vyžadují druhý pár očí. Agent připraví, člověk potvrdí.
6. Audit a nepopiratelnost - podepisovat akce a logy, abyste prokázali, kdo co spustil.

Identita, autorizace a audit pro agenty

Agent nesmí běžet pod superuživatelem. Potřebuje vlastní identitu a jemnozrnná práva.

• Service identity - každý agent a subagent má unikátní identitu a klíče. Nic se nesdílí.
• On-behalf-of - akce se dějí jménem uživatele s jeho právy, ne s právy agenta, pokud to dává smysl.
• Segregace prostředí - oddělit vývoj, test, produkci a data. Přístupové klíče rotovat a mít break-glass postup.
• Plný audit - konverzace, retrievery, nástroje, rozhodnutí, důkazy, schválení. Zároveň respekt retention a soukromí.

Data: klasifikace, minimalizace a ochrana tajemství

Nejlepší obrana proti úniku dat je, když se citliviny do kontextu vůbec nedostanou.

• Klasifikace - štítky citlivosti a ACL se propisují do RAG a do odpovědí. Bez štítků je chaos.
• Minimalizace - dávkovat jen nezbytný kontext, preferovat odkaz s kontrolou práv před injektováním celých dokumentů.
• Redakce - automaticky maskovat PII a tajné řetězce v retrievu i v odpovědi.
• Secrety mimo prompt - klíče a tajemství žijí ve vaultu. Prompt obsahuje reference, ne hodnoty.
• Provenance - uchovávat původ dokumentu, verzi, hash a cestu změn, abyste odhalili poisoning a dokázali zdroj.

Referenční architektura bezpečného AI stacku

Popis architektury end-to-end, která mapuje předchozí principy.

1. Ingest a katalog - validace a klasifikace dokumentů, karanténa pro nové zdroje, kontrola metadat, hashování.
2. RAG a vyhledávání - indexy s enforcementem ACL, redakce v pipeline, citace na úrovni pasáže či buňky.
3. LLM a politiky - systémové prompt politiky, detekční filtry před a po, krátkodobá paměť.
4. Policy broker - převod požadavků na capability tokeny, šablony schémat pro nástroje, logování rozhodnutí.
5. Nástrojová vrstva - read-only by default, simulace a commit, kvóty, podpis akcí, reverzní validace výsledku.
6. Observabilita - trace každého kroku, metriky rizika, alerty, integrační logy, privacy-safe maskování logů.

Evaluace, red-teaming a měření rizika

Bez průběžného testování se i robustní systém časem otevře. Potřebujete automatizovanou sadu útoků a metriky odolnosti.

• Attack corpora - katalog prompt-injection vzorů, jailbreaků, RAG exfiltračních dotazů, nebezpečných kombinací nástrojů.
• Success rate - míra, s jakou útok prolomí politiku nebo vyvolá nežádoucí akci. Sledujte trend a regrese.
• Risk tiers - testy škálujte podle kritičnosti nástrojů. Platby mají přísnější práhy než generování meeting pozvánky.
• Human red-team - pravidelné kampaně s cílem obejít politiky. Odměňujte nálezy, standardizujte reportování.
• Blue-team dashboard - propojte výsledky do backlogu a risk registru. Každé oslabení má ownera a termín nápravy.

Observabilita, detekce a incident response

Incidenty v AI nejsou jen úniky. Jsou to i chybné akce, toxické odpovědi a nákladové runaway. Reagovat musíte rychle a s důkazy.

• Telemetry - kontextové logy na vstupu a výstupu, rozlišené citlivosti. Události z policy brokeru a nástrojů.
• Alerty - podezřelé vzory frází, opakované odmítnutí politik, nárůst chyb nástrojů, skok v nákladech.
• Circuit breakers - když to hoří, vypněte rizikové nástroje, přepněte model na konzervativní režim, dočasně pauzněte RAG.
• IR playbook - kroky, role, komunikace, forenzní sběr, zákonné lhůty, post-mortem a nápravná opatření.

Compliance, soukromí a řízení rizik

AI přináší specifika, ale principy zůstávají: účel, minimalizace, přístupová práva, audit a spolupráce s právním a risk týmem.

• Účel zpracování - pro každý use-case definujte právní základ a účel, uchovávejte jen nezbytná data.
• Privacy-by-design - redakce PII, anonymizace v logách, retenční doby, práva subjektů údajů.
• Third-party modely - smluvní ujednání o datech a logování, umístění dat, možnosti auditu, penetrační testy.
• Risk governance - AI risk registr, komise pro bezpečnost AI, periodické review a schvalování změn politik.

KPI a risk metriky pro AI bezpečnost

Co neměříte, to neřídíte. Navržené metriky pro AI bezpečnost podnik program.

• Attack success rate - procento úspěšných útoků v automatizovaných testech.
• Policy violation rate - podíl odpovědí, které by bez zásahu porušily politiku.
• Tool misuse prevented - počet zablokovaných nebo schválením zachycených rizikových akcí.
• Mean time to detect a contain - rychlost reakce na incidenty.
• False positive rate - kolik legitimních akcí bylo zbytečně zablokováno.
• Cost containment - ušetřené náklady díky quotas a optimalizacím.

Playbooky a checklisty

Checklist pro hardening LLM agenta

• Krátké, neměnné systémové politiky v každém kroku.
• Vstupní a výstupní detekční filtry, logika nízké důvěry.
• RAG s enforcementem ACL a redakcí citlivin.
• Povinné citace se zpětnou kontrolou práv.
• Oddělení tajemství od promptu a rotace klíčů.

Checklist pro bezpečné nástroje

• Capability tokeny s úzkým rozsahem a expirací.
• Read-only před commit, simulace a schválení.
• Kvóty, limity, idempotence a rollback.
• Podpis akcí a centralizovaný audit.

Checklist pro evaluace a red-teaming

• Katalog útoků s verzemi a měřením úspěchu.
• Automatizované běhy při každém releasu.
• Lidské kampaně a bug bounty pro interní týmy.
• Vázání nálezů na backlog a risk registr.

Checklist pro incident response

• ✔ Třídy incidentů, spouštěče a kontakty.
• ✔ Sbírání důkazů a forenzní postup bez úniku PII.
• ✔ Komunikační šablony a právní eskalace.
• ✔ Post-mortem, akční body a retesty.

Roadmapa adopce bez 30-60-90 klišé

Namísto fixních čísel postavte cestu na kapitolách, které se překlápějí podle toho, jak plníte výstupní kritéria.

Kapitola 1 - základ a inventura

• Mapujte use-case, citliviny a nástroje. Založte AI risk registr.
• Vyberte první agenta a omezte jeho oprávnění na minimum.
• Definujte systémové politiky, detekční filtry a logging.

Kapitola 2 - pilot s nulovou tolerancí pro riziko

• Zapněte read-only režim, všechny akce jen simulace.
• Proveďte red-team kampaň a automatizované evaly.
• Upravte politiky, dokud attack success rate neklesne pod práh.

Kapitola 3 - řízený write a schvalování

• Povolte vybrané nástroje s capability tokeny a kvótami.
• Zaveďte schválení pro akce nad prahem a audit podpisem.
• Měřte false positives a dolaďte hranice.

Kapitola 4 - škálování a standardizace

• Standardizujte šablony promptů, politik a nástrojových kontraktů.
• Rozšiřte agenty do dalších domén, držte segmentaci dat.
• Regulárně rotujte klíče, provádějte penetrační testy.

Kapitola 5 - kultura a kontinuální zlepšování

• Školte týmy, sdílejte incident lessons learned.
• Automatizujte evaluace v CI a vynucujte release gates.
• Propojte náklady, rizika a benefity do jednoho řízení.

FAQ

Je bezpečnější zakázat AI přístup k nástrojům úplně

Ne. Získáte sice klid, ale přijdete o hodnotu. Cílem je zero-trust orchestrace: úzké capability tokeny, simulace, schválení, audit. Zákaz bývá dočasný krok při incidentu, ne strategie.

Jak se bránit prompt-injection, když model „chce pomáhat“

Kontrakty a role. Model nemá volné ruce. Základ tvoří krátké systémové politiky, detekce a delegace rozhodování na policy broker, který dává capability tokeny jen pro konkrétní akci.

Co s RAG, který spojí interní a externí zdroje

Vynucovat ACL na retrievu a při citaci, redigovat citliviny a držet evidenci původu. Externí zdroje vkládejte s nízkou důvěrou a vždy je oddělujte od politik.

Jak řešit útoky přes obrázky a PDF

OCR a parser běží v sandboxu, extrahovaný text proženete detekcí. Neznámé dokumenty prochází karanténou, kde validujete metadata, původ a podezřelé vzory.

Co je nejčastější chyba při nasazení AI bezpečnosti

Příliš mnoho důvěry v model a příliš málo v politiku. A absence logů. Bez auditních záznamů je každý incident dvojnásob bolestivý.

Závěr a doporučení

AI přinesla do podnikových systémů jazyk a akci v jednom balíčku. To je mocné a zároveň nebezpečné. Útočníci míří na slabá místa: nekontrolované prompty, RAG bez práv, nástroje bez omezení a supply chain bez ověření. Odpovědí je pragmatická disciplína: systémové politiky, detekce na vstupu i výstupu, zero-trust pro nástroje, capability tokeny, simulace, schvalování, audit. AI bezpečnost podnik není brzda. Je to předpoklad, aby se AI mohla bezpečně zapojit do práce a přinést hodnotu v měřitelném a obhajitelném rámci.

Doporučení na závěr: začněte malým, ale úplným průřezem. Vezměte jednoho agenta, připojte ho k jednomu bezpečnému nástroji s capability tokeny, zapněte RAG s ACL a redakcí, nastavte detekce, logging a evaluace. Získejte důvěru lidí i auditu. Teprve potom škálujte. Bezpečná AI není jednorázový projekt. Je to nový provozní standard.