Határozzon meg kis, tartományspecifikus eszközöket pontos bemeneti és kimeneti sémával. Az argumentumokat a szerveren ellenőrizze, a jogosultságot az identitás és az objektum alapján bírálja el, az írási vagy visszafordíthatatlan műveleteket jelenítse meg megerősítésre, és hajtsa végre idempotens módon. Naplózza a döntést és az eredményt titkos adatok nélkül, és tesztelje a káros hívási kombinációkat.
A tool calling lehetővé teszi, hogy a modell egy definiált függvényen keresztül adatok lekérését vagy egy művelet végrehajtását kérje az alkalmazástól. A modell azonban nem rendelkezik közvetlenül az eszköz felett, és az általa átadott argumentumok nem tekinthetők megbízhatónak. Az alkalmazásrétegnek minden hívást validálnia és engedélyeznie kell, és döntenie kell arról, hogy végrehajtja, elutasítja, vagy emberi megerősítést kér.
A legbiztonságosabb eszköz szűk céllal, kis sémával és kiszámítható eredménnyel rendelkezik. Az olyan általános eszközök, mint a „hajtsd végre a kérést” vagy a „futtasd az SQL-t”, túl sok felelősséget hárítanak a nyelvi modellre. Az olvasás és az írás külön van választva, az érzékeny értékek nem jelennek meg a kontextusban, és minden végrehajtott művelet összekapcsolva marad a felhasználóval, az üggyel és a naplózási nyomvonallal.
Az eszközöket a munkacél szerint tervezze
Az eszköznek egy konkrét képességet kell megneveznie, például rendelés keresését jogosult azonosító alapján vagy időpont-módosítási javaslat előkészítését. A modell így egyértelmű lehetőségek közül választ. Az adatbázishoz, fájlokhoz vagy tetszőleges URL-hez való univerzális hozzáférés növeli a visszaélés lehetőségét, és megnehezíti az auditot. Amire a modellnek az adott célhoz nincs szüksége, azt egyáltalán ne tegye elérhetővé.
Válassza szét az olvasást, a javaslatot és a végrehajtást. Az eszköz először visszaadhatja a következmények előnézetét és egy stabil javaslati tokent; a változtatást egy külön lépés hajtja végre a megerősítés után. Ha a rendszer támogatja a tömeges műveletet, korlátozza az objektumok számát, és jelenítse meg őket a felhasználónak. Az eszközök neve és leírása hasonló folyamatok esetén is legyen egyértelmű.
Validálja a sémát és az argumentumok üzleti jelentését is
A bemeneti séma korlátozza a típusokat, a kötelező mezőket, a hosszt, a formátumot és a megengedett értékeket. A szerver elutasítja az ismeretlen mezőket és a váratlan tartományokat. A séma azonban nem elég: egy dátum formailag helyes lehet, mégis kívül eshet a megengedett időszakon, egy azonosító pedig más ügyfélhez tartozhat. A doménszabályokat a modellen kívül, minden hívásnál érvényesíteni kell.
A modell nem adhatja meg a felhasználó identitását, a tenantot vagy a szerepkört hiteles argumentumként. Ezeket az alkalmazás az ellenőrzött munkamenetből vezeti le. Szöveggel végzett munkánál különítse el a tárolandó tartalmat a belső utasításoktól. URL-eket csak engedélyezési lista és hálózati szabályok alapján engedélyezzen, hogy az eszköz egy beágyazott utasítás nyomán ne olvasson belső szolgáltatásokat vagy nem megbízható címeket.
- pontos séma váratlan mezők nélkül
- a szerver által levezetett identitás, szerepkör és tenant
- a formátumellenőrzésen túlmutató szakterületi korlátok
- az engedélyezett célok és műveletek biztonságos listája
Érvényesítse a jogosultság-ellenőrzést minden objektumnál
Az engedélyezést közvetlenül az olvasás vagy módosítás előtt kell ellenőrizni, nem csak a chat megnyitásakor. A felhasználónak hozzáférése lehet az egyik projekthez, a másikhoz pedig nem, holott ugyanazt az eszközt használja. Az eredményt az adatrétegben szűrje. A modell még a tiltott objektum nevét sem kapja meg, mert már maga a létezése is érzékeny információ lehet.
A szolgáltatásidentitás a legkisebb szükséges jogosultságokkal rendelkezik, és lehetőség szerint a felhasználó delegált kontextusában jár el. Egy hosszú távú, széles körű kulcs az összes eszközhöz megnehezíti a visszavonást és a vizsgálatot. Szerepkörváltáskor vagy a munkamenet befejezésekor a jogosultság változása azonnal érvényesül a gyorsítótárban is. Az elutasítás biztonságos információt ad vissza, olyan részletek nélkül, amelyek megkönnyítenék idegen azonosítók kipróbálását.
Kérjen megerősítést a kényes műveleteknél, és kezelje az ismétlést
Üzenet küldése, törlés, pénzügyi művelet vagy egy fontos állapot módosítása előtt mutassa meg az embernek a célt, az értékeket és a várható hatást. A megerősítés egy konkrét, változatlan javaslathoz kötődik, és módosítás után megújul. Egy általános „engedélyezd az összes további műveletet” nem felel meg a tájékozott döntésnek. Egyes műveletek teljesen a modell hatókörén kívül maradhatnak.
Az eszköz idempotens kulcsot használ, és egyértelmű állapotot ad vissza, mert egy timeout ismétléshez vezethet. A modell bizonytalan eredmény esetén nem próbálhat meg automatikusan egy másik, azonos hatású utat. Először az eredeti művelet állapotát kell ellenőrizni. Kompenzációs lépést azokra az esetekre tervezzen, amelyek biztonságosan visszafordíthatók, részleges siker esetén pedig pontos kontextussal eszkaláljon.
Tesztelje a kombinációkat, és auditálja a tényleges hatást
A tesztek kiterjednek az érvénytelen argumentumokra, idegen objektumra, visszavont jogosultságra, duplikált hívásra, időtúllépésre, dokumentumból származó kártékony tartalomra és az eszközök szándékon kívüli összefűzésének kísérletére. A szimulált környezet lehetővé teszi a próbát éles következmények nélkül. Ne csak azt értékelje, mit kért a modell, hanem a szerveroldali döntést és a célrendszer végső állapotát is.
Az auditnyomvonal összeköti a felhasználói szándékot, a modell kérését, a validált argumentumot, az engedélyezési eredményt, a megerősítést és a végrehajtott művelet azonosítóját. A titkokat és a teljes érzékeny tartalmakat redigálja ki. A monitorozás jelzi az elutasítások számának növekedését, a szokatlan eszközhasználatot, a ciklusokat és a váratlan mennyiséget. Az egyes eszközöket gyorsan ki kell tudni kapcsolni a teljes asszisztens leállítása nélkül.
Gyakori kérdések
Végrehajthat-e a modell közvetlenül egy függvényt?
A modell csak javasolja az eszköz nevét és az argumentumokat. Az alkalmazásrétegnek validálnia és engedélyeznie kell őket, a kockázattól függően megerősítést kell kérnie, és csak ezután hajtja végre a tényleges függvényt.
Miért nem elég a bemeneti JSON-séma?
A séma a formátumot ellenőrzi, nem az objektum tulajdonjogát, az üzleti szabályt vagy a felhasználó jogosultságát. Ezeket az ellenőrzéseket a szervernek minden hívásnál el kell végeznie.
Mely AI-eszközök igényelnek megerősítést?
Főként azok, amelyek küldenek, módosítanak, közzétesznek, fizetnek vagy törölnek, és jelentős vagy nehezen visszafordítható hatásuk van. A pontos határ a szervezet kockázatán alapul.
Források és további olvasnivaló
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.
