Model Context Protocol a gyakorlatban · Lecke 06

Jogosultság és biztonság

Az MCP szerver azzal a joggal dolgozik, amit adsz neki. Ez a lecke arról szól, hogyan adjunk keveset, és mit kell tudni a tartalom felőli támadásokról.

Vissza a tananyaghoz


A legkisebb jogosultság elve

A leggyakoribb hiba, hogy a szerver a teljes rendszert látja, mert így egyszerűbb volt beüzemelni. Ha egy ügyfélszolgálati asszisztens el tudja olvasni a jegyeket, meg tud írni választ, de utalni és fiókot törölni is tud, akkor a törlés joga ott van, holott soha senkinek nem volt rá szüksége.

A helyes lépés ilyenkor nem az, hogy naplózunk, és nem is az, hogy megerősítést kérünk. A helyes lépés az, hogy a felesleges képességet kivesszük a szerverből. Amit nem adtunk oda, azzal nem lehet visszaélni.


A tartalom felől jövő támadás

Az MCP sajátos kockázata az, hogy az eszköz által visszaadott szöveg bekerül a modell kontextusába. Ha ez a szöveg olyan helyről jön, ahova kívülről is lehet írni, akkor a támadó nem a rendszeredet töri fel, hanem üzenetet küld a modellednek.

Egy beérkező e-mail, egy ügyfél által kitöltött űrlap, egy nyilvános weboldal tartalma mind ilyen. Ha ezekben utasítás van, a modell hajlamos követni, mert nem tudja megkülönböztetni az adatot az utasítástól.

A védekezés nem az, hogy megkérjük a modellt, ne dőljön be. A védekezés az, hogy a kívülről jött tartalom ne érjen el veszélyes eszközt. Ha a levélolvasó és a pénzküldő ugyanabban a munkamenetben van, az baj, függetlenül attól, milyen jól van megírva a rendszerprompt.


Egy jó szabály. Ha a rendszer olyan tartalmat olvas, amit idegen írhatott, akkor abban a munkamenetben ne legyen visszafordíthatatlan művelet. A kettő szétválasztása többet ér minden szűrésnél.


Honnan jön a szerver

Egy MCP szerver telepítése ugyanolyan bizalmi döntés, mint bármilyen más program telepítése. Fut a gépeden, azzal a joggal, amit kap, és látja, amit odaadtál neki.

Mielőtt idegen szervert kötsz be, nézd meg, ki adta ki, nyílt-e a forrása, és milyen jogosultságot kér. Céges környezetben ez ne egyéni döntés legyen, hanem legyen egy jóváhagyott lista, mint bármelyik más szoftvernél.

Külön figyelj arra, ha egy szerver frissül. A leírások és az eszközök megváltozhatnak anélkül, hogy bármi látható jelét adná, és ezzel a modell viselkedése is megváltozik.


Hol legyen az emberi jóváhagyás

Nem minden művelethez kell. Ha mindenhez kérünk megerősítést, a felhasználó néhány nap alatt gépiesen rányom mindenre, és a védelem elveszti az értelmét.

Oda tegyük, ahol a művelet visszafordíthatatlan, ahol pénz mozog, vagy ahol a cégen kívülre megy valami. Máshova ne. A ritka és jelentőségteljes kérdésre az ember odafigyel, a gyakorira nem.


← Előző lecke Következő lecke →

Workshop

AI Transformation Day

Egésznapos, vezetőknek szóló program. Feltérképezzük, hol tart a szervezet, mi az első reális lépés, és milyen belső feltételek szükségesek a sikerhez. A nap végén konkrét, prioritizált cselekvési lista.

Érdekel a program →