AI agent s prístupom do systému: kto povoľuje jeho operácie?

Dokument môže obsahovať príkaz, ktorý nie je od používateľa

V ilustračnom scenári AI asistent číta dodávateľský dokument a pripravuje návrh objednávky. V dokumente je veta, ktorá ho vyzýva odoslať interné údaje na cudzí server. Ide o obsah z nedôveryhodného zdroja, hoci sa do kontextu dostal cez bežné vyhľadanie. OWASP opisuje túto triedu problémov ako prompt injection vrátane nepriamych pokynov vložených do externých podkladov.

Rozlíšenie používateľského zadania a citovaného obsahu pomáha modelu, ale samo nie je hranicou oprávnení. Návrh musí počítať aj s tým, že model požiada o nevhodnú operáciu. Server rozhodne, či ju smie vykonať, podľa overenej identity, pravidiel systému a aktuálneho stavu. Pokyn nájdený v PDF nemôže zmeniť členstvo používateľa ani rozšíriť právo na export.

Nástroj má predstavovať konkrétnu obchodnú operáciu

Namiesto všeobecného vykonania SQL alebo shell príkazu môže asistent dostať úzky nástroj na návrh objednávky. Jeho vstup má presne definované položky, povolené rozsahy a limity. Server odvodí organizáciu z overeného kontextu a overí prístup k dodávateľovi aj produktom. Identifikátor klienta z modelového vstupu nie je dôveryhodný zdroj rozsahu operácie.

OWASP pri excessive agency upozorňuje na priveľa funkcií, oprávnení a autonómie. Úzky nástroj zmenšuje rozsah možného zneužitia, no aj jeho hodnoty potrebujú sémantickú kontrolu. Platné JSON číslo môže byť neprimerané množstvo a platná URL môže odkazovať na nepovolené miesto. Schéma potvrdí štruktúru, nie obchodné oprávnenie ani prijateľnosť výsledku.

{
  "operation": "prepare_purchase_order",
  "supplier_id": "supplier-42",
  "items": [{ "product_id": "product-17", "quantity": 3 }],
  "request_id": "request-example-001"
}

Čítanie a záväzný zápis majú rozdielne podmienky

Vyhľadanie dostupných produktov, vytvorenie návrhu a odoslanie záväznej objednávky sú tri odlišné operácie. Asistent môže mať právo pripraviť návrh bez práva ho odoslať. Citlivý krok má mať samostatný serverový endpoint a podmienky. Prístupové poverenie drží dôveryhodná integračná vrstva; model nepotrebuje vidieť token ani všeobecné prihlasovacie údaje databázy.

Pri každom volaní overte aktuálne právo na konkrétny objekt. Raz vykonaná kontrola pri otvorení konverzácie nestačí, ak sa členstvo neskôr zmení. Výsledky nástroja vracajte iba v rozsahu potrebnom na úlohu. Ak asistent potrebuje cenu a dostupnosť produktu, sprístupnenie celého profilu zákazníka zbytočne zväčší možné dôsledky chyby.

Schválenie sa musí viazať na to, čo sa vykoná

Všeobecné tlačidlo Súhlasím nemusí používateľovi povedať, aký zápis server vykoná. V ilustračnom návrhu potvrdenie zobrazuje dodávateľa, položky, množstvá a výslednú sumu. Server uloží konkrétny návrh a jeho verziu. Následné schválenie sa vzťahuje práve na tento obsah, nie na nový text, ktorý model vytvorí po stlačení tlačidla.

Pred záväzným zápisom znova overte podmienky, ktoré sa mohli zmeniť, napríklad platnosť dodávateľa alebo limity používateľa. Ak sa mení schválený obsah, vyžiadajte nové potvrdenie podľa pravidiel procesu. Tento postup chráni aj pred zmenou medzi kontrolou a použitím. Súhlas s vyhľadaním podkladov nie je automaticky súhlas s odoslaním dokumentu externému príjemcovi.

Opakovanie a náklady potrebujú hranice

Jeden agent môže pri chybe opakovať volanie nástroja. Operácia s obchodným účinkom preto potrebuje identitu požiadavky a pravidlo pre duplicitu. Timeout nepreukazuje, že zápis neprebehol. Stav sa dohľadáva v autoritatívnej evidencii a opakovaný pokus sa spracuje podľa dohodnutej idempotencie. Nový náhodný identifikátor pri každom retry by túto ochranu obišiel.

Určte limit počtu volaní, trvania a nákladov na jednu úlohu. Pri prekročení má asistent ukončiť prácu s dostupným stavom a vysvetlením ďalšieho kroku. Audit môže zaznamenať žiadateľa, typ operácie, objekt a výsledok. OWASP odporúča chrániť logy a nevkladať do nich heslá či prístupové tokeny. Celý obsah citlivých dokumentov v auditnom zázname zvyčajne nie je potrebný.

Testujte pokus o prekročenie hraníc

Pripravte aj dokumenty obsahujúce úmyselne vložené pokyny a skúšajte odlišné formulácie. Výsledok posudzujte podľa serverovej operácie, nie iba podľa toho, či model odpovedal slušným odmietnutím. Ak sa nič neoprávnené nevykoná aj pri nesprávnom návrhu modelu, systém má overiteľnú hranicu. Tieto prípady sa majú opakovať po zmene modelu, nástroja alebo spôsobu získania podkladov.

• Pokyn v dokumente nezmení klienta ani povolený cieľ exportu.
• Používateľ bez práva objednávku odoslať nemôže obísť kontrolu cez asistenta.
• Zmenený návrh sa nevykoná pod starým schválením.
• Opakované volanie nevytvorí druhý záväzný zápis a dodrží limity úlohy.

Od témy ku konkrétnemu riešeniu.