Új biztonsági modellt kapott az MCP, négy szinttel és szigorúbb kontrollokkal

A fenyegetési listától az auditálható követelményekig

Az első változat tizenkét fenyegetési kategóriát és harmincnégy egyedi fenyegetést írt le, kontrollokkal és mérséklési javaslatokkal együtt. A Coalition for Secure AI szerint ez azt válaszolta meg, mi romolhat el és miért, a biztonsági csapatok azonban azt is tudni akarták, hogy egy konkrét telepítésre ebből mennyi vonatkozik, illetve mikor tekinthető elegendőnek a védelem.

A 2.0-s változat, amelyet a forrás szerint 2026. augusztus 12-én publikáltak, erre a kérdésre ad választ. A dokumentum minden kontrollt visszaköt az MCP-T1 és MCP-T12 közötti fenyegetési kategóriákhoz, és az OWASP MCP Top 10 elemeire is hivatkozik. Így a követelmények elvileg egyértelműen összekapcsolhatók azzal a fenyegetéssel, amelyet kezelniük kell.

Négy garanciaszint határozza meg az elvárásokat

A dokumentum 3.3-as szakasza négy, egymásra épülő biztonsági garanciaszintet határoz meg. Az 1-es szint, a Sandbox, helyi fejlesztéshez és egyfelhasználós kísérletekhez készült. Itt nem lehetnek éles hitelesítő adatok vagy éles adatok, a hibáknak pedig helyreállíthatónak kell lenniük.

A 2-es, Internal szint a csapatok által megosztott és tesztkörnyezetekre vonatkozik, hitelesített felhasználókkal és mérsékelt károkozási hatókörrel. A 3-as, Production szint az érzékeny vagy üzletileg kritikus adatokat kezelő éles rendszereket célozza, ahol aktív fenyegetési felület és teljes körű naplózhatóság várható. A 4-es, Regulated szint több bérlős és ellenséges környezetekhez készült, szabályozói auditkötelezettségek mellett.

A követelmények nyolc területre terjednek ki: identitás és hitelesítés, jogosultságkezelés és delegálás, hálózati biztonság, elkülönítés és homokbeágyazás, naplózás és megfigyelhetőség, az ellátási lánc és az életciklus, az eszközök, bemenetek és kimenetek integritása, valamint az állapot és a felderítés biztonsága.

A Coalition for Secure AI külön kiemeli, hogy a 3-as szinten kötelező a tokenek küldőhöz kötése, például DPoP vagy mTLS használatával. Enélkül egy feltört ügynökkörnyezet vagy feladatkezelő újrajátszható lenne a későbbi szolgáltatások ellen. A garanciaszintet az adatok érzékenysége és a lehetséges károk hatóköre határozza meg, nem az, hogy a szerver helyben vagy hálózaton fut.

Megszűntek a protokollszintű munkamenetek

A 2026. július 28-i MCP-kiadás eltávolította a protokollszintű munkameneteket. Az új implementációkban már nincs initialize és initialized kézfogás, illetve Mcp-Session-Id fejléc. Minden kérés önálló, és a protokollverziót, a kliens identitását, valamint a kliens képességeit a _meta mezőben hordozza.

A változás könnyebbé teheti a horizontális skálázást, ugyanakkor megszünteti azt a feltételezést, hogy a kapcsolat mögött állandó, rejtett munkamenetállapot található. A dokumentum háromféle állapotot különít el. A szerver által létrehozott hivatkozásoknak, például a feladatazonosítóknak, kitalálhatatlannak, bérlőhöz és élettartamhoz kötöttnek, visszavonhatónak és naplózottnak kell lenniük. A kliens által hordozott, lezárt állapot integritásvédelmet, például HMAC-et vagy AEAD-et igényel. A névvel ellátott hivatkozásoknál, például erőforrás-URI-knál, minden olvasáskor külön jogosultság-ellenőrzés szükséges.

A server/discover váltja fel az inicializálási kézfogást a protokollverzió, a szerveridentitás és a képességek felderítésében. A _meta mezőben érkező identitás- és képességállításokat a szervernek nem megbízható bemenetként kell kezelnie, majd össze kell vetnie a hozzáférési tokenből, mTLS-tanúsítványból vagy munkaterhelési identitásból megállapított féllel.

Mit jelent ez az MCP-t használó rendszereknek?

A dokumentum szerint a 3-as és 4-es szintű telepítéseknél célszerű a tokenellenőrzést, a szabályzatértékelést, a munkaterhelési identitás cseréjét és az auditnaplózást dedikált ügynökátjáróba szervezni. A protokollképességeket kezelő Extensions Framework miatt a bővítményeket tulajdonossal, verziórögzítéssel, biztonsági felülvizsgálattal és előzetes jóváhagyással kell kezelni.

Az MCP Apps által megjelenített HTML-t a forrás akkor is nem megbízható tartalomként kezeli, ha jóváhagyott szervertől érkezik. A javasolt védelem a homokbeágyazott iframe, a tartalombiztonsági szabályzat és a postMessage üzenetek ellenőrzése. A Roots, a Sampling és a protokollszintű Logging elavultnak számítanak. Új rendszereknél a dokumentum ezek helyett eszközparamétereket vagy szerverkonfigurációt, közvetlen LLM-szolgáltatói integrációt, illetve szabványos sémát használó naplózást, például OpenTelemetryt és OCSF-et javasol.

A Coalition for Secure AI szerint a 2.0 nem váltja ki az első fenyegetési modellt, hanem annak szigorúbb, a jelenlegi protokollhoz igazított bővítése. Aki korábbi kontrollok alapján tervezett rendszert, annak elsőként a 3.3-as szakaszban kell besorolnia a telepítést, majd összevetnie a meglévő védelmeket az adott szint nyolc területre vonatkozó követelményeivel.