Definujte malé doménové nástroje s přesným vstupním a výstupním schématem. Argumenty ověřujte na serveru, oprávnění posuzujte podle identity a objektu, zápisové nebo nevratné akce zobrazte k potvrzení a provádějte je idempotentně. Logujte rozhodnutí a výsledek bez tajných údajů a testujte škodlivé kombinace volání.
Tool calling umožňuje modelu požádat aplikaci o vyhledání údajů nebo provedení akce prostřednictvím definované funkce. Model však nástroj přímo nevlastní a jeho argumenty nelze považovat za důvěryhodné. Aplikační vrstva musí každé volání validovat, autorizovat a rozhodnout, zda ho provede, zamítne, nebo požádá člověka o potvrzení.
Nejbezpečnější nástroj má úzký účel, malé schéma a předvídatelný výsledek. Obecné nástroje typu proveď požadavek nebo spusť SQL přenášejí příliš mnoho odpovědnosti na jazykový model. Čtení a zápis se oddělují, citlivé hodnoty se nezobrazují v kontextu a každá provedená akce zůstává spojená s uživatelem, případem a auditní stopou.
Navrhujte nástroje podle pracovního záměru
Nástroj má pojmenovávat konkrétní schopnost, například najít objednávku podle oprávněného identifikátoru nebo připravit návrh změny termínu. Model pak vybírá z jasných možností. Univerzální přístup k databázi, souborům nebo libovolné URL zvětšuje prostor pro zneužití a ztěžuje audit. To, co model pro daný cíl nepotřebuje, vůbec nezpřístupňujte.
Oddělte čtení, návrh a provedení. Nástroj může nejprve vrátit náhled důsledku a stabilní token návrhu; samostatný krok po potvrzení provede změnu. Pokud systém podporuje hromadnou operaci, omezte počet objektů a zobrazte je uživateli. Názvy a popisy nástrojů mají být jednoznačné i u podobných procesů.
Validujte schéma i obchodní význam argumentů
Vstupní schéma omezí typy, povinná pole, délku, formát a povolené hodnoty. Server odmítne neznámá pole a neočekávaný rozsah. Schéma však nestačí: datum může být formálně správné, ale mimo povolené období, a identifikátor může patřit jinému zákazníkovi. Doménová pravidla se vyhodnocují mimo model při každém volání.
Model nesmí dodávat identitu uživatele, tenanta ani roli jako autoritativní argument. Aplikace je odvodí z ověřené relace. Při práci s textem rozlišujte obsah určený k uložení od interních instrukcí. URL povolujte pouze podle seznamu a síťových pravidel, aby nástroj na základě vloženého pokynu nečetl interní služby nebo nedůvěryhodné adresy.
- přesné schéma bez neočekávaných polí
- serverem odvozená identita, role a tenant
- doménové limity nad rámec kontroly formátu
- bezpečný seznam povolených cílů a operací
Vynucujte oprávnění u každého objektu
Autorizace se kontroluje těsně před čtením nebo změnou, nikoli jen při otevření chatu. Uživatel může mít přístup k jednomu projektu a k druhému ne, přestože používá stejný nástroj. Výsledky filtrujte na datové vrstvě. Model nedostane ani název zakázaného objektu, protože citlivá může být už samotná jeho existence.
Servisní identita má nejmenší potřebná práva a podle možností jedná v delegovaném kontextu uživatele. Dlouhodobý široký klíč pro všechny nástroje ztěžuje odvolání i vyšetřování. Při změně role nebo ukončení relace se oprávnění projeví okamžitě i v cache. Zamítnutí vrátí bezpečnou informaci bez detailů, které by usnadnily zkoušení cizích identifikátorů.
Potvrzujte citlivé akce a řešte opakování
Před odesláním zprávy, smazáním, finanční operací nebo změnou důležitého stavu zobrazte člověku cíl, hodnoty a očekávaný účinek. Potvrzení se váže ke konkrétnímu neměnnému návrhu a po úpravě se vyžaduje znovu. Obecné „povol všechny další akce“ neodpovídá informovanému rozhodnutí. Některé operace mohou zůstat zcela mimo dosah modelu.
Nástroj používá idempotentní klíč a vrací jednoznačný stav, protože timeout může vést k opakování. Model nesmí při nejasném výsledku automaticky zkoušet jinou cestu se stejným účinkem. Nejprve se ověří stav původní operace. Kompenzační krok navrhněte pro případy, které lze bezpečně vrátit, a při částečném úspěchu eskalujte s přesným kontextem.
Testujte kombinace a auditujte skutečný účinek
Testy zahrnují neplatné argumenty, cizí objekt, odebrané oprávnění, duplicitní volání, timeout, škodlivý obsah z dokumentu a pokus řetězit nástroje mimo zamýšlený účel. Simulované prostředí umožní zkoušet bez produkčních následků. Hodnoťte nejen to, oč model požádal, ale i rozhodnutí serveru a konečný stav cílového systému.
Auditní stopa spojuje záměr uživatele, požadavek modelu, validovaný argument, výsledek autorizace, potvrzení a identifikátor provedené akce. Tajné údaje a celé citlivé obsahy redigujte. Monitoring upozorní na nárůst zamítnutí, neobvyklý nástroj, smyčku a neočekávaný objem. Jednotlivý nástroj musí jít rychle vypnout bez odstavení celého asistenta.
Časté dotazy
Může model přímo vykonat funkci?
Model pouze navrhne název nástroje a argumenty. Aplikační vrstva je musí validovat, autorizovat a podle rizika vyžádat potvrzení, teprve potom provede samotnou funkci.
Proč nestačí vstupní JSON schéma?
Schéma ověří formát, nikoli vlastnictví objektu, obchodní pravidlo ani oprávnění uživatele. Tyto kontroly musí server provést při každém volání.
Které nástroje AI potřebují potvrzení?
Především ty, které odesílají, mění, zveřejňují, platí nebo mažou a mají významný či těžko vratný dopad. Přesná hranice vychází z rizika organizace.
Zdroje a další čtení
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
