MCP biztonsági ellenőrzőlista: tool poisoning, rug pull és OAuth

Az MCP biztonsága az a döntéshalmaz, amely meghatározza, mit olvashat, módosíthat és költhet egy Model Context Protocol szerver egy ember vagy egy ügynök nevében, plusz az ezeket kikötő kontrollok. Nem átviteli probléma. A JSON-RPC nem dönti el, kinek bízunk, egy séma-validátor sem, és a helyes válasz semmit nem bizonyít. Minden MCP szerver olyan program, amelyet egyszer jóváhagytál, és egy olyan hurokban ül, ahol a hívó egy modell, az argumentumok pedig modell által generáltak.

Ez az ellenőrzőlista a fenyegetési modellel kezd: a szerverekkel, a kliensekkel, a hosztokkal és a három ponttal, ahol a bizalom valójában véget ér. Utána a két támadás, amelyet ez a protokoll olcsóvá tett, a tool poisoning és a rug pull, a 2026-07-28 revízió hitelesítési változásai (RFC 9207 iss ellenőrzés, Client ID Metadata Documentek, kiállítónként külön hitelesítő adatok), a least privilege alapú upstream tokenek, és az auditnyom a revízióban hozzáadott OpenTelemetry trace kontextussal. Végül egy ellenőrzőlista, egy táblázat, amely minden kockázathoz rendeli a kontrollt és a mögötte álló követelményt, és az, amit az NSA 2026-os útmutatója hozzátesz.

Mi az MCP fenyegetési modellje?

Négy szereplőt nevezz meg, mielőtt egyetlen ellenőrzést leírsz. A szerver olyan kódot futtat, amit nem te írtál, modell által generált argumentumokat kap, és olyan szöveget ad vissza, amely egyenesen a modell kontextusába kerül. A kliens az a host alkalmazás, amely a modellt, az eszközlistát és a felhasználó hitelesítő adatait tartja. A felhasználó hagyja jóvá a szervereket, és viseli a következményeket. Az upstream az az API, amelyet a szerver az általad kapott tokentel hív. A szerver tehát egyszerre két dolog: kódvégrehajtási függőség a szokásos szoftverellátási láncban, és olyan csatorna, amely szöveget etet be, amit a modell követ.

A bizalom nem a folyamatod vagy a hálózatod határán ér véget. Két helyen ér véget: abban a pillanatban, amikor a szerver által felügyelt szöveg modellbemenetté válik – egy eszközleírás a felderítés pillanatában vagy egy eszközeredmény a hívás pillanatában; és abban a pillanatban, amikor egy általad tartott tokent egy olyan rendszer költ el, amelyet egy modell befolyásolhat. Minden más itt egy kontroll e két átlépés egyikén.

A legközelebbi közzétett taxonómia az OWASP Top 10 for Agentic Applications (2025. december 9., a 2026-ra). Két bejegyzése fogja át a cikk teljes tartalmát: az ASI02 Tool Misuse és az ASI04 Agentic Supply Chain, utóbbi azt a szervert, amelyet telepítesz, nem azt, amelyet te írtál. A taxonómiát használd a kockázat megnevezésére, mert az „összezavarodott az ügynök” nem használható megállapítás.

Hogyan működik a tool poisoning?

A tool poisoning a leírás elleni támadás, nem a kódé. Az Invariant Labs közzétette azt az írást, amely elnevezte ezt az osztályt, 2025. április 1-jén (Luca Beurer-Kellner és Marc Fischer): rosszindulatú utasítások egy eszközleírásba ágyazva – ezt nevezik ők a közvetett prompt injection egyik formájának. A példájuk egy add eszköz, amelynek leírása azt is mondja, hogy olvassa el a ~/.cursor/mcp.json és a ~/.ssh/id_rsa fájlt, és a tartalmukat argumentként adja tovább. A felhasználó egy eszközt lát, amely két számot összead. A modell fájlútvonalakat lát.

Az aszimmetria a mechanizmus. A Cursorral végzett kísérleteikben a megerősítő ablak egy eszköznevet és egy összefoglalót mutatott, míg az argumentumok – köztük az SSH-kulcs – egy egyszerűsített felület mögé rejtődtek. Az Invariant Labs következtetése egyértelmű: az MCP biztonsági modellje azt feltételezi, hogy az eszközleírások megbízhatóak és ártalmatlanok, és ezt nem ellenőrzi. A második megállapításukhoz, a shadowing-hez nem kell meghívni a támadó saját eszközét. Egy második szerver leírása további viselkedést ír elő egy megbízható eszközre – esetükben azt, hogy egy send_email eszköznek az összes levelet a támadó címére kell irányítania. Az ügynök ezután levelet küld a támadónak, holott a felhasználó más címzést kért, és semmi az interakciós naplóban nem nevezi meg a rosszindulatú szervert.

Az ellenintézkedéseik három: tegyél láhatóan különbözővé a felhasználónak és a modellnek szánt utasításokat, hash-szel rögzítsd a szervert és az eszközdefinícióit, és kényszeríts ki adatfolyam-határokat a szerverek között. Az első felületváltoztatás, a második a következő szakasz, a harmadik architekturális. Hogy egy leírás miért injektálási csatorna, arról a prompt injection mint architekturprobléma cikk szól.

Mi a rug pull, és hogyan állítod meg?

A rug pull ugyanaz a támadás, csak jobb időzítéssel: telepítéskor a szerver legitim, és később megváltoztatja a leírást. Az Invariant Labs a PyPI-n végbement csomagcseréhez hasonlítja, ami egy jóváhagyás után történt. A rögzítésnek két fele van. Rögzítsd a verziót, ami megakadályozza, hogy új kód érkezzen, és rögzítsd a kanonikus eszközlista hash-ét, ami megakadályozza, hogy megváltozzon az a szöveg, amelyet a modell olvas. Önmagában a verziórögzítés nem fogja meg a patch release-ben módosított leírást.

# Pseudo-code: an approve-on-change gate in the client
approved = load_approved_hashes()          # server id -> sha256 of the canonical tool list

def open_session(server):
    tools = server.tools_list()            # names, descriptions, JSON schemas
    digest = sha256(canonical_json(tools)) # sort keys, sort tools, normalize whitespace
    if approved.get(server.id) != digest:
        show_diff(approved_tools.get(server.id), tools)   # a human reads it
        approved[server.id] = digest       # re-approve, then re-pin
    return Session(server, tools)

Két részlet dönti el, hogy ez működik-e. Kanonizálás: a nyers válasz hashelése azt jelenti, hogy egy átrendezett lista változásnak látszik, és a felhasználók megtanulnak továbbkattintani. Fail closed: ha a listát nem lehet lekérni vagy hashelni, a munkamenet nem indul el. A revízió ttlMs és cacheScope mezői a listaeredményeken költségelemek, nem kontrollok: egy egy órával korábban ellenőrzött eszközlista most nincs ellenőrizve.

Az Anthropic a helyi és a távoli közti különbséget a „How we contain Claude” cikkben teszi egyértelművé (2026. május 25.): „Egy helyben telepített eszköz auditálható. Elolvashatod a kódot, rögzítheted a verziót, és tudod, hogy nem változik a hátad alatt. Egy távoli eszköz, egy hosztolt MCP szerver, egy felhőkapcsoló bármikor megváltoztathatja a viselkedését, miután jóváhagytad.” Tanácsuk mindarra, ami egy átnézett könyvtáron kívül van: először hamis adatokkal fuss, ahol egy rosszindulatú eszköz hatásköre korlátozott.

Hogyan csináld az MCP OAuth-ot és az API-tokeneket?

A 2026-07-28 revízióban három változás számít, és mindhárom arról szól, ki állította ki a tokent. Először az RFC 9207 iss ellenőrzése: az authorization szerverek megadják a kiállítójukat az authorization válaszban, és a klienseknek a kód beváltása előtt egyeztetniük kell a kapott iss-t a rögzített kiállítóval. Ez lezárja a felcserélés osztályát, ahol a támadó egy saját authorization szerverre irányítja a klienst, hogy egy a tiédre szánt kódot beváltson. A revízió ezt a SEP-2468 szerint kötelezővé teszi. Másodszor a SEP-2352: a megőrzött hitelesítő adatok a kiállító azonosítójával vannak kulcsolva, más authorization szerverrel nem használhatók újra, és ha az adott szerver változik, újra regisztrálni kell őket. Harmadszor a Client ID Metadata Documenteket előnyben részesítik a Dynamic Client Registrationnel szemben: a kliens azonosítója egy HTTPS-URL, amely egy JSON-dokumentumra mutat, amelyben legalább client_id, client_name és redirect_uris van, így a kliens auditálható egy dokumentum elolvasásával. A DCR deprecated, az eltávolítása legkorábban az első, 2027. július 28. után kiadott revízióban történhet.

# Pseudo-code: the two client-side checks the revision requires
if "iss" in authorization_response and authorization_response["iss"] != recorded_issuer:
    raise AuthorizationError("issuer mismatch")   # RFC 9207, before the code is redeemed

creds = key_store.get(authorization_response["iss"])   # SEP-2352: keyed by issuer
if creds is None or creds.issuer != authorization_response["iss"]:
    register_again()                                  # never reuse across servers

A szerveroldalon szűkebb a feladat: csak azokat a tokeneket fogadd el, amelyeket neked állítottak ki, ellenőrizd az audience-t, és a bejövő tokent soha ne továbbítsd felfelé. A legjobb tokenhigiénia az upstream oldalon van, nem az inbound oldalon. Adj minden eszközsaládnak saját hitelesítő adatot a legkisebb hatókörrel, ami mellett már működik, és a csak olvasó eszközeket csak olvasó tokeneken tartsd, hogy egy Jira szerverben mérgezett leírás issue-kat tudjon olvasni, de ne tudjon átmenetet indítani. A próba: írd le minden olyan hitelesítő adathoz, amelyet a szervered tart, a mondatot „mi a legrosszabb, amit ez a token tehet”, és bontsd ketté azt, amelyre a válasz szélesebb, mint az eszköz célja.

Mit loggolj, és mit ad egy trace?

A protokoll naplózási képessége a 2026-07-28 revízióban deprecated, helyette OpenTelemetry és stderr, a naplózási szint pedig mostantól kérésenként a io.modelcontextprotocol/logLevel mezőben utazik. A szerveroldali naplók alapból az auditnyomod, nem egy beszélgetési csatorna.

Egy eszközhívásonként loggolj, nem kérésenként: trace- vagy munkamenetazonosító, az a tárgy, akinek a tokent képviseli, a szerver, az eszköz, az argumentumok és az eredmény hash-e és mérete, az upstream URL, a döntés, az időtartam. Tokent soha ne loggolj. A SEP-414 dokumentált _meta kulcsokat ad az OpenTelemetry trace kontextushoz, így egy traceparent összeköti a modellhívást, a klienst, a gatewayt és a szerveredet. Enélkül időbélyegek alapján correlálsz, és reménykedsz.

A kemény korlátot érdemes nyíltan kimondani. Az Anthropicnak a saját kapcsolójáról szóló állítása az, hogy egy mérgezett eszközeredmény úgy terelheti az ügynököt egy hívás felé, amely a naplóban sikeres, engedélyezett API-kérésnek látszik: „miután egy mérgezett eszközvisszatérés az ügynököt az adatok kiszivárogtatásába terelte, a napló csak egy sikeres, engedélyezett API-hívást mutat. Nincs utólagos jel, amit keresni lehetne.” Tehát loggolj szemantikát, nem csak átvitelt: melyik eszköz melyik erőforrást érintette, milyen gyakran, milyen ütemben, egy alaphoz viszonyítva. Az ellenintézkedésük egy proxy a hálózatot használó eszközök elé, amely a visszatérési értékeket ellenőrzi, mielőtt azok a kontextusba kerülnének.

Mit ad hozzá az NSA útmutatója?

2026 májusában az NSA kiadott egy Computer Security Information bulletin-t „Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation” címmel, amelyet a Reed Smith 2026. június 4-én foglalt össze. A kiindulópont: a terjedés megelőzte a védelmi intézkedéseket, és így a szervezetek olyan kockázatoknak vannak kitéve, amelyeket a protokoll tervezői nem láttak előre. A felsorolt kockázatok között szerepel a felügyelet nélküli automatizált művelet, a hiányzó bemenetszűrés, a context poisoning, a gyenge identitás- és hozzáféréskezelés, az adat szivárgása, a hiányzó emberi jóváhagyás, a lejárati vagy visszavonási lehetőség nélküli hitelesítő adatok és a túlterhelésre való hajlamosság.

Listaként olvasva a legtöbbje már az, amit ez a cikk előír: minden automatizált műveletet kezelj magas kockázatúnak, és tartsd szigorú jogosultsági határok között, válaszd el a rendszereket és az adatokat bizalmi szint szerint, adj csak minimális hozzáférést, szűrj bemeneteket, futtasd a adatfeldolgozást helyben, ahol tudod, és tarts átfogó tevékenységi naplókat a meglévő monitorozásoddal összevetve. Két ajánlás ritkább az MCP irodalmában: használj megbízható, aktívan karbantartott eszközöket megbízható szolgáltatóktól, és vidd rájuk a legszigorúbb review-folyamatodat, ugyanazt, amelyet az új produkciós szoftverre alkalmazol. Ez útmutató, nem szabvány, de olyan dokumentum, amelyet egy biztonsági csapat felismer, és ez számít, ha a kontrollnak finanszírozást kell szerezni.

MCP biztonsági ellenőrzőlista

A táblázat az összefoglaló: kockázat, kontroll és a mögötte álló követelmény.

1. Írd le a bizalmi térképet: mely szerverek osztoznak egy klienskontextusen, milyen hitelesítő adatokat tart meg egy-egy szerver, és ezek közül melyeket nem te írtál.
2. Pineld minden szervert: verzió plusz a kanonikus eszközlista hash-e, ellenőrizve az első eszközhívás előtt, fail closed módon.
3. Változásnál kérj új jóváhagyást, és mutasd a diffet, hogy egy megváltozott leírás döntés legyen, ne meglepetés.
4. A leírásokat és az eszközeredményeket kezeld nem megbízható bemenetként, és nézd meg, mit ad vissza egy hálózatot használó eszköz, mielőtt a kontextusba kerülne.
5. Ellenőrizd az iss-t, és kulcsold kiállító szerint a hitelesítő adatokat, ha klienst szállítasz; a regisztrációhoz CIMD-t használj DCR helyett.
6. Minden eszközsaládnak adj saját korlátozott tokent, csak a neked kiállított tokeneket fogadd el, és a bejövő tokent soha ne továbbítsd felfelé.
7. Loggolj minden eszközhívást a _meta-ból kapott trace kontextussal, és riazz változásokra: új definíciók, új kimenő célok, új token hatókörök.
8. Új szervert úgy nézz át, mint egy új függőséget: forrás vagy beszállító, karbantartó, telepítési útvonal, és az az adat, amelyet elérhet.

Az eszközleírások tervezési problémák is, mert ugyanaz a szöveg olcsónak kell lennie ahhoz, hogy a kontextusban maradjon, és elég pontosnak ahhoz, hogy jól válassz: erről a MCP eszközök tervezése, amelyet az ügynökök jól választanak cikk szól, az átviteli változásokról pedig, amelyek erre hatással vannak, a 2026-07-28 migrációs útmutató. Az MCP elé állítani egy rendszert, amely valódi hitelesítő adatokat tart, pontosan az a munka, amelyet MI mérnökként végzek.

Források

1. Invariant Labs: MCP Security Notification – Tool Poisoning Attacks (2025. április 1.)
2. OWASP: Top 10 for Agentic Applications for 2026 (2025. december 9.)
3. MCP specifikáció 2026-07-28: changelog (SEP-2468, SEP-2352, SEP-414)
4. RFC 9207: OAuth 2.0 Authorization Server Issuer Identification
5. NSA: Model Context Protocol (MCP) – Security Design Considerations for AI-Driven Automation (2026. május)
6. Reed Smith: NSA publishes security guidance on designing AI systems with MCP (2026. június 4.)
7. Anthropic: How we contain Claude across products (2026. május 25.)