Prompt injection nezastaví filtr: agent potřebuje omezené nástroje i schválení

AI agenta čtoucího web, e-mail a firemní dokumenty chraňte i pro případ, že model škodlivému pokynu uvěří. Oddělte načtený obsah od řídicích instrukcí, omezte nástroje a jejich oprávnění a před vykonáním kontrolujte argumenty každého volání v aplikačním kódu. Doporučení OWASP k těmto opatřením přidává schválení závažných akcí člověkem.

Detekční filtr může zachytit podezřelý vstup, ale sám nemá rozhodovat, zda agent smí odeslat e-mail, změnit záznam nebo předat data mimo firmu. To musí určit aplikace podle identity uživatele, původního úkolu a přesné podoby navržené akce. Stejná kontrola vykonání je nutná, ať se pokyn dostal k modelu přímo v uživatelském vstupu, nebo nepřímo v načteném obsahu.

Oddělte úkol od obsahu, který agent načítá

Webová stránka, příchozí e-mail ani nalezený firemní dokument nesmějí měnit zadání agenta. Přehled Microsoftu uvádí web, dokumenty, e-maily a databázové záznamy jako možné nosiče nepřímé prompt injection. Text může vypadat jako běžný podklad ke shrnutí, a přitom po agentovi žádat krok, který uživatel nezadal.

Načtenému obsahu přiřaďte původ a předávejte jej modelu jako data oddělená od instrukcí aplikace. Podle úkolu lze vybrat jen potřebné části, například tělo zprávy nebo pasáže dokumentu; tím se zmenší množství cizího textu, které agent zpracuje. Samotný štítek „nedůvěryhodné“ však bezpečnost nevynucuje: jestli model text přesto poslechne, musí nepovolenou akci zastavit další vrstva.

Analýza britského NCSC popisuje riziko vstupu ze znalostní databáze, odpovědi nástroje i jiného agentního systému. Interní úložiště proto automaticky neznamená důvěryhodný obsah. Rozhoduje také to, kdo mohl záznam vytvořit nebo změnit; tuto informaci zachovejte i při předání výsledku dalšímu nástroji či agentovi.

Dejte nástrojům jen pravomoc potřebnou pro úkol

Sepište úkony, které agent musí v konkrétním pracovním postupu vykonat, a pro každý vymezte samostatný nástroj nebo oprávnění. Agent pro shrnutí zpráv potřebuje číst vybrané e-maily; odesílání zpráv a úprava kontaktů jsou odlišné schopnosti. Podobně oddělte vyhledávání v dokumentech od jejich změny a čtení webu od možnosti volat libovolnou externí adresu.

U každého nástroje určete povolenou operaci, rozsah dat a identitu, pod níž poběží. Nástroj pro vytvoření konceptu odpovědi poskytuje jasnější hranici než obecné rozhraní, kterému model předá celý požadavek na e-mailové API. Kde stačí čtení, použijte přístup pouze pro čtení; pokud pozdější krok vyžaduje zápis, zpřístupněte ho až pro tento krok a v potřebném rozsahu.

Uchovávejte také původ hodnot, které model navrhl jako argumenty nástroje. Adresa nalezená na webové stránce může být údajem pro odpověď uživateli, ale sama o sobě se nesmí stát příjemcem firemního e-mailu. Toto pravidlo lze vynutit v aplikaci bez ohledu na to, jak důvěryhodně stránka působí nebo jak model svůj návrh vysvětlí.

Validujte navržené volání v aplikačním kódu

Výstup modelu je návrh akce, nikoli povolení k jejímu provedení. Ověření technického formátu nestačí: správně sestavený požadavek může stále mířit na nepovolený dokument nebo na cizího příjemce. Kontrolní vrstva proto musí porovnat operaci i její argumenty s oprávněním uživatele a původním úkolem.

1. Ověřte, zda uživatel smí zvolenou operaci provést nad uvedeným zdrojem.
2. Přijímejte pouze pole, která daný nástroj potřebuje, a kontrolujte jejich povolené hodnoty.
3. U příjemců, adres a identifikátorů zdrojů uplatněte pravidla aplikace; jejich hodnotu nesmí bez další kontroly určovat načtená stránka nebo dokument.
4. Před vykonáním posuďte celý účinek volání včetně cíle a rozsahu dat, která mají opustit systém.

Uvažujme úkol shrnout smlouvu. Agent smí dokument přečíst a vrátit souhrn, ale pokyn ukrytý ve smlouvě může vyvolat návrh odeslat její kopii na externí adresu. Kontrola musí odeslání odmítnout jako akci mimo zadání, i když jsou všechny parametry e-mailového nástroje vyplněné správně. Rozhodnutí a důvod odmítnutí zaznamenejte bez ukládání hesel, přístupových tokenů či nepotřebného citlivého obsahu.

Rizikové akce pozastavte do konkrétního schválení

Odeslání zprávy, zpřístupnění dokumentu, změna záznamu nebo smazání dat zasluhují silnější kontrolu než vytvoření návrhu. Aplikace má před vykonáním ukázat oprávněné osobě skutečnou operaci, její cíl a rozhodné argumenty. Schválení se musí vztahovat právě k této podobě akce; obecný souhlas s používáním e-mailového asistenta k tomu nestačí.

Změní-li se po schválení příjemce, příloha, rozsah dat nebo jiný podstatný argument, vyžádejte si nové potvrzení. Komponenta, která nástroj spouští, musí shodu schválené a vykonávané akce ověřit těsně před spuštěním. Méně rizikové úkony mohou probíhat bez přerušení, hranici pro lidský souhlas však stanovte v pravidlech aplikace předem podle skutečného účinku operace.

Otestujte místo, kde má každá vrstva útok zastavit

Testovací pokyn vložte do kanálu, kterým by mohl přijít ve skutečnosti: přímý pokus do uživatelského vstupu, nepřímý do zkušební stránky, e-mailu, dokumentu nebo odpovědi nástroje. Použijte zástupná data a testovací verze nástrojů, aby šlo sledovat zamýšlené volání bez odeslání zprávy či změny produkčních záznamů. Pro každý scénář předem určete, která akce by byla nepovolená a jak se její zablokování projeví.

Samotná závěrečná odpověď modelu nestačí jako výsledek testu. Sledujte navržené argumenty nástrojů, rozhodnutí autorizační vrstvy, případnou žádost o schválení a stav testovacích dat: agent může útok slovně odmítnout až po nepovoleném volání. Vedle útočných vstupů spouštějte běžné úkoly, aby bylo vidět, zda pravidla neblokují i oprávněnou práci. Po změně modelu, nástrojů nebo oprávnění zopakujte stejné scénáře; právě vykonaná akce ukáže, zda hranice dál platí.

Přečtěte si také:

• Cloudflare, nebo Fastly: nulový tarif prohrává, když potřebujete kontrolu
• Zoom, nebo Google Meet: nejlevnější je nástroj, který už platíte
• Trello, nebo ClickUp: jednodušší nástroj může ušetřit drahé zavádění