Schválení AI agenta nestačí: povolujte konkrétní akci, ne celý běh

Lidské schválení vložte před volání nástroje, který může provést platbu, změnit záznam nebo smazat data. Agent připraví konkrétní volání, aplikace ukáže jeho argumenty oprávněnému člověku a po souhlasu spustí právě uložený návrh.

Souhlas s celým během je příliš široký. Agent může po rozhodnutí navrhnout další krok nebo změnit příjemce, částku či cílový záznam. Každá taková změna proto vytváří nový návrh: předchozí souhlas se na něj nevztahuje.

Hranici nastavte u nástroje, který způsobí účinek

Rozhodujte podle toho, co volání skutečně provede. Načtení běžného katalogového záznamu obvykle člověka nepotřebuje. Odeslání peněz, zveřejnění obsahu, změna oprávnění a mazání mají kontrolu před vykonáním. Souhlas může být nutný i u čtení, pokud nástroj zpřístupní citlivá data nebo je odešle mimo povolený okruh.

Návod OpenAI u citlivých kyberbezpečnostních úloh doporučuje před spuštěním nástroje posoudit cíl, zamýšlenou akci, argumenty, identitu volajícího a časový rozsah oprávnění. Pro platby a změny dat z toho plyne užitečný návrhový princip: kontrolu vynucujte v aplikační vrstvě u nástroje, nikoli pouze pokynem v zadání agenta. Musí platit pro každou cestu ke stejnému účinku, včetně volání přes vnořeného agenta.

Samotná kategorie „zápis“ je pro rozhodnutí hrubá. Uložení pracovního návrhu a odeslání objednávky jsou oba zápisy, ale následky se liší. Pravidlo proto určete pro kombinaci nástroje, cíle a parametrů; u každého rizikového volání je vyhodnoťte znovu.

Schvalovateli předložte hodnoty, které nástroj dostane

Obrazovka nesmí stát jen na agentově shrnutí typu „proveď platbu“. Ukažte údaje ze stejného uloženého návrhu, který později dostane nástroj. Člověk tak rozhoduje o skutečném příjemci a částce, ne o volném popisu záměru.

• U platby zobrazte příjemce nebo platební identifikátor, částku, měnu a účel.
• U změny či smazání zobrazte přesný objekt, rozsah zásahu a možnost obnovy, pokud existuje.
• U každé akce uveďte název nástroje, identitu žadatele, účet či organizaci, jejímž jménem agent jedná, a dobu platnosti rozhodnutí.

Schvalovatel potřebuje oddělené možnosti schválit a zamítnout. Chce-li opravit parametr, vraťte návrh k přepracování a upravené hodnoty předložte znovu. Souhlas s původní částkou nebo původním cílem nesmí platit pro verzi, kterou člověk neviděl.

V podmíněném příkladu platby kartou nestačí tlačítko „Schválit platbu“, pokud chybí identifikace platby a její částka. Před potvrzením musí být také jasné, zda agent navrhuje jednorázové stržení, nebo založení dalšího platebního závazku. Rozdíl patří do názvu akce a jejích argumentů.

Návrh udržujte jako stavový záznam

Každé rizikové volání veďte samostatně ve sledu návrh → čeká na kontrolu → schváleno nebo zamítnuto → provádí se → dokončeno. K záznamu patří identifikátor relace a volání, název nástroje, přesné argumenty, identita žadatele, čas vypršení a rozhodnutí schvalovatele. Schválení je přechod k jednomu uloženému volání, nikoli trvalé oprávnění pro agenta.

Microsoft Agent Framework standardně přijme místní odpověď na schválení jen pro odpovídající čekající volání ve stejné relaci; jeho rozšířený režim zároveň umožňuje trvalá pravidla „always approve“. Pro požadavek na jednorázový souhlas takové pravidlo nepoužívejte. Odpověď na konkrétní požadavek pošlete zpět se stejnou relací a další čekající volání posuzujte samostatně.

Ve vlastní aplikaci svažte rozhodnutí také s neměnnou podobou návrhu. Otisk počítejte z jednoznačně zapsaného názvu nástroje, cíle a všech argumentů, které mění účinek. Před vykonáním porovnejte uložené hodnoty s hodnotami předloženými člověku a ověřte jeho oprávnění. Odkazuje-li návrh na záznam, který se mezitím změnil, znovu ověřte podmínky provedení; podstatně změněný účinek vyžaduje nové schválení.

Pseudokód spotřebuje souhlas právě pro uložené volání

Následující postup je aplikační návrhový vzor, nikoli kód konkrétního SDK. Přechod do stavu PROVÁDÍ_SE musí být atomický, aby dvě souběžná pokračování nemohla použít totéž rozhodnutí.

1. Je-li volání rizikové, ulož nástroj, cíl, přesné argumenty, jejich otisk, relaci, identitu žadatele a čas vypršení. Nastav stav ČEKÁ a vrať žádost o rozhodnutí.
2. Při zamítnutí nastav stav ZAMÍTNUTO. Po vypršení platnosti nastav stav VYPRŠELO. V obou případech nástroj nespouštěj.
3. Při schválení ověř identitu a oprávnění schvalovatele, shodu relace a volání, platnost návrhu a shodu otisku. Při neshodě zastav; změněná akce potřebuje nový návrh.
4. V databázové transakci změň stav ČEKÁ na PROVÁDÍ_SE jen tehdy, je-li záznam stále čekající. Neúspěšný přechod znamená, že rozhodnutí už nelze spotřebovat.
5. Spusť uložené volání s původními argumenty, zapiš výsledek a nastav konečný stav. Pro každé další rizikové volání vytvoř další žádost o souhlas.

Po schválení nesestavujte argumenty z nové odpovědi modelu. Agent může pokračovat v plánování, ale nástroj obdrží pouze hodnoty z odsouhlaseného záznamu. Pokud schvalovací služba není dostupná, stav zůstane čekající nebo vyprší a účinek se nespustí.

Opakování požadavku řešte odděleně od schválení

Jednorázový souhlas zabrání použití starého rozhodnutí pro jiné volání. Sám však neurčí, zda se již schválená operace vykonala, když se ztratí odpověď poskytovatele. U platby by slepé zopakování s novým požadavkem mohlo vyvolat další stržení.

Dokumentace Stripe popisuje opakování podporovaného požadavku se stejným idempotentním klíčem a porovnání jeho parametrů; upozorňuje také, že klíč může být odstraněn nejdříve po 24 hodinách. Pokud platební poskytovatel takový mechanismus nabízí, spojte stabilní klíč s identifikátorem schválené operace a při opakování zachovejte stejné parametry. Po uplynutí retenční doby nejprve zjistěte stav původní platby.

Nejasný výsledek provedení nepřevádějte automaticky zpět do stavu ČEKÁ. Uchovejte rozhodnutí, přesné argumenty, identifikátor pokusu a odpověď poskytovatele, pokud dorazila. Teprve zjištěný stav operace umožní rozhodnout, zda lze bezpečně dokončit původní pokus, nebo zda je třeba vytvořit nový návrh.

Přečtěte si také:

• Prompt injection nezastaví filtr: agent potřebuje omezené nástroje i schválení
• Cena AI agenta není počet tokenů: smyčky znovu účtují celý kontext
• AI překročila přístup k datům v 87 % firem, samotná pravidla nestačí