AI vám během chvíle napíše databázový dotaz, který vypadá rozumně. Jenže sloupec, ze kterého chce počítat tržby, ve vaší databázi vůbec neexistuje. Nový nástroj schema-guard se snaží tuhle chybu zachytit ještě před spuštěním dotazu nebo uložením souboru. Na jeho návrhu je ale zajímavější něco jiného: když agent stejný odmítnutý dotaz pošle znovu, kontrolní hook ho propustí.
To není objevená zadní vrátka ani důkaz, že projekt nefunguje. Je to výslovně popsané rozhodnutí autora, který nechce zastaralým seznamem sloupců zablokovat práci. A právě na něm je dobře vidět rozdíl mezi pomocníkem při vývoji a bezpečnostní bránou. Kontrola, která ustoupí opakovanému požadavku, může být užitečná. Nesmíme ji ovšem považovat za oprávnění pustit agenta do produkce.
Agent zná váš repozitář. Databázi si domýšlí
V dnešní rychlé zprávě o schema-guard jsme popsali základní princip: do repozitáře se uloží snímek skutečného databázového schématu a software proti němu ověřuje názvy v SQL. Snímek obsahuje tabulky, sloupce a jejich typy, nikoli řádky zákaznických dat nebo přístupová hesla. Agent tak dostane konkrétní seznam místo příležitosti hádat podle staré dokumentace.
Potíž se netýká jen jednoho malého projektu. Luke Hartzell a Gilberto Hernandez ji v září popsali na vývojářském blogu Snowflake: kontext souborů a kontext skutečného datového prostředí jsou dvě různé věci. Agent může číst modely, historii změn a dokumentaci, ale z toho ještě nezjistí, které sloupce dnes existují nebo co už někdo přejmenoval.
V převodu přirozeného jazyka na databázové dotazy, označovaném jako text-to-SQL, je taková mezera obzvlášť nepříjemná. Běžně znějící název může být přesně ten nesprávný: dokumentace používá customer_id, skutečná tabulka třeba cust_id. Model vytvoří přesvědčivý návrh, protože jazykově dává smysl. Databáze ovšem nerozhoduje podle přesvědčivosti.
Snowflake nabízí cestu přes živé připojení a nástroje, které agentovi zpřístupní aktuální prostředí. Schema-guard volí jiný kompromis: databázový přístup potřebuje člověk nebo proces pořizující snímek, samotný agent ho kvůli seznamu názvů mít nemusí. To je praktické třeba při přípravě analytického modelu v repozitáři bez přímého přístupu do datového skladu. Není to však bezúdržbové řešení: aktuálnost snímku musí někdo zajistit.
Tady dává obyčejný program větší smysl než další model
Podle aktuální dokumentace projektu lze stejný snímek používat v kontrolním hooku pro Claude Code, přes MCP i v průběžné integraci. Kontrola rozebírá SQL parserem a hledá neexistující názvy; nepotřebuje druhý jazykový model, který by posuzoval výstup prvního. Když zjistí problém, může agentovi vrátit i podobné skutečné názvy, aby návrh opravil.
Tohle je podle nás správná dělba práce. AI může navrhovat, jak se k výsledku dostat, ale existenci konkrétního sloupce nemá cenu řešit dalším odhadem. Jestli údaj patří do ověřitelného seznamu, má rozhodovat seznam a kontrolní program. Zlepšování modelů tuto povinnost neruší, stejně jako lepší programátor neruší potřebu kompilátoru.
Prakticky to pomůže při psaní nového reportu, úpravě staršího SQL souboru nebo kontrole změn před jejich začleněním. Projekt popisuje i kontrolu dotazů předávaných některým nástrojům a příkazovým klientům. Neznamená to však, že vidí každý způsob práce s databází: dynamicky skládané SQL v aplikačním kódu mezi jeho výslovně uvedené limity patří.
Snímek bez řádků dat navíc není automaticky veřejný dokument. Už názvy tabulek mohou prozrazovat vnitřní strukturu firmy nebo její procesy; i Snowflake před bezmyšlenkovitým ukládáním schématu do repozitáře varuje. Oddělení metadat od zákaznických záznamů je užitečné, ale pořád je potřeba rozhodnout, kdo smí metadata číst a do jakého modelu se mohou dostat.
Nula falešných blokací není nula chybných odpovědí
Autor schema-guard uvádí, že kontrola na 1 034 platných dotazech z vývojové části sady Spider nezablokovala žádný správný dotaz. To je výsledek publikovaný autorem, nikoli náš nezávislý test. Vypovídá o chování kontroly na konkrétní sadě, ne o tom, že všechny dotazy od agentů budou správné nebo že nástroj pokryje každou produkční databázi.
Dokumentace zveřejňuje také malý syntetický experiment, v němž agenti dostali repozitář se záměrně zastaralým README. Dodání aktuálního snímku odstranilo chyby v názvech, ale některé výsledky dál obsahovaly chyby ve výpočtu týdnů. Autor přiznává omezený rozsah i dodatečné doplnění některých referenčních odpovědí při hodnocení. Je dobře, že to nezamlčuje; pořád to není důvod odvozovat z experimentu univerzální spolehlivost.
Rozdíl si lze ukázat i bez benchmarku. Dotaz může správně najít existující sloupec s hrubou částkou, přestože zadání chtělo tržbu po odečtení vratek. Stejně tak může pracovat se správnou tabulkou, ale špatně stanovit začátek týdne. Kontrola názvů v obou případech splní svůj úkol. Chybný report tím nepromění ve správný.
Na širší problém jsme upozorňovali už v článku o AI agentovi s klíči od databáze. Nový projekt k němu přidává konkrétní, úzkou kontrolu; nepřebírá výklad firemních metrik ani odpovědnost za schválení výsledku. Zelená kontrolka u názvů sloupců tedy nesmí znamenat zelenou kontrolku u účetního závěru.
Napodruhé projde. A právě to si musíte přečíst
Nejdůležitější detail není v instalačním příkazu, ale v popisu situací, kdy nástroj mlčí. Hook při opakování totožného odmítnutého SQL dovolí pokračovat. Autor to zdůvodňuje tím, že ve skutečné databázi mohl mezitím přibýt nový sloupec a zastaralý snímek nemá uživatele zamknout mimo práci. Kód hooku jsme při rešerši přečetli: rozhodnutí odpovídá dokumentaci, nejde o pouhou interpretaci titulku.
Přitom nejde o živé ověření, že se schéma opravdu změnilo. Kód pozná opakovaný dotaz, nikoli důvod opakování. Pro interaktivní práci vývojáře to může být snesitelný kompromis. Pro bezobslužného agenta je ale podstatné, že naléhání neznamená správnost a opakovaný pokus nenahrazuje souhlas člověka.
Podobně projekt vědomě nehlásí problém u části SQL, které nedokáže bezpečně rozebrat, nebo u konstrukcí, do nichž nevidí. Takový přístup chrání použitelnost nástroje před falešnými poplachy. Zároveň znamená, že ticho není potvrzením úspěšné kontroly. Tým musí rozlišovat mezi „prověřeno bez nálezu“ a „tuhle věc kontrola neposoudila“.
Ani chování hooku nelze automaticky přenést na všechny integrační cesty. Dokumentace samostatné kontroly v průběžné integraci popisuje chybový návrat při neexistující tabulce nebo sloupci. Výjimka pro opakovaný pokus je konkrétní vlastností hooku, nikoli důkazem, že každá kontrola projektu napodruhé ustoupí. Při nasazení rozhoduje skutečně používaná cesta, ne jen název balíčku.
Dobrá pomocná kontrola potřebuje pevné hranice
Schema-guard bychom proto hodnotili jako pomocníka pro kvalitnější návrhy, ne jako oprávnění k větší autonomii. Před nasazením má tým určit, kdo aktualizuje snímek, jak se změny schématu kontrolují a které dotazy vyžadují test nad skutečnou databází. Kritické reporty potřebují také ověřené očekávané výsledky, protože existence sloupců neřeší význam čísel.
Další hranice patří mimo samotný nástroj: omezená databázová oprávnění, schvalování změn a oddělení vývoje od produkce. Jiný přístup ke stejné oblasti popisuje prototyp klienta Postquel, jehož AI asistent má podle popisu číst schéma, provádět pouze čtecí dotazy a změny předkládat uživateli. Ani tento popis není bezpečnostní audit; ukazuje ale, že kvalita návrhu a právo vykonat změnu jsou dvě samostatná rozhodnutí.
Na malém projektu s licencí MIT je nejcennější střízlivost jeho základní myšlenky: část problémů AI agentů se neřeší chytřejším chatbotem, ale přesnou informací a běžnou softwarovou kontrolou. Hranice ověření je také jasná: přečetli jsme dokumentaci, licenci a relevantní kód, vlastní benchmark ani provozní test jsme neprováděli. Tvrzení autora o výsledcích proto nepovažujeme za nezávisle potvrzenou kvalitu nasazení.
Užitečnost schema-guard stojí na tom, že chytá konkrétní chybu. Jeho bezpečné použití stojí na tom, že od něj nečekáme nic dalšího. Pokud nám další agent začne počítat firemní tržby, chceme správné názvy, správný výpočet i jasně vymezená oprávnění. Jedna kontrola může zařídit první část. Zbylé dvě za nás zelená kontrolka nevyřeší.
