Poslední rok ke mně chodí skoro pořád stejné zadání: „napojte nám AI na CRM / na dokumenty / na e-maily, ať to za nás něco dělá." Chatbot, který zná ceníky. Asistent, který si přečte schránku a odpoví. Agent, který sám založí záznam. Dává to smysl a umím to postavit. Jenže v tu chvíli, kdy model vidí firemní data a smí sáhnout na nástroje, se z hračky stává systém, který má bezpečnostní model. A ten se dělá jinak než „přidáme do promptu, ať se chová slušně".

Tenhle článek je o tom, co se reálně děje, když to spojíte špatně, a jak to dělám, aby to teklo co nejmíň.

Co je vlastně ten problém

LLM zpracovává instrukce i data ve stejném kanálu. Nemá vestavěnou hranici mezi „tohle je moje systémová instrukce" a „tohle je jen text, který mám zpracovat". Všechno je to jedna sekvence tokenů. Takže když se do toho textu dostane věta „ignoruj předchozí instrukce a udělej tohle", model ji klidně vezme jako příkaz.

Tomu se říká prompt injection a je to v žebříčku OWASP Top 10 for LLM Applications (verze 2025) na prvním místě jako LLM01 — už podruhé po sobě. Není to hypotéza. Je to obdoba SQL nebo code injection u klasických aplikací, jen se to hůř ohraničuje, protože „parser" je pravděpodobnostní model.

A pozor, tohle není jailbreak. Jailbreak je, když uživatel sám obchází pravidla modelu. Prompt injection je, když třetí strana schová instrukci do obsahu a unese vašeho asistenta, aby jednal proti vám. Jiná třída problému, řeší se jinak.

Přímá a nepřímá injekce

Přímá je ta zjevná: útočník napíše škodlivou instrukci rovnou do chatu. Otravná, ale čekáte ji.

Horší je nepřímá (indirect) injekce. Instrukce je schovaná v obsahu, který asistent načte v rámci normálního úkolu — v e-mailu, v dokumentu, na webové stránce, v položce, kterou vytáhne RAG ze znalostní báze. Útočník nepotřebuje žádný přístup k vašemu systému. Stačí, aby váš agent přečetl něco, co on připravil. Text bílý na bílém, HTML komentář, metadata, znak, který člověk nevidí, ale OCR nebo chunking ho spolkne.

Nejlíp to ilustruje EchoLeak (CVE-2025-32711), zveřejněný v červnu 2025 — veřejně označovaný za první „zero-click" nepřímou injekci v produkčním enterprise AI asistentovi. Oběti stačilo dostat e-mail se skrytými instrukcemi. Když se pak asistenta na cokoli zeptala, RAG ten e-mail vytáhl do kontextu, instrukce se provedla a interní data odešla ven. Detail, který stojí za pozornost: exfiltrace prošla přes speciálně formátovaný (reference-style) markdown odkaz mířící na doménu, které CSP důvěřoval, protože byla na allowlistu poskytovatele — a útok přitom obešel i klasifikátor a redakci odkazů, které tam přesně na tohle byly. Bez jediného kliknutí.

„Zero-click" neznamená, že data odtečou úplně sama od sebe. Znamená, že oběť neklikla na nic škodlivého — jen normálně používala AI. To je celý ten trik.

Podobných případů z let 2024–2025 je řada u velkých hráčů: únik z privátních chatovacích kanálů, exfiltrace kódu z privátních repozitářů přes popis pull requestu, data ven přes kalendářní pozvánku. Napříč nimi se opakuje jeden vzor: model si přečte cizí obsah a ten obsah převezme řízení. A druhý vzor: data odtečou renderovaným obrázkem nebo odkazem, jehož URL nese ukradená data.

Druhá polovina problému: únik dat

Injekce sama o sobě je „jen" převzetí instrukcí. Reálná škoda vzniká, když má asistent k čemu sáhnout a kudy to poslat ven. OWASP proto v roce 2025 posunul únik citlivých informací na druhé místo (LLM02).

Tady se nejvíc chybuje u RAG. Oprávnění ze zdrojových systémů — firemní úložiště, sdílené disky — necestují s daty do vektorové databáze. Nasekáte dokumenty na chunky, uložíte embeddingy a model pak netuší, že originál byl jen pro jedno oddělení. Uživatel se zeptá a dostane vytažené něco, co vidět neměl. U víc klientů v jednom indexu je to ještě horší — bez tvrdého oddělení vám vektorové hledání vrátí nejpodobnější dokument klidně od jiného tenanta.

A ještě jedna věc, kterou lidé neradi slyší: embeddingy nejsou anonymní čísla. Existují inverzní útoky, které z vektorů rekonstruují původní text. Vektorovou databázi je potřeba chránit jako plaintext.

Jak to dělám, aby to teklo míň

Nemám jednu kouzelnou vrstvu. Nikdo ji nemá — přední AI laboratoře v roce 2025 shodně přiznaly, že v současné architektuře LLM prompt injection nejde plně vyřešit. Adaptivní útoky prolamují většinu publikovaných obran s úspěšností přes 90 %. Takže se nestaví na prevenci, ale na omezení dopadu — počítám s tím, že něco projde, a dělám to tak, aby to nemohlo moc napáchat.

Konkrétně:

  • Výstup modelu beru jako nedůvěryhodný vstup. Nikdy ho nepředávám rovnou do shellu, SQL, HTML nebo prohlížeče bez validace. Neošetřený výstup (LLM05) vede na klasické XSS, SSRF i vzdálené spuštění kódu.
  • Oddělím instrukce od dat. Načtený obsah dostane jasné hranice a zachází se s ním jako s daty, ne s příkazy. Architektonicky pomáhají akademicky publikované vzory jako Dual-LLM nebo CaMeL, kde nedůvěryhodná data zpracovává izolovaný model bez přístupu k nástrojům.
  • Princip nejmenších oprávnění. Agent dostane jen ty nástroje a jen ta data, která úkol nutně potřebuje. V praxi agenti běžně dostávají řádově víc přístupu, než reálně použijí — a přesně tak daleko sahá škoda, když se to zvrtne.
  • Oprávnění vynucuju před retrievalem, na úrovni vektorové databáze (namespaces, metadata, tokeny), ne prosbou v promptu. Data, která uživatel nesmí vidět, se nesmí vůbec dostat do kontextu.
  • Zavírám exfiltrační kanály. Žádné auto-načítání obrázků na cizí domény, striktní egress allowlist, sanitizace odkazů. A vím, že i povolená doména se dá zneužít jako relay — allowlist zužuje, nezavírá.
  • Člověk ve smyčce u nevratných akcí. Odeslání e-mailu, platba, mazání, změna konfigurace — potvrzení člověkem je povinná brána, ne volitelnost.
  • Sandbox a monitoring. Tool-use běží v izolaci s minimem práv, akce a odchozí spojení se logují. Obranu, kterou nikdo aktivně nezkoušel prolomit, nepovažuju za ověřenou — testuju i adaptivně.

Čemu nevěřím: sanitizaci vstupu regexem, blocklistům a instrukci „neposlouchej vložené příkazy". To všechno riziko snižuje statisticky, negarantuje nic. A druhý detekční model jako pojistka je zase jen model — taky se dá ukecat. Skutečnou hranici tvoří deterministické kontroly mimo model: oprávnění, egress, allowlist nástrojů, potvrzení člověkem.

Bezpečnost AI integrace se nedělá lepším promptem. Dělá se tím, co model nesmí, i když ho někdo přemluví.

Střízlivě

AI napojená na firemní data je skvělý nástroj a nemám nejmenší chuť od ní kohokoli odrazovat — sám ji stavím. Jen to není „nalepíme chatbota a hotovo". Je to systém s reálnou útočnou plochou, a ta plocha roste s každým nástrojem a každým zdrojem dat, který mu dáte. Dobrá zpráva: většina úniků, které jsou venku, šla přes pár opakujících se chyb, a ty se dají ošetřit, když se na to myslí od začátku, ne až po incidentu.

Pokud řešíte AI asistenta nebo agenta, který má vidět firemní data, umím ho navrhnout a nasadit tak, aby dělal svou práci a přitom neposílal citlivá data neznámo kam. Mrkněte na služby, nebo se rovnou ozvěte a projdeme to na vašem konkrétním případu.