> MCP biztonsági ellenőrzőlista: fenyegetési modell, tool poisoning, rug pull, RFC 9207 kiállítóellenőrzés, korlátozott tokenek és audit naplók.
>
> Web page: https://balazscsorba.com/hu/blog/mcp-server-security-checklist · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/mcp-server-security-checklist.md) · [Deutsch](https://balazscsorba.com/de/blog/mcp-server-security-checklist.md)
> Author: Balázs Csorba · Published: 2026-08-11 · Updated: 2026-09-01 · Keywords: mcp biztonság, mcp szerver biztonsági ellenőrzőlista, mcp tool poisoning, mcp rug pull, mcp oauth, mcp sebezhetőségek, hogyan védjünk meg egy mcp szervert, mcp authorization rfc 9207, nsa mcp ajánlás, mcp audit naplózás

[Blog](https://balazscsorba.com/hu/blog)/[Biztonság és megfelelés](https://balazscsorba.com/hu/blog/category/security)

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

MCP biztonsági ellenőrzőlista: fenyegetési modell, tool poisoning, rug pull, RFC 9207 kiállítóellenőrzés, korlátozott tokenek és audit naplók.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. augusztus 11.·frissítve 2026\. szeptember 1.·10 perc olvasás

-   MCP security
-   Tool poisoning
-   MCP OAuth
-   Supply chain
-   Audit logs

![MCP biztonsági ellenőrzőlista: lakattal biztosított csatlakozó és aljzat, egy kukac kúszik a kábel felé.](https://balazscsorba.com/images/blog/mcp-server-security-checklist/cover.webp?v=d61832abc7)

## A lényeg röviden

-   A bizalom két helyen ér véget: ahol a szerver által felügyelt szöveg (az eszközleírások, az eszközeredmények) modellbemenetté válik, és ahol egy általad tartott tokent egy olyan rendszer költ el, amelyet a modell befolyásolhat.
-   Az Invariant Labs 2025. április 1-jén vezette be a tool poisoning fogalmát: egy eszközleírás, amelynek rejtett utasításai az SSH-kulcsok olvasására utasítják a modellt, valamint a shadowing, amikor egy szerver átírja egy másik szerver eszközeit.
-   A rug pull egy jóváhagyás után megváltozó leírás. Pineld a szerver verzióját és a kanonikus eszközlista hash-ét, ellenőrizd az első eszközhívás előtt, és bármilyen eltérésnél diffel újra jóváhagytass.
-   A 2026-07-28 revízió megköveteli az RFC 9207 iss-ellenőrzést (SEP-2468), kiállító szerint kulcsolja a hitelesítő adatokat (SEP-2352), előnyben részesíti a Client ID Metadata Documenteket, és OTel trace kontextust ad a \_meta mezőbe (SEP-414).
-   Adj minden eszközsaládnak saját, least privilege alapú upstream tokent, a bejövő tokent soha ne továbbítsd, és minden eszközhívást loggolj trace azonosítóval: egy mérgezett eredmény csak egy normálisan kinéző API-hívást hagy hátra.

Ezen az oldalon

1.  [Mi az MCP fenyegetési modellje?](https://balazscsorba.com/#mcp-threat-model)
2.  [Hogyan működik a tool poisoning?](https://balazscsorba.com/#tool-poisoning)
3.  [Mi a rug pull, és hogyan állítod meg?](https://balazscsorba.com/#rug-pulls)
4.  [Hogyan csináld az MCP OAuth-ot és az API-tokeneket?](https://balazscsorba.com/#mcp-oauth)
5.  [Mit loggolj, és mit ad egy trace?](https://balazscsorba.com/#audit-trails)
6.  [Mit ad hozzá az NSA útmutatója?](https://balazscsorba.com/#nsa-guidance)
7.  [MCP biztonsági ellenőrzőlista](https://balazscsorba.com/#mcp-security-checklist)
8.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:00

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.

![Hol ér véget a bizalom egy MCP-telepítésben: a gép, a kliens, a szerverek és az adatok, három bizalmi határral.](https://balazscsorba.com/images/blog/mcp-server-security-checklist/diagram-5.webp?v=0f2f7e4064)

Az három MCP bizalmi határ. A hozzájárulás egyszeri párbeszédablak, az eszközdefiníciókat a modell minden munkamenetben elolvassa, az upstream tokeneket pedig olyan kód költi el, amelyet azelőtt hagytál jóvá, hogy a modellnek véleménye lett volna.

A legközelebbi közzétett taxonómia az [OWASP Top 10 for Agentic Applications](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) (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](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks) (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 eszközleírás modellbemenet, nem dokumentáció**

Ha a futtatókörnyezeted egy embertnek nevet és egymondatos összefoglalót mutat, a modell viszont a teljes leírást és minden argumentumot megkap, a jóváhagyási lépés dísz. Ugyanazt a szöveget mutasd mindkettőnek, vagy legalább azokat az utasításokat, amelyek a modellnek szólnak.

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](https://balazscsorba.com/hu/blog/prompt-injection-lethal-trifecta-patterns) 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.

![Eszközdefiníció jóváhagyása: a tools/list hashelve, összevetve a rögzítettel, változáskor újrajóváhagyás kell.](https://balazscsorba.com/images/blog/mcp-server-security-checklist/diagram-14.webp?v=c28ed26382)

A jóváhagyási gate, ami csak változáskor lép be. Hashteld a kanonikus eszközlistát, hasonlítsd össze a jóváhagyott hash-csel az első eszközhívás előtt, és minden eltérést új definíciónak tekints, amelyhez kell egy ember.

Python

```
# 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”](https://www.anthropic.com/engineering/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.

Python

```
# 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”](https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF) címmel, amelyet a [Reed Smith](https://www.reedsmith.com/our-insights/blogs/viewpoints/102mvg9/nsa-publishes-security-guidance-on-designing-ai-systems-with-model-context-protoc/) 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.

Kockázat

Kontroll

Az ezt kezelő követelmény

Egy eszközleírásban rejtett utasítások

A csak a modellnek szánt szöveget is mutasd az embernek; telepítéskor nézd át a leírásokat

OWASP ASI02 és ASI04; nincs rá vonatkozó specifikációs követelmény

Egy szerver átírja egy másik szerver eszközeit (shadowing)

Klienskontextensenként egy bizalmi szint; ne legyen nem megbízható szerver egy hitelesítő adattal rendelkező mellett

NSA: a rendszereket és az adatokat bizalmi szint szerint el kell különíteni

A definíció a jóváhagyás után megváltozik

Pineld a verziót és a kanonikus eszközlista hash-ét, változásnál új jóváhagyás, fail closed

Nincs rá specifikációs válasz; klienspolitika

A kód egy rossz authorization szerverhez kerül

Ellenőrizd az `iss`\-t a beváltás előtt; kulcsold kiállító szerint a hitelesítő adatokat

SEP-2468, SEP-2352, RFC 9207

Nem átvizsgálható kliensazonosítás

Client ID Metadata Documentek a Dynamic Client Registration helyett

A 2026-07-28 a CIMD-t preferálja; a DCR deprecated

Túl széles upstream token

Egy korlátozott token eszközsaládonként; a bejövő tokent soha ne továbbítsd

NSA: csak a minimális hozzáférést adj

Nincs mód egy incidens rekonstruálására

Minden eszközhívást továbbadott trace kontextussal loggolj

SEP-414; az MCP Logging az OTel és a stderr kedvéért deprecated

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; az átviteli változásokról, amelyek erre hatással vannak, a [2026-07-28 migrációs útmutató](https://balazscsorba.com/hu/blog/mcp-2026-07-28-stateless-migration-guide) szól. Az MCP elé állítani egy rendszert, amely valódi hitelesítő adatokat tart, pontosan az a munka, amelyet [MI mérnökként](https://balazscsorba.com/hu/expertise/ai-engineer) végzek.

## Források

1.  [Invariant Labs: MCP Security Notification – Tool Poisoning Attacks (2025. április 1.)](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks)
2.  [OWASP: Top 10 for Agentic Applications for 2026 (2025. december 9.)](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/)
3.  [MCP specifikáció 2026-07-28: changelog (SEP-2468, SEP-2352, SEP-414)](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/changelog.mdx)
4.  [RFC 9207: OAuth 2.0 Authorization Server Issuer Identification](https://www.rfc-editor.org/rfc/rfc9207)
5.  [NSA: Model Context Protocol (MCP) – Security Design Considerations for AI-Driven Automation (2026. május)](https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF)
6.  [Reed Smith: NSA publishes security guidance on designing AI systems with MCP (2026. június 4.)](https://www.reedsmith.com/our-insights/blogs/viewpoints/102mvg9/nsa-publishes-security-guidance-on-designing-ai-systems-with-model-context-protoc/)
7.  [Anthropic: How we contain Claude across products (2026. május 25.)](https://www.anthropic.com/engineering/how-we-contain-claude)

## Gyakori kérdések

Mi az az MCP tool poisoning?

A tool poisoning egy eszköz leírása elleni támadás, nem a kódjáé. Az Invariant Labs 2025. április 1-jén vezette be a fogalmat egy osztályra, amelyet közvetett prompt injectionként ír le: egy ártalmatlan eszköz – például két számot összeadó – leírása utasítja a modellt arra is, hogy olvasson el fájlokat, például egy privát SSH-kulcsot, és a tartalmukat argumentként adja tovább. A felhasználó egy nevet lát; a modell az utasításokat és az argumentumokat.

Hogyan állítom meg, hogy egy MCP szerver rug pullal csapjon be?

Két dolgot rögzíts: a szerver verzióját és a kanonikus eszközlista hash-ét, vagyis a rendezett neveket, leírásokat és JSON-sémákat. Minden munkamenetben ellenőrizd a hasht az első eszközhívás előtt, előbb kanonizálj, hogy az átrendezés ne tűnjön változásnak, és fail closed módon állj meg, ha a listát nem lehet lekérni. Eltérésnél mutass diffet az embernek, és csak elfogadás után rögzítsd újra: egy megváltozott leírás új definíció, amelyet jóvá kell hagyni.

Mit változtat az RFC 9207 iss-ellenőrzés az MCP kliensekben?

Az RFC 9207 lehetővé teszi, hogy az authorization szerver megadja, melyik kiállító, és megköveteli a klienstől, hogy ezt az értéket a rögzített kiállítóval egyeztesse, mielőtt egy engedélyezési kódot bevált. Ez lezárja a felcseréléses támadást, ahol a támadó a saját szerverére irányítja a klienst, hogy a valódi szerverre szánt kódot beváltsa. Az MCP 2026-07-28 revíziója a SEP-2468 szerint kötelezővé teszi az iss paramétert, és bevezeti a SEP-2352-t, amely kiállító szerint kulcsolja a hitelesítő adatokat, hogy azok soha ne legyenek újrahasznosíthatók szervereken át.

Mi a Client ID Metadata Document az MCP-ben?

A Dynamic Client Registration helyébe lép, mint az MCP kliens azonosításának kedvező módja. Ahelyett, hogy futásidőben regisztrálna és egy átláthatatlan kliensazonosítót kapna, a kliensazonosító egy HTTPS-URL, amely egy JSON-dokumentumra mutat, benne legalább client\_id, client\_name és redirect\_uris. Ezt a dokumentumot bárki elolvashatja, így a reviewer jóváhagyás előtt ellenőrizheti, mit állít egy kliens magáról. Az authorization szerverek a client\_id\_metadata\_document\_supported mezővel jelzik a támogatást.

Hogyan korlátozza egy MCP szerver az API-tokenjeit?

Adj minden eszközsaládnak saját hitelesítő adatot a legkisebb hatókörrel, amellyel az eszköz működik, és a csak olvasó eszközöket csak olvasó tokeneken tartsd. Egy Jira szerver, amelynek eszközei keresés, komment és átmenet, ne tartson egyetlen tokent, amely mind a hármat meg tudja tenni. Csak a neked kiállított tokeneket fogadd el, ellenőrizd az audience-t, és a bejövő tokent soha ne továbbítsd felfelé. Írd le a mondatot: mi a legrosszabb, amit ez a token tehet, és bontsd ketté azt a hitelesítő adatot, amelynek a válasza túl széles.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Protect AI modellszkenner: Guardian nincs többé, a ModelScan viszont van](https://balazscsorba.com/hu/blog/protect-ai)
-   [LLM output guardrailek: moderáció, biztonságos megjelenítés és ellenőrzés, mielőtt bármi történne](https://balazscsorba.com/hu/blog/llm-output-guardrails-moderation)
-   [AI red teaming ellenőrzőlista LLM-appokhoz: mit támadj meg, mielőtt a felhasználók tennék](https://balazscsorba.com/hu/blog/ai-red-teaming-checklist-llm-apps)
-   [Slopsquatting: amikor a kódoló ügynökök nem létező csomagokat telepítenek](https://balazscsorba.com/hu/blog/slopsquatting-ai-package-hallucinations)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)