Ügynökbiztonság

A biztonságos AI-ügynökök létrehozása az Agent Framework és az alkalmazásfejlesztők közös felelőssége. Az Agent Framework biztosítja az építőelemeket – absztrakciókat, szolgáltatókat és vezénylést –, de a fejlesztők feladata a bemenetek ellenőrzése, az adatfolyamok védelme és az eszközök megfelelő konfigurálása a forgatókönyvükhöz.

Ez a cikk a biztonságos és biztonságos ügynökök ügynök-keretrendszerrel való létrehozásának ajánlott eljárásait ismerteti.

Tip

A gyors injektálással és adatkiszivárgással szembeni determinisztikus, címkealapú védelemért lásd: Agent Security with FIDES. A FIDES kiegészíti az oldalon található heurisztikus ajánlott eljárásokat olyan információáramlás-vezérlési köztes szoftverekkel, amelyek a bizalmas eszközök futtatása előtt házirendeket kényszerítenek ki.

A megbízhatósági határok ismertetése

Az ügynökök futtatásakor az adatok több összetevőn is áthaladnak: felhasználói bemenetek, csevegési előzmények szolgáltatói, környezetszolgáltatók, LLM-szolgáltatás és függvényeszközök. Minden határ, ahol az adatok belépnek vagy kilépnek az alkalmazásból, potenciális támadási felületet jelölnek.

Megfontolandó megbízhatósági határok:

  • AI-szolgáltatás – Csevegőüzeneteket fogad (amelyek tartalmazhatnak PII-t és rendszerutasításokat), és LLM által generált kimenetet ad vissza.
  • Csevegési előzmények tárolója – A szolgáltatók külső tárolón keresztül tölthetik be és őrizhetik meg a beszélgetési üzeneteket.
  • Környezeti szolgáltatások – A környezetszolgáltatók adatokat kérhetnek le vagy tárolhatnak külső szolgáltatásokból (memóriák, felhasználói profilok, RAG-eredmények).
  • Eszközhöz hozzáférő szolgáltatások – A függvényeszközök olyan fejlesztő által megadott kódot hajtanak végre, amely külső API-kat vagy adatbázisokat hívhat meg.

Minden külső szolgáltatás kommunikációját a fejlesztő által kiválasztott ügyféloldali SDK-k kezelik. Az Ügynök-keretrendszer nem kezeli ezen szolgáltatások hitelesítési, titkosítási vagy kapcsolati adatait.

Bevált gyakorlatok

Függvénybemenetek ellenőrzése

Az AI bármilyen, eszközként megadott függvényt meghívhat, és kiválaszthatja az argumentumokat. Az LLM által megadott argumentumokat ne megbízható bemenetként kezelje, hasonlóan a webes API felhasználói bemenetéhez.

  • Engedélyezési lista használata – A bemenetek ellenőrzése ismert jó értékek alapján, nem pedig az ismert-rossz minták szűrése. Ellenőrizze például, hogy egy fájl elérési útja egy engedélyezett könyvtáron belül található-e ahelyett, hogy elérési útvonal bejárási szekvenciákat keresne .. .
  • Típus- és tartománykorlátozások kényszerítése – Ellenőrizze, hogy az argumentumok a várt típushoz tartoznak-e, és elfogadható tartományokon belül vannak-e (numerikus korlátok, sztringhossz-korlátok, dátumtartományok).
  • Sztringhosszok korlátozása – A sztringargumentumok maximális hosszának kikényszerítése az erőforrás-kimerültség vagy az injektálási támadások megelőzése érdekében.
  • Elérési út bejárásának megakadályozása – Ha a függvények elfogadják a fájlelérési utakat, oldja fel őket abszolút elérési utakra, és ellenőrizze, hogy az engedélyezett könyvtárakba tartoznak-e.
  • Paraméteres lekérdezések használata – Ha SQL-lekérdezésekben, rendszerhéj parancsokban vagy más értelmezett környezetekben argumentumokat használnak, használjon paraméteres lekérdezéseket vagy escape karaktereket – soha ne sztringösszefűzést.

Nagy kockázatú eszközök jóváhagyásának megkövetelése

Alapértelmezés szerint az ügynökhöz biztosított összes eszköz felhasználói jóváhagyás nélkül lesz meghívva. A jóváhagyási mechanizmust használja a magas kockázatú műveletek emberi megerősítéshez kötéséhez.

Amikor eldönti, hogy mely eszközök igényelnek jóváhagyást, fontolja meg a következő szempontokat:

  • Mellékhatások – Az adatokat módosító, kommunikációt küldő, vásárlásokat vagy egyéb mellékhatásokat okozó eszközöket általában jóváhagyásra kell kötelezni.
  • Adatérzékenység – A bizalmas adatokhoz (PII, pénzügyi adatok, hitelesítő adatok) hozzáférő vagy visszaküldött eszközök jóváhagyást biztosítanak.
  • Visszafordíthatóság – A visszavonhatatlan műveletek (törlés, e-mailek küldése) nagyobb kockázatot jelentenek, mint az írásvédett lekérdezések.
  • Hatás hatóköre – A széles körű hatású eszközöknek (tömeges műveleteknek) nagyobb ellenőrzést kell igényelniük, mint a szűk hatókörű eszközöknek.

A rendszerüzenetek fejlesztői felügyelet alatt tartása

A csevegőüzenetek olyan szerepkört (system, , , user) assistanthordoznak, toolamely meghatározza, hogy az AI-szolgáltatás hogyan értelmezi őket. Ezeknek a szerepköröknek a megértése kritikus fontosságú:

Szerepkör Megbízhatósági szint
system Legmagasabb megbízhatóság – Közvetlenül formálja az LLM viselkedését. Soha nem tartalmazhat nem megbízható bemenetet.
user Nem megbízható – Tartalmazhat gyors injektálási kísérleteket vagy rosszindulatú tartalmakat.
assistant Nem megbízható – Az LLM hozza létre, amely egy külső rendszer.
tool Nem megbízható – Tartalmazhat külső rendszerekből vagy felhasználó által befolyásolt tartalmakból származó adatokat.

Ne helyezzen végfelhasználói bemenetet system szerepű üzenetekbe. Az Agent Framework alapértelmezésként a szöveget a user szerepkörhöz rendeli, de legyen óvatos, amikor programozással hozza létre az üzeneteket.

Vet bővítményszolgáltatók

A környezetszolgáltatók és az előzményszolgáltatók bármilyen szerepkörrel rendelkező üzeneteket injektálhatnak, beleértve a system. Csak megbízható szolgáltatókat csatolhat.

Vegye figyelembe a közvetett parancssori injektálást: ha a mögöttes adattár biztonsága sérül, a támadó tartalom befolyásolhatja az LLM viselkedését. A RAG-on keresztül lekért dokumentumok tartalmazhatnak például olyan rejtett utasításokat, amelyek miatt az LLM eltér a kívánt viselkedéstől, vagy eszközhívásokkal kiszűri az adatokat.

LLM-kimenet ellenőrzése és megtisztítása

Az LLM-válaszokat nem megbízható kimenetként kell kezelni. Az AI-szolgáltatás egy külső végpont, amelyet az Agent Framework nem szabályoz. Vegye figyelembe a következőt:

  • Hallucináció – Az LLM-ek hihetően hangzó, de tényszerűen helytelen információkat eredményezhetnek. Ne kezelje az LLM-kimenetet mérvadóként ellenőrzés nélkül.
  • Indirekt parancssori injektálás – Az eszközök, a környezetszolgáltatók vagy a csevegési előzmények szolgáltatói által lekért adatok az LLM befolyásolására tervezett kártékony tartalmakat tartalmazhatnak.
  • Rosszatindulatú tartalom – Az LLM kimenete olyan tartalmakat tartalmazhat, amelyek károsak, ha tisztítás nélkül jelenítenek meg vagy hajtanak végre (HTML/JavaScript XSS-hez, SQL injektáláshoz, parancsok a rendszerhéjhoz).

Mindig ellenőrizze és fertőtlenítse az LLM-kimenetet , mielőtt HTML-ben renderelné, kódként futtatná, adatbázis-lekérdezésekben használná, vagy bármilyen biztonsági szempontból érzékeny környezetbe továbbítanák.

Bizalmas adatok védelme a naplókban

Az Agent Framework az OpenTelemetry használatával támogatja a naplózást és a telemetriát. A bizalmas adatokat csak akkor naplózza a rendszer, ha kifejezetten engedélyezve van:

  • Naplózás – Naplószinten Tracea rendszer a teljes ChatMessages gyűjteményt naplózza. Ez magában foglalhatja a PII-t is. Trace szintet soha nem szabad engedélyezni az éles környezetben.
  • Telemetriai adatok – Ha EnableSensitiveData be van állítva, a telemetriai adatok tartalmazzák a csevegőüzenetek teljes szövegét, beleértve a függvényhívásokat és az eredményeket. Ezt ne engedélyezze éles környezetben.

Munkamenet adatainak védelme

A munkamenetek (AgentSession) a beszélgetési környezetet jelölik, és szerializálhatók az adatmegőrzés érdekében. Szerializált munkamenetek kezelése bizalmas adatokként:

  • A munkamenetek hivatkozhatnak beszélgetési tartalmakra vagy munkamenet-azonosítókra.
  • A munkamenetek nem megbízható forrásból való visszaállítása egyenértékű a nem megbízható bemenetek elfogadásával. A sérült tárterület háttérrendszere megváltoztathatja a szerepköröket a megbízhatóság eszkalálása érdekében.
  • A munkameneteket biztonságos tárolóban tárolhatja a megfelelő hozzáférés-vezérléssel és -előkészítéssel.

Erőforráskorlátok megvalósítása

Az Ügynök-keretrendszer nem ír elő korlátozásokat a bemeneti/kimeneti hosszúságra vagy a kérések sebességére, mert nem tudja, mi az ésszerű az Ön forgatókönyvéhez. Ön felelős a következőkért:

  • Bemeneti hosszkorlátok – A bemeneti hossz korlátozása a környezet túlcsordulásának vagy a DoS-támadások megelőzéséhez.
  • Kimeneti hosszkorlátok – A szolgáltatás által biztosított korlátok használata (például MaxOutputTokens a csevegési beállításokban).
  • Sebességkorlátozás – Sebességkorlátozó létesítmények használata a költségek túllépésének és az egyidejű kérésekkel való visszaélésnek a megakadályozásához.

Következő lépések