Korlátozott AI-asszisztens tervezése eszközökkel, jogosultságokkal és kontextushatárokkal

Egy üzleti AI-asszisztens valódi határát nem a rendszerprompt tiltó mondatai, hanem a modell köré épített, végrehajtható szolgáltatási szerződés adja. Hiába szerepel az utasításban, hogy az asszisztens nem küldhet üzenetet, ha közben rendelkezik küldési eszközzel és arra jogosult hitelesítő adattal. A biztonságos tervezés ezért képességenként rögzíti, milyen információ használható, melyik identitás jár el, milyen művelet hajtható végre, hol kell megállni, és ki viseli a döntési felelősséget.

Mit szabad elvégeznie az asszisztensnek?

A csapat először egyetlen mondatban rögzítse a szolgáltatási alapmegbízást: „A jogosult felhasználók számára az asszisztens az engedélyezett információk felhasználásával elvégezheti a meghatározott feladatcsaládot és létrehozhatja a megengedett eredményt, de nem végezheti el a felsorolt tiltott vagy következményekkel járó döntéseket.” Ebben már a felhasználói körnek, a működési helyzetnek, az információhatárnak, az emberi felügyeletnek és a felelős szolgáltatásgazdának is látszania kell.

A következő lépés a tág igék felbontása. A „segít az ügykezelésben” nem ellenőrizhető képesség, míg az „ügy megkeresése”, „összefoglaló készítése”, „válasz javaslata”, „piszkozat mentése” és „jóváhagyott válasz elküldése” már külön-külön tervezhető. Az OWASP minimális eszközfunkciókra vonatkozó ajánlása támogatja ezt a szűkítést, a NIST pedig a rendeltetés, a támogatott feladatok, a tudáskorlátok és az emberi felügyelet dokumentálását hangsúlyozza.

• Nevezze meg, ki használhatja a képességet, és milyen üzleti helyzetben.
• Rögzítse a sikeres kimenetet, valamint azt, hogy az csak tájékoztatás, javaslat, piszkozat vagy állapotváltozás.
• Sorolja fel a kifejezett nem célokat, a tiltott eredményeket és a felelős kockázati tulajdonost.
• A képességszintű módszert gyakorlati szerkesztői szintézisként kezelje, ne NIST- vagy OWASP-követelményként.

Milyen információt használhat az egyes képességekhez?

A kontextushatár információs keret: azt mondja meg, milyen adatok jogosultak belépni egy képesség működésébe, és mely bizalmi határokon belül használhatók. Nem azonos a modell technikai tokenkeretével. Képességenként rögzíteni kell az engedélyezett rendszereket, rekordtípusokat, adatbesorolásokat, objektumszűrőket, időszakokat, frissességi elvárásokat, felhasználói hozzáféréseket és tiltott adatokat. A nagyobb kontextusablak sem ad új jogosultságot, és nem tesz igazabbá egy alá nem támasztott választ.

A lekért dokumentumot, mellékletet, külső üzenetet és API-választ adatként, nem szolgáltatási utasításként kell kezelni. Az OWASP ezeket nem megbízható tartalomként kezeli, és elkülönítésüket ajánlja. A munkamenet előzményeit és a tartós memóriát külön kell megtervezni: mi menthető, mely felhasználóhoz és munkamenethez tartozik, milyen ellenőrzés után maradhat meg, mikor jár le, hogyan törölhető, és milyen érzékeny adat nem kerülhet bele soha.

• Ellenőrizze a forrásrendszert, a rekord jogosultságát, az objektumszűrőt és az adat frissességét.
• Tartsa elkülönítve a rendszerutasítást és a lekért, potenciálisan ellenséges tartalmat.
• Határozza meg külön a munkameneti előzmény és a tartós memória jogosultságát, méretét, lejáratát és törlését.
• Hiányzó, hozzáférhetetlen vagy elavult bizonyítéknál utasítsa vissza vagy egyértelműen minősítse a választ.

Hogyan érvényesítse a határt az identitás, az eszköz és a jogosultság?

A határ érvényesítéséhez három döntést kell szétválasztani: kit vagy mit hitelesített a rendszer, mely művelet engedélyezett mely védett erőforráson, és jóváhagyták-e az adott, konkrétan előkészített műveletet. Az MCP engedélyezési specifikációja jól szemlélteti az elkülönített kliens-, erőforrás- és engedélyezési szerepeket, valamint a legkisebb hatókör és az erőforráshoz kötött token elvét. Ezek azonban védett MCP-integrációkra vonatkoznak, nem minden eszközarchitektúrára.

A végrehajtási útvonalon előre el kell dönteni, hogy az eszköz a felhasználó delegált jogosultságával vagy szigorúan ellenőrzött munkaterhelési identitással jár el. Nem örökölheti észrevétlenül egy privilegizált üzemeltető fiókját. A modell csak keskeny, paraméterezett műveleteket kapjon, például egy jogosult ügy olvasását vagy egy piszkozat létrehozását; a műveletet, erőforrást, objektumot, mezőt, célállomást, hitelesítő adat élettartamát és tokenközönséget az eszközátjáró és a háttérrendszer ellenőrizze.

• A promptban megfogalmazott tiltás és a természetes nyelvű védőszabály nem engedélyezési kontroll.
• A sebesség-, ismétlési, lánchossz-, köteg-, költség-, idő- és megszakítási korlátokat a szolgáltatás kockázatához kell igazítani.
• Az idempotencia, a visszaállítás és a megszakító mechanizmus csökkentheti a hibás ismétlés vagy elszabadult műveletsor következményeit.

A beszélgetés folytonosnak tűnhet, de a mögötte álló jogosultságot kis, egymástól függetlenül kikényszerített képességekre kell bontani.

Mekkora cselekvési szabadságot kaphat egy képesség?

Minden képességhez kifejezett műveleti plafon kell, és a külső állapot megváltoztatásához egyre erősebb, független kontrollokat kell rendelni. Hasznos szerkesztői létra az információ megválaszolása vagy összegzése; következő lépés javaslata; szerkeszthető piszkozat készítése; korlátozott, visszaállítható írás; következményekkel járó külső művelet; végül a szolgáltatás számára tiltott döntés. Ez a létra nem szabványos kockázati besorolás, hanem a források kontrollelveiből levezetett tervezési segédlet.

A piszkozat létrehozását külön kell választani a küldéstől, a visszafordítható rekordmódosítást a törléstől, a javaslatot pedig a felelős döntéstől. Következményekkel járó művelet előtt a jóváhagyó ellenőrizhető előnézetet kapjon, a jóváhagyást pedig a szereplőhöz, eszközhöz, célhoz, normalizált paraméterekhez, időponthoz és lejárathoz kell kötni. Ha a címzett, a tartalom vagy más lényeges paraméter megváltozik, a korábbi jóváhagyás nem használható fel.

• A jóváhagyás nem ad hiányzó jogosultságot, nem szélesíti az állandó hozzáférést, és nem old fel tiltott döntést.
• A fizetés, hozzáférés-adás, törlés, éles rendszer módosítása és jelentős külső kötelezettségvállalás maradjon megfelelő emberi és determinisztikus szabályozás alatt.
• Jogi, szabályozási vagy más magas kockázatú szakmai döntést képesített szakemberhez és külön irányított folyamathoz kell terelni.

Mi történjen, amikor az asszisztens eléri a határát?

A visszautasítást, a biztonságos részsegítséget, az emberi átadást és a biztonsági eszkalációt önálló szolgáltatási kimenetként kell megtervezni, valódi leállási feltétellel. Az ok lehet hatókörön kívüli feladat, nem jogosult információ, elégtelen engedély, hiányzó jóváhagyás, hiányzó vagy elavult bizonyíték, szakértői döntési igény, elérhetetlen függőség, működési korlát vagy biztonsági jelzés. A válasznak közérthetően kell megneveznie a határt anélkül, hogy érzékeny szabályrészleteket fedne fel.

Az asszisztens soha ne állítsa, hogy forrásellenőrzés, eszközhívás, jóváhagyás vagy írás sikerült, ha valójában nem történt meg. Felajánlhatja a biztonságos részt, például piszkozatot, ellenőrzőlistát vagy hiányzó adatra vonatkozó kérdést. Az átadási csomag tartalmazza az eredeti célt, a szükséges nem érzékeny környezetet, a megkísérelt képességet, az okot, a rendelkezésre álló vagy hiányzó bizonyítékot, a javasolt következő lépést és a nyomkövetési azonosítót.

• A rutin ügyintézői átadás, az üzleti jóváhagyás és a biztonsági incidens három külön útvonal, eltérő tulajdonossal.
• A függőben lévő végrehajtás maradjon leállítva, amíg a megfelelő felelős nem intézkedik.
• Módosult műveletet csak friss jogosultság- és jóváhagyás-ellenőrzés után szabad folytatni.
• A jogosultságkiterjesztés, adatkivonás, memóriamérgezés és rekurzív eszközhasználat jele biztonsági útvonalat indokolhat.

Hogyan lesz a határokból működtethető képességterv?

A csapat minden felhasználó által látható művelethez töltsön ki egy külön képességtervezési sort, majd minden mezőt kössön kikényszeríthető kontrollhoz, bizonyítékhoz, teszthez, üzemi mérőszámhoz és felelős tulajdonoshoz. A sorban szerepeljen a jogosult szereplő és hitelesítése, az információs keret, a munkamenet és memória, a keskeny eszközművelet, az eljáró identitás, az erőforrás-hatókör, a műveleti plafon, a jóváhagyás, a leállási feltétel, a visszautasítás, a naplózási bizonyíték és az eszkaláció.

A dokumentum önmagában nem kontroll. Minden sorhoz meg kell nevezni, mely rendszer ellenőrzi a jogosultságot, mely eseményből rekonstruálható a döntés, mely pozitív és elutasítási próbák bizonyítják a működést, milyen üzemi jel mutat eltérést, és ki jogosult a képesség szüneteltetésére vagy visszavonására. A NIST irányítási eredményei az egyértelmű szerepeket, az emberi és AI-felelősségek elkülönítését, a monitoringot és az időszakos felülvizsgálatot hangsúlyozzák.

Milyen bizonyíték kell a kiadáshoz és a folyamatos működéshez?

A kiadáshoz bizonyítani kell, hogy a megengedett szolgáltatás és az elvárt elutasítás egyaránt működik a telepítéshez hasonló körülmények között. A pozitív feladatok mellett vizsgálni kell a más fiókjához tartozó adatot, a nem engedélyezett eszközt, az elavult bizonyítékot, a mérgezett lekért tartalmat, a tiltott adatot, a jóváhagyás megkerülését, a módosított paramétert, az ismételt próbálkozást, a függőségi hibát, az adatkivonási kísérletet és az elszabadult műveletsort.

A naplónak rekonstruálhatóvá kell tennie, ki mit kért, mely képesség és szabályzat volt érvényben, milyen forrás- és eszközosztályt használt a rendszer, mi lett az engedélyezési és jóváhagyási döntés, milyen művelet történt, és mely verziók futottak. Ez nem jelentheti titkok vagy korlátlan érzékeny kontextus megőrzését. A tartalmat, a hozzáférést és a megőrzést a szervezet adatvédelmi, biztonsági és iratkezelési követelményeihez kell igazítani.

• Figyelje képességenként a váratlan eszközhasználatot, az ismételt tagadásokat, a jogosultsági hibákat és a megváltozott jóváhagyásokat.
• Kövesse a rendellenes műveletsorokat, az eltérést, a késleltetést, az erőforrás-használatot és a függőségi hibákat.
• Jelöljön ki külön felelőst a szolgáltatási viselkedéshez, a hozzáférési grantokhoz, az üzleti átadásokhoz és a biztonsági incidensekhez.
• Nyissa újra az érintett teszteket modell-, prompt-, adat-, lekérési, memória-, eszköz-, jogosultság-, szabályzat-, szolgáltató- vagy működésikörnyezet-változás után.

Érdemes a legkisebb, önmagában hasznos képességgel indulni, és csak akkor kiadni, amikor a sikeres és a megtagadott esetek egyaránt megfigyelhetők. A jogosultságot felülvizsgált változtatásokkal, ne pusztán promptmódosítással bővítsék. Érzékeny információ, tartós memória, privilegizált hozzáférés, külső kötelezettség, romboló módosítás vagy incidenskezelés esetén vonják be a biztonsági, identitáskezelési, adatvédelmi, iratkezelési, kockázati és szolgáltatási felelősöket; magas kockázatú szakmai ítéletet pedig külön irányított szakértői folyamat kezeljen.