
Prompt injection ellen nincs varázsszűrő: így rétegezd az ágens védelmét

A dokumentumokat, weboldalakat és eszközválaszokat feldolgozó MI-ágens védelmét azzal kezdd, hogy a külső tartalmat adatként kezeled, az eszközhívásokat külön jogosultsági szabályhoz kötöd, a nagy hatású műveleteket pedig jóváhagyásig megállítod. Az OWASP útmutatója szerint a prompt injection alapja, hogy a természetes nyelvű adat és utasítás sok LLM-rendszerben éles határ nélkül kerül feldolgozásra. Egy bemeneti tiltólista ismert mintákat szűrhet, de a találat nélküli szöveg ettől még nem kap utasítási jogot.
A megvalósítás sorrendje: előbb térképezd fel, ki írhatja az ágens által olvasott tartalmat; utána válaszd el ezt a feladattól; végül korlátozd az elérhető eszközöket, azok paramétereit és a végrehajtás feltételeit. A Microsoft védelmi útmutatója tartalomelkülönítést, a tervtől való eltérés és az eszközhívási lánc figyelését, minimális és rövid életű jogosultságokat, valamint emberi jóváhagyást sorol a rétegek közé. Az ellenőrzés tárgya mindig az legyen, hogy az ágens mit olvashat és mit hajthat végre.
Határozd meg a támadó által befolyásolható bemenetet
Írd le az ágens konkrét feladatát és azt, ki jogosult módosítani a célját. Ezután jelöld külön a felhasználó kérését, a visszakeresett dokumentumot, a megnyitott weboldalt, az e-mailt és az eszköz válaszát. A keresőtalálat vagy a belső tárolóból visszakapott állomány sem válik utasításforrássá pusztán attól, hogy egy megbízható eszköz továbbította: az eredeti tartalom szerzője ettől még lehet külső fél.
A fenyegetési modellben az engedély nélküli eredményt is nevezd meg: adat kijuttatása külső címre, rekord törlése, jogosultság módosítása vagy új eszköz váratlan meghívása. Feltételezett példa: a számla összefoglalását végző ágens csatolmányban olyan mondatot talál, amely az ügyféllista exportjára utasítja. A határ akkor működik, ha a csatolmány alapján az export nem indulhat el, függetlenül attól, hogy a modell felismerte-e a szöveget támadásként. Ez a célállapot konkrétabban tesztelhető, mint a „ne kövesd a rossz utasítást” szabály.
Válaszd szét a forrásszöveget és a végrehajtási jogot
A rendszerutasítást és a felhasználói feladatot külön mezőben kezeld a visszakeresett tartalomtól; a dokumentumot jelölt, körülhatárolt forrásként add át. A benne található felszólítás az összefoglalás tárgya lehet, de nem módosíthatja az eredeti feladatot. Ha a feldolgozás több összetevőből áll, a külső tartalmat olvasó rész csak a szükséges adatmezőket adja tovább, és ne rendelkezzen küldési vagy törlési eszközzel.
A forrásszöveg megjelölése segíti a modellt az értelmezésben, de önmagában nem kényszeríti ki a bizalmi határt. Ezt az alkalmazásnak kell megtennie az eszközhívás előtt: az engedélyezett műveletet, célt és paramétereket a felhasználó jogaihoz és az aktuális feladathoz kell mérnie. Ha a feladat egy összefoglaló készítése, egy dokumentumban szereplő e-mail-cím még nem jogosít fel üzenetküldésre. A kimenetet is kezeld külön kockázatként: a modell által előállított hivatkozás vagy jelölőnyelv nem kerülhet ellenőrzés nélkül olyan felületre, amely külső kérést indít.
Az eszközjogokat feladatonként írd le
A jogosultsági mátrix minden sorában legyen ott a művelet, az érintett adatkör, a megengedett célpont, a kezdeményező és a jog érvényessége. A döntést a végrehajtó réteg hozza meg, ne az ágens saját szöveges indoklása. Az alábbi minta feltételezett dokumentumfeldolgozó munkafolyamathoz készült; az engedélyezett címzetteket és adatköröket az adott rendszerben kell meghatározni.
- Dokumentumolvasás: csak a feladathoz kijelölt állományokra; ahol elég, olvasási joggal. Az olvasás nem ad módosítási vagy megosztási engedélyt.
- Keresés és webelérés: csak a szükséges forrásokhoz és célokhoz. A talált oldal tartalma nem változtathatja meg az ágens eszközlistáját.
- Üzenetküldés és export: csak előre megengedett címzettre, adattípusra és felhasználói célból. A külső forrásban talált címzett nem kerülhet automatikusan az engedélyezett listára.
- Törlés és jogosultságmódosítás: külön engedélyhez, pontos célponthoz és végrehajtás előtti megerősítéshez kötve.
Ha az ágensnek csak olvasnia kell, ne kapjon írási hitelesítő adatot. Az ideiglenes jogot az adott műveletre és időre korlátozd, majd vond vissza; az általános felhasználói hozzáférés átmásolása az ágensnek fölöslegesen nagy támadási felületet nyit. A szabály az egymás után hívott eszközökre is vonatkozzon: külön-külön megengedett olvasás és küldés együtt már jogosulatlan adatátadást eredményezhet.
A nagy hatású műveletnél legyen valódi megálló
A jóváhagyási pontot a tényleges eszközhívás elé tedd. A felhasználó lássa a műveletet, a célpontot, az érintett adatok körét és az eredeti kéréshez való kapcsolatot. A hozzájárulás egy pontos műveletre és paraméterkészletre szóljon: ha a címzett vagy az adatkör megváltozik, új döntés kell. Az elutasítás után a végrehajtó réteg ne próbálja másik eszközzel teljesíteni ugyanazt a kérést.
A Microsoft biztonsági elemzése megkülönbözteti a valószínűségi felismerést a meghatározott hatást kizáró, determinisztikus korlátoktól. A mintakereső szűrő, a második modell értékelése és a terveltérés jelzése tévedhet; ezek riasztást és további vizsgálatot segítenek. A végrehajtó kódban érvényesített jogosultság és címzettlista, valamint a jóváhagyás hiányában blokkoló kapu az adott tiltott műveletet akkor is megállíthatja, ha az ágens félreérti a forrást. A garancia mindig a pontosan lefedett műveletre és helyesen beállított szabályra vonatkozik.
A teszt a végrehajtást mérje, a napló a döntést őrizze
A tesztkészlet a saját adatfolyamot utánozza, és minden esethez előre rögzítse a megengedett választ meg a tiltott eszközhívást. Így a siker mércéje nem egy udvarias elutasító mondat, hanem a végrehajtási határ viselkedése. A legitim feladat teljesülését is vizsgáld, mert a túl széles szűrés a valódi dokumentumok feldolgozását is leállíthatja.
- Tegyél feltételezett utasítást visszakeresett dokumentumba: az ágens foglalja össze a tartalmat, de ne indítson új műveletet.
- Ismételd meg a próbát weboldallal és eszközválasszal, majd rejtett vagy kódolt szöveggel; mindegyik belépési pont ugyanahhoz az engedélyezési szabályhoz fusson.
- Kérj a külső tartalmon keresztül más címzettet, szélesebb adatlekérést vagy egymásra épülő eszközhívásokat; ellenőrizd a tiltott paraméter és a tiltott lánc elutasítását.
- Használj olyan ártalmatlan feladatot is, amely támadó szavakat idéz; rögzítsd, ha a felismerő tévesen leállítja a munkát.
Az incidens vizsgálatához naplózd az eredeti feladat azonosítóját, a külső tartalom eredetét, a tervezett műveletet és paramétereit, az alkalmazott szabályt, a jóváhagyási döntést és a tényleges eredményt. Érzékeny tartalomból csak annyit őrizz meg, amennyi az esemény megértéséhez szükséges; a naplóhoz való hozzáférést is korlátozd. Külön jelzésre érdemes kötni az új címzettet, a feladattól eltérő eszközt és a szokatlan eszközláncot. Ha egy próba hibát talál, a végrehajtási szabályt és a hozzá tartozó tesztet együtt módosítsd, hogy ugyanaz a bemeneti út később is ellenőrzés alatt maradjon.
Kapcsolódó cikkek


RAG vagy finomhangolás: a változó tudást nem érdemes a modellbe égetni

JSON mód helyett séma: így nem csúszik szét az MI válasza

MCP vagy function calling? A csere nem mindig egyszerűsítés

LangSmith, Phoenix vagy Langfuse: nem ugyanazt méri mindhárom

A RemControl tévéappnak álcázza magát, majd banki belépést másol
Iratkozzon fel hírlevelünkre
A legfrissebb Web3-, MI- és kriptohírek egyenesen a postafiókjába.