MCP-szerver védelme: a módosító eszköz maradjon jóváhagyásköteles

A védett MCP-szervernél a bearer tokent az MCP-végpont előtt kell ellenőrizni, majd műveletenként kell eldönteni, mire jogosult a hívó. Az MI-ügynök számára csak a feladathoz szükséges eszközöket engedélyezd; az adatot módosító eszközhívás végrehajtását kösd emberi jóváhagyáshoz.

Ez három külön döntés: beléphet-e a hívó a szerverhez, használhatja-e az adott műveletet, és lefuthat-e az ügynök által kezdeményezett konkrét hívás. Egy érvényes OAuth-token önmagában nem ad felhatalmazást minden elérhető eszközre vagy minden rekord módosítására. A jóváhagyás sem pótolja a szerver saját jogosultság-ellenőrzését.

A tokent a végpont előtt ellenőrizd

Az MCP TypeScript SDK hitelesítési útmutatója az MCP-szervert OAuth-erőforrásszerverként kezeli: a tokent külön hitelesítési szerver adja ki, az MCP-szerver pedig ellenőrzi. Express esetén a saját tokenellenőrzővel létrehozott requireBearerAuth kaput a /mcp útvonal elé helyezi. A hiányzó, hibás vagy lejárt tokenre a dokumentált kapu 401 invalid_token választ ad; a végpont egészére előírt scope hiányára 403 insufficient_scope a válasz.

A verifyAccessToken függvényben ellenőrizd a token érvényességét a választott módszerrel, például helyi JWT-ellenőrzéssel vagy introspekcióval. Az ellenőrzött adatokból állítsd elő az AuthInfo értékeit, köztük a kliensazonosítót, a scope-okat, a lejáratot és az erőforrás azonosítóját. A lejáratot ne hagyd üresen: a requireBearerAuth az expiresAt nélkül továbbadott tokent is érvénytelennek tekinti.

Az expectedResource értékét ahhoz az erőforrás-azonosítóhoz igazítsd, amelyet a hitelesítési szerver az ennek az MCP-szervernek szánt tokenbe tesz. A token ellenőrzője a megfelelő audience értéket adja tovább az AuthInfo.resource mezőben. Így a más erőforráshoz kiadott token elutasítható; expectedResource nélkül ez az összehasonlítás elmarad. Express használatakor a kapcsolódó csomagokat együtt frissítsd: az útmutató szerint a @modelcontextprotocol/express 2.0.1 nem továbbítja az expectedResource beállítást.

A védett erőforrás metaadatait is tedd elérhetővé. A hitelesítést kérő válasz ezekre mutat, így az ügyfél megtalálhatja a megfelelő hitelesítési szervert, tokent kérhet, majd újrapróbálhatja a hívást. Ez a bejelentkezési útvonal része; a művelethez szükséges további jogot külön kell megkövetelni.

Az olvasás és a módosítás külön jogosultságot kapjon

A végpont egészére beállított requiredScopes belépési feltétel. Egy szerveren belül a scopeChallenge az adott eszköz, erőforrás vagy prompt meghívása előtt további scope-ot követelhet. Állandó követelményhez a requireScopes használható; ha a szükséges jog a hívás tartalmától függ, külön ellenőrző függvény dönthet róla.

Az SDK példájában a private-notes nevű erőforrás olvasásához notes:read, a purge-notes nevű törlő eszközhöz notes:write szükséges. A saját szerveren ugyanígy különítsd el a tényleges olvasási és módosítási műveleteket. Ha a módosítás célja a paraméterektől függ, a jogosultsági döntéshez használt értékeket előbb ellenőrizd vagy egységesítsd: a dinamikus scope-ellenőrzés a bemeneti séma validálása és átalakítása előtt fut.

A scope azt fejezi ki, milyen típusú műveletre ad jogot a token; a kezelőnek ezután azt is el kell döntenie, hogy a hívó a megjelölt adaton végrehajthatja-e a műveletet. Feltételes példa: a notes:write joggal rendelkező kliens sem törölheti automatikusan egy másik felhasználó jegyzeteit. A rekord tulajdonosát, a szervezet határait vagy az adott alkalmazás hozzáférési szabályait a szerver oldalán kell érvényesíteni.

Az ügynök eszközkészlete alapból legyen szűk

A Claude Platform üzemeltetési útmutatója a Managed Agents MCP-eszközkészleténél a default_config.enabled false beállítást és csak a szükséges eszközök név szerinti engedélyezését javasolja. Az MCP-eszközkészlet egyébként alapból az összes, szerver által kínált eszközt engedélyezi. A szűk lista azt is megakadályozza, hogy egy később hozzáadott eszköz automatikusan az ügynök rendelkezésére álljon.

Az engedélyezett eszközöket a feladathoz rendeld, ne a szerver teljes kínálatához. Ha az ügynöknek keresnie és összefoglalnia kell, az ehhez szükséges olvasó műveleteket válaszd ki; a létrehozást, átírást, törlést vagy külső továbbítást csak akkor engedélyezd, ha a feladat valóban megköveteli. A név szerinti lista az ügynök számára elérhető műveleteket korlátozza, míg a token és az adathozzáférés ellenőrzése továbbra is a szerver feladata.

A tág hatókörű parancsfuttató és a saját alkalmazásban futó egyedi eszköz külön figyelmet igényel. Egy parancsfuttató engedélyezett neve önmagában nem szűkíti le, milyen parancsot kaphat. A Claude Platform egyedi eszközeire pedig nem az MCP-eszközök permission_policy szabálya vonatkozik: a hívás végrehajtásáról az alkalmazás dönt, ezért ott kell ellenőrizni a bemenetet és az elérhető műveletet.

A módosító hívás várjon emberi jóváhagyásra

A Claude Platform engedélyezési szabályai szerint az always_ask megállítja a hívást a jóváhagyásig, míg az auto a szerver értékelése alapján jóváhagyás nélkül is lefuttathatja. Ha a hívást embernek kell látnia végrehajtás előtt, az adott módosító MCP-eszközön az always_ask szabályt tartsd meg. Az olvasó MCP-eszközök más szabályt kaphatnak, ha a feladat és az adatok ezt megengedik.

A jóváhagyónak a függő hívás konkrét tartalmát mutasd meg: melyik eszköz futna, milyen bemenettel, melyik rekordot érintené, és mi lenne a várható változás. A döntést ehhez az egy híváshoz kösd; az elutasított hívás ne hajtson végre módosítást. A munkamenetnek a függő hívásnál kell folytatódnia, ezért fontos a folytatható jóváhagyási állapot kezelése.

A szüneteltetés csak akkor jelent emberi kontrollt, ha valaki valóban megvizsgálja a hívást. A várakozó kérések automatikus elfogadása kiüresíti a kaput. Jóváhagyás után a szervernek a végrehajtáskor is érvényesítenie kell a tokenre, a műveletre és az érintett adatra vonatkozó szabályait: az ügynökoldali engedély nem ad új OAuth-jogot.

Indítás előtt próbáld végig az elutasításokat

Az ellenőrzést a rétegek sorrendjében végezd. Először hívd meg a védett végpontot token nélkül, majd lejárt és más erőforráshoz kiadott tokennel. Ezután érvényes, de csak olvasásra jogosító tokennel próbálj módosító műveletet indítani. Minden elutasított esetben azt vizsgáld, hogy a kérés még az adatot változtató kezelő előtt megáll-e.

1. A megfelelő erőforráshoz kiadott, érvényes tokennel ellenőrizd, hogy a szükséges olvasó művelet működik.
2. Próbálj hiányzó műveleti scope-pal, majd más felhasználó adatára irányuló hívással módosítani; a szerver mindkét esetben akadályozza meg a jogosulatlan változtatást.
3. Nézd meg az ügynök számára elérhető eszközöket, és ellenőrizd, hogy egy újonnan hozzáadott, név szerint nem engedélyezett eszköz nem használható.
4. Indíts jogosult módosító hívást: várjon emberi döntésre, elutasítás után pedig az érintett adat maradjon változatlan.

Ha valamelyik próba váratlanul sikerül, a hibát annál a kapunál javítsd, amelynek el kellett volna utasítania a hívást. Az ügynök eszközlistájának szűkítése, a szerveroldali jogellenőrzés és az emberi jóváhagyás együtt adja a kívánt működést.

Olvassa el ezt is:

• Emberi jóváhagyás MI-ügynökben: a folytatható állapot a kulcs
• Prompt injection ellen nincs varázsszűrő: így rétegezd az ágens védelmét
• MCP vagy A2A: az egyik eszközt köt be, a másik ügynököt