Jazykový model může být dobře izolovaný, mít omezené nástroje a přesto dostat do kontextu něco, co tam nikdy být nemělo. Stačí vložit soubor .env, výpis z terminálu, screenshot nebo PDF. Projekt Preflight řeší právě tuto vrstvu: kontroluje celý požadavek ještě předtím, než opustí počítač a zamíří k modelu.
Na první pohled jde o obyčejnou lokální proxy. Poslouchá na jednom portu, přijímá OpenAI-kompatibilní požadavky a posílá je dál. Rozdíl je v tom, že mezi klienta a model vkládá kontrolní bod, který se nesoustředí jen na prompt. Prochází také výsledky nástrojů, vnořené argumenty, přílohy a data, která si s sebou programátorský agent nese z okolního systému.
Podle dokumentace projektu na GitHubu vznikl Preflight jako open-source software pod licencí MIT. Repozitář byl zveřejněn 20. září 2026, takže nejde o hotový produkt s dlouhou provozní historií. Je to čerstvý návrh bezpečnostní vrstvy, který ale dobře ukazuje, kam se problém s AI agenty posouvá.
Tajemství se do modelu nedostávají jen přes prompt
Když někdo řekne, že AI nemá vidět API klíč, obvykle myslí na text, který uživatel ručně napsal do chatu. U programátorského agenta je ale hranice mnohem méně přehledná. Model může dostat obsah souboru, výstup shellu, návratovou hodnotu nástroje, obrázek ze screenshotu nebo dokument přiložený k požadavku. Tajný údaj tak může projít do inference, aniž by ho člověk kdy vložil přímo do zprávy.
Preflight proto nejdřív rozebírá JSON a prochází jeho textové části včetně vnořených JSON argumentů nástrojů. Hledá rozpoznatelné tvary přístupových údajů – například tokeny pro známé služby, privátní klíče nebo JWT. Neopírá se přitom pouze o obecnou entropii. Autoři správně upozorňují, že zdrojový kód, logy a běžné prompty jsou samy o sobě plné náhodně vypadajících řetězců.
To je důležité omezení i důležitá výhoda. Systém, který označí každý dlouhý náhodný řetězec za tajemství, bude v praxi obtěžovat stejně jako systém, který nehlídá nic. Rozpoznání konkrétních formátů snižuje počet falešných poplachů, ale současně znamená, že neznámé nebo atypické tajemství může projít.
Obrázek a PDF nejsou bezpečná slepá místa
Nejzajímavější část projektu začíná u příloh. Preflight podle README dekóduje obrázky, kontroluje metadata, čte čárové kódy a používá lokální OCR. U PDF kombinuje extrakci textu, kontrolu objektů, práci s vloženými obrázky a OCR vykreslených stránek. Tajný klíč tedy nemusí být napsaný v textové vrstvě dokumentu – může být vyfocený na obrazovce nebo vložený jako obrázek uvnitř PDF.
Tohle je přesně typ problému, který běžná filtrace promptu přehlédne. Textový filtr vidí jen odkaz na soubor nebo zakódovaný obsah. Bez rozbalení přílohy se nedozví, co v ní skutečně je. Preflight se proto snaží kontrolovat celý materiál ještě před předáním dál a u vzdálených URL nepoužívá přihlašovací údaje určené pro nadřazený model.
Současně není fér z toho dělat neprůstřelný trezor. Samotná dokumentace přiznává, že OCR nedokazuje nepřítomnost každého vizuálně čitelného tajemství. Některé PDF funkce, šifrované dokumenty nebo nepodporovaný aktivní obsah mohou skončit chybou. Vynucovací režimy v takové situaci požadavek raději odmítnou, než aby předstíraly, že kontrola proběhla.
Tři režimy: upravit, zastavit, nebo jen varovat
Výchozí režim se jmenuje redact. Když Preflight najde známý tajný údaj v textu, nahradí ho zástupnou hodnotou typu [REDACTED:github-pat] a požadavek pošle dál. U podporovaných příloh se pokusí vytvořit sanitizovanou kopii. Pokud bezpečná náhrada není možná, vrátí chybu místo toho, aby riskoval odeslání původního obsahu.
Přísnější režim no-go zablokuje každý nález, který není na seznamu povolených výjimek. Je vhodný tam, kde je důležitější jistota než pohodlí. Třetí režim advisory pouze hlásí nálezy a původní požadavek propustí. Hodí se pro ladění pravidel, ale nesmí se zaměnit za ochranu – tajemství se v tomto režimu k modelu dostat může.
Zajímavý je také způsob, jak projekt pracuje s výjimkami. Takzvaný carnet nefunguje jako široký seznam regulárních výrazů, které umlčí celou část dokumentu. Výjimka se váže na přesný hash konkrétní hodnoty. Je to méně pohodlné než globální allowlist, ale výrazně hůř se tím omylem povolí celá skupina podobných tajemství.
Bezpečnostní proxy nesmí být jen další průchod pro data
Největší přínos Preflightu není v tom, že přidává další detektor klíčů. Podstatná je myšlenka, že rozhodnutí o odeslání požadavku nemá dělat samotný model ani klient, který mu věří. Celé tělo požadavku se má nejprve prohlédnout, teprve potom může pokračovat k inference.
To je podobný posun, jaký jsme popisovali u izolace MCP serverů. Kontejner může oddělit proces od hostitele, ale neřekne, jestli agent smí poslat obsah dokumentu do externí služby. U MCP se řeší oprávnění nástrojů, sítě a tajemství. U Preflightu se stejná otázka přesouvá přímo na hranici mezi agentem a modelem: co přesně opouští lokální prostředí?
V praxi to může být užitečné například u vývojářského týmu, který nechce zakázat AI agentům práci s repozitáři, ale současně nechce spoléhat na to, že každý uživatel uhlídá své logy a přílohy. Proxy může zachytit běžné omyly – vložený token, screenshot s klíčem nebo omylem přiložený konfigurační soubor – dříve, než se z nich stane problém u poskytovatele modelu.
Cache pomůže výkonu, ale přidává další citlivé místo
Kontrola obrázků a PDF není zadarmo. Preflight proto používá content-addressed cache: při stejných datech, stejném rozsahu oprávnění a stejném profilu kontroly může znovu použít hotový výsledek. To omezuje opakované OCR nad totožnou přílohou a dává smysl hlavně u agentů, kteří posílají podobné soubory v několika krocích.
Cache ale není detail, který lze schovat do poznámky pod čarou. Obsahuje verdikty a může obsahovat sanitizované artefakty. Projekt ji proto ukládá do soukromého úložiště, omezuje její velikost a nabízí živé mazání záznamů. Ani to však není forenzní vymazání ze snapshotů a záloh. Každý, kdo Preflight nasadí, musí řešit stejnou otázku jako u logů: co se ukládá, jak dlouho a kdo k tomu má přístup.
Model není jediný problém v řetězci
Preflight také ukazuje, proč nestačí mluvit o bezpečnosti modelu jako o vlastnosti jednoho API. Model může být opatrný, ale do požadavku se dostane tajemství ještě před jeho zpracováním. Nebo může být prompt čistý, jenže agent si do kontextu přinese výsledek nástroje, který obsahuje citlivá data. Riziko vzniká v celém toku – od souboru přes klienta a proxy až po poskytovatele inference.
Na Radyz jsme už psali o případech, kdy se AI agent dostal za hranici původně zamýšleného sandboxu. Preflight řeší jiný směr stejného problému. Nehlídá primárně, kam se agent může dostat, ale co může z prostředí vynést. Jedna vrstva bez druhé nestačí.
Dobrá myšlenka, ne hotová garance
Preflight je zatím čerstvý projekt a jeho vlastní testy nemohou prokázat univerzální kompatibilitu se všemi klienty, poskytovateli a formáty dokumentů. README popisuje jednotkové, integrační a diferenciální testy, ale také výslovně říká, že živé účty poskytovatelů a univerzální kompatibilita s harnessy nejsou součástí ověření. To je přesnější tvrzení než obvyklé „ochrání vás před únikem“.
Přesto je směr správný. Ochrana AI systému nemůže končit u modelu, protože model často vidí až poslední část řetězce. Pokud agent pracuje se soubory, screenshoty, PDF, nástroji a externími službami, musí existovat místo, které umí kontrolovat celý požadavek – a v případě nejistoty ho zastavit.
Nejrozumnější role pro podobnou proxy proto není slib absolutní bezpečnosti. Má zachytit běžné nehody, zpřehlednit rozhodování a vytvořit poslední hranici před odesláním dat ven. Když k tomu přidáme omezená oprávnění, izolované nástroje, krátkodobá tajemství a auditní logy bez citlivého obsahu, dostaneme bezpečnostní systém. Samotný model ani samotný filtr ho nenahradí.
