PAR a AWS skladajú bezpečný text-to-SQL agent s riadkovou ochranou dát

AWS opísal produkčný návrh analytického agenta, ktorý je zaujímavý práve tým, že veľkému jazykovému modelu nedáva úlohu bezpečnostnej hranice. Prípadová štúdia vznikla s PAR Technology, dodávateľom systémov pre reštauračný priemysel, ktorý obsluhuje stovky prevádzok, franšíz a značiek. Cieľ bol lákavý: používateľ sa opýta prirodzeným jazykom na predaje, zásoby alebo výkon pobočiek a agent vygeneruje SQL dotaz aj zrozumiteľnú odpoveď. Problémom je, že rovnaká otázka môže mať pre rôznych používateľov úplne iný oprávnený rozsah dát.

Článok preto začína typickým príkladom multi-tenant analytiky. Majiteľ dvoch prevádzok v Chicagu a manažér značky s dvesto pobočkami sa môžu opýtať „aké boli tržby minulý týždeň“. Správna odpoveď pre prvého používateľa je lokálny súčet, pre druhého národný súčet. Obe odpovede môžu byť fakticky správne, ale zámenné z hľadiska bezpečnosti. Ak agent omylom vráti globálne číslo lokálnemu franšízantovi, nejde iba o drobnú halucináciu, ale o únik obchodne citlivých dát.

AWS a PAR preto odmietajú model, v ktorom sa do promptu vloží identifikátor zákazníka a čaká sa, že LLM ho vždy použije vo filtri. Jazykový model je užitočný na interpretáciu otázky a návrh SQL, ale nie je deterministický policy engine. Môže filter vynechať, zle pochopiť nejednoznačné zadanie alebo byť ovplyvnený prompt injection útokom. V spotrebiteľskej aplikácii by to bola chyba použiteľnosti; pri dátach viacerých zákazníkov v jednej analytickej vrstve je to chyba architektúry.

Navrhnutý systém preto skladá tri nezávislé vrstvy. Prvou je kryptograficky podpísaný kontext požiadavky pomocou AWS SigV4, ktorý viaže používateľovu identitu a oprávnenia na backendový tok. Druhou je sémantická validácia cez Amazon Bedrock: modelom navrhnutý dotaz sa kontroluje voči očakávanému zámeru, povoleným entitám a bezpečnostným pravidlám. Treťou je programová izolácia v SQL vrstve, ktorú článok opisuje ako Split-Plane SQL. Výsledný dotaz sa nespolieha na to, že LLM správne dopísal filter; pravidlá rozsahu sa aplikujú mimo modelu.

Pre podnikové tímy je toto dôležitá lekcia. Veľká časť agentických dem ukazuje, že model dokáže napísať SQL. Menej často sa rieši, kto ručí za to, že SQL nikdy neprekročí hranice zákazníka, roly alebo regiónu. PAR príklad posúva diskusiu od „vie to odpovedať?“ k otázke „čo sa stane, keď model urobí nesprávny návrh?“. Ak chybný návrh zastaví validačná vrstva alebo dátová rovina, chyba je zvládnuteľná. Ak chybný návrh priamo beží nad databázou, bezpečnosť stojí na pravdepodobnosti.

Tento rozdiel bude čoraz dôležitejší aj mimo reštauračného softvéru. Rovnaký vzor potrebujú banky, poisťovne, zdravotnícke siete, e-commerce platformy či SaaS produkty s vlastnou analytikou pre zákazníkov. Všade, kde sa prirodzený jazyk mení na dotaz nad zdieľanou dátovou vrstvou, treba oddeliť schopnosť modelu porozumieť otázke od právomoci rozhodnúť, ku ktorým riadkom sa používateľ smie dostať. Agent môže pomôcť s formuláciou, nie nahradiť autorizáciu.

Článok zároveň nepriamo nastavuje realistickejšiu latku pre „produkčných AI agentov“. Produkcia nie je len vyššia presnosť odpovedí alebo pekné rozhranie. Zahŕňa podpisovanie požiadaviek, sledovanie pôvodu kontextu, validáciu dotazov, auditovateľné rozhodnutia a ochranu pred kompromitovanou reláciou. To sú nudné vrstvy, ktoré v demo videu nevidno, ale rozhodujú o tom, či sa agent dostane k citlivým dátam.

Otvorenou otázkou zostáva, ako ľahko sa tento vzor prenáša do existujúcich dátových skladov a BI nástrojov. Split-Plane SQL, sémantická validácia aj podpisovanie kontextu vyžadujú disciplinovanú integráciu a jasný model oprávnení. Firmy, ktoré majú neporiadok v dátových rolách, ho LLM agent nezachráni; skôr ho zviditeľní. Hodnota príkladu od AWS je však v tom, že ukazuje konkrétny smer: bezpečný agent nie je model s lepším systémovým promptom, ale viacvrstvová aplikácia, v ktorej model zostáva jednou súčasťou riadeného toku.