Prompt injection proti AI agentom: samotný systémový pokyn nestačí

Riziko prompt injection pri AI agentovi znížite viacvrstvovou obranou: cudzí obsah spracúvajte ako nedôveryhodné dáta, agentovi prideľte iba potrebné oprávnenia a každé volanie nástroja kontrolujte mimo modelu. Odoslanie údajov, mazanie či vykonanie kódu podmieňte samostatným schválením. Systémový pokyn určuje správanie agenta, ale sám nevynúti, čo smie nástroj vykonať.

Útok môže začať v podklade, ktorý agent potrebuje na oprávnenú úlohu. NIST v opise únosu agentov vysvetľuje, ako škodlivý pokyn v e-maile, súbore alebo na webe môže presmerovať následnú akciu. Obrana preto musí udržať hranicu medzi čítaním cudzieho obsahu a rozhodnutím, čo sa skutočne vykoná.

Oddeľte cudzí obsah od pokynov pre agenta

Najprv spíšte miesta, odkiaľ agent prijíma obsah: vyhľadávanie, prílohy, dokumenty, e-maily, výsledky API a odpovede nástrojov. Ku každému vstupu uchovajte jeho pôvod a úroveň dôveryhodnosti. Text získaný z webu môže poslúžiť ako podklad pre odpoveď, no nemôže meniť pravidlá agenta ani povoľovať nový nástroj.

Pred vložením obsahu do kontextu obmedzte jeho rozsah a podľa úlohy vyberte iba potrebné polia. OWASP v odporúčaniach proti prompt injection uvádza oddelenie pokynov od dát, kontrolu vstupov a výstupov aj izolované spracovanie rizikového obsahu. Filter môže zachytiť známy vzor útoku, ale pokyn ukrytý v bežnom texte ním môže prejsť. Oprávnenia preto nesmú závisieť od výsledku filtra.

Pre malý tím je použiteľné rozdeliť čítanie a plánovanie. Komponent bez prístupu k nástrojom spracuje externý dokument a vráti štruktúrovaný výťah s označením pôvodu. Agent, ktorý navrhuje ďalší krok, môže tento výťah použiť ako údaj; ani výťah však automaticky nezískava dôveryhodnosť pokynu. Ak potrebuje pôvodný text, musí ho naďalej spracúvať ako obsah dokumentu.

Oprávnenia nastavte podľa úlohy

Každému nástroju určite povolené operácie a konkrétne zdroje. Agent, ktorý sumarizuje zmluvy, môže čítať vyhradené úložisko; na túto úlohu nepotrebuje prístup k celej pošte, odosielaniu správ ani príkazovému riadku. Rozdiel medzi čítaním a zápisom musí platiť v prihlasovacích údajoch a pravidlách služby, nie iba v systémovom pokyne.

Bezpečnostný prehľad OWASP pre AI agentov odporúča minimálne oprávnenia nástrojov, nezávislé overenie významných akcií, ľudské schvaľovanie, monitoring a opakovateľné bezpečnostné testy. Z toho vyplýva hranica architektúry: model môže navrhnúť volanie, ale samostatná autorizačná vrstva overí používateľa, nástroj, cieľový zdroj a rozsah operácie. Model nesmie sám rozhodnúť, že toto overenie splnil.

Volania nástrojov prijímajte len v pevnej schéme. Pri návrhu na odoslanie e-mailu kontrolujte adresáta, prílohu a oprávnenie používateľa; pri čítaní súboru povoľte iba určené priečinky. Neznámy parameter, nepovolený cieľ alebo chýbajúce pravidlo znamená zamietnutie. Kontrolu opakujte pri každom volaní, pretože škodlivý pokyn sa môže objaviť až v odpovedi ďalšieho nástroja.

Rizikové akcie zastavte pred vykonaním

Akcie rozdeľte podľa následku. Čítanie schváleného zdroja môže prebehnúť automaticky; odoslanie správy, zmena záznamu, spustenie kódu či vymazanie dát vyžadujú prísnejší režim. Pri vykonávaní kódu určite aj povolené prostredie a dostupné zdroje, aby schválený nástroj nezískal širší prístup, než úloha potrebuje.

Pri citlivej akcii ukážte schvaľujúcemu presný návrh: kto koná, ktorý nástroj sa použije, na aký cieľ a s akými parametrami. Súhlas viažte na tento návrh a obmedzte jeho platnosť. Ak agent po schválení zmení adresáta, prílohu alebo rozsah mazania, musí žiadať nový súhlas. Všeobecné „pokračovať“ neposkytuje vykonávacej službe jednoznačnú hranicu.

Vykonávacia služba má tesne pred akciou znovu overiť pravidlá aj platné schválenie. Pri výpadku autorizačnej služby citlivú akciu nevykoná. Tak sa pokyn vložený do stránky nemôže zmeniť na oprávnenie len preto, že ho agent presvedčivo zopakoval vo svojom návrhu.

Kontrolujte pamäť a prevádzku

Útok sa môže preniesť do ďalšej relácie, ak agent bez kontroly uloží cudzí text do dlhodobej pamäte. Pred zápisom overte obsah, pôvod a účel uloženia; pamäť oddeľte podľa používateľa a určite, kedy sa záznam odstráni. Aj odpoveď nástroja ostáva nedôveryhodným vstupom, hoci prichádza cez technické rozhranie, ktoré agent bežne používa.

Do prevádzkových záznamov ukladajte identifikátor relácie, pôvod podkladu, návrh volania, rozhodnutie autorizačnej vrstvy a výsledok vykonania. Citlivé údaje v záznamoch maskujte. Nastavte limity na počet volaní, opakovaní a náklady. Pri nezvyčajnom slede zamietnutých akcií musí mať tím možnosť prerušiť reláciu a dočasne vypnúť rizikový nástroj.

Otestujte celý reťazec, nielen odpoveď modelu

Skúška má začať pri cudzom vstupe a skončiť pri pokuse o akciu. Pripravte skúšobné dokumenty, e-maily a odpovede nástrojov s pokynmi na odoslanie údajov, zmenu príjemcu, zápis do pamäte alebo vyvolanie nepovoleného nástroja. Pri každom scenári zaznamenajte očakávané zamietnutie aj skutočné rozhodnutie vykonávacej služby. Samotná zdvorilá odpoveď modelu nestačí, ak nástroj medzitým akciu vykonal.

Pred nasadením prejdite kontrolný zoznam:

1. Každý externý vstup má známy pôvod a nižšiu dôveryhodnosť než pokyny používateľa.
2. Nástroje majú obmedzené oprávnenia a každé volanie prechádza autorizáciou mimo modelu.
3. Citlivá akcia čaká na platné schválenie viazané na konkrétny cieľ a parametre.
4. Pamäť, výstupy a prevádzkové záznamy majú vlastné kontroly; reláciu aj rizikový nástroj možno zastaviť.
5. Skúšobné útoky sa opakujú po zmene modelu, nástroja, vyhľadávania, pamäte alebo pravidiel.

Za výsledok testu považujte rozhodnutie na hranici oprávnení: či sa nepovolené volanie skutočne zamietlo a či záznam ukazuje dôvod. Tak možno odlíšiť situáciu, keď model škodlivý pokyn ignoroval, od situácie, keď sa ho pokúsil vykonať, ale zastavila ho vykonávacia vrstva.