Egy MI-munkafolyamatnak ellenőriznie kell egy projektkiszolgálót, vagy el kell indítania egy jóváhagyott műveletet. Ehhez megfelelő eszközök és jogosultságok kellenek. A projektmappában tárolt, minden API-tokent és privát SSH-kulcsot tartalmazó fájl kényelmessé teszi a folyamatot, de növeli egy hiba vagy manipulált bemenet lehetséges következményeit.
Egy ellenőrzött MCP-közvetítő pontosan leképezheti az engedélyezett műveletek körét. Az ügynök meghatározott műveletet kér; a kiszolgáló ellenőrzi az identitást, a projektet és a jogosultságot. Ahol a folyamat lehetővé teszi, egy korlátozott háttérszolgáltatás használja a szükséges hitelesítő adatokat anélkül, hogy visszaadná őket a modellnek.
Az MCP eszközöket közvetít, nem biztosít automatikusan biztonságos jogosultságokat
A Model Context Protocol azt írja le, hogyan használhatják az ügyfelek egy kiszolgáló eszközeit és más képességeit. Az alkalmazásnak kell megbízhatóan eldöntenie, hogy egy felhasználó végrehajthat-e egy adott műveletet egy konkrét objektumon. Egy hitelesített ügyfél nem jogosult automatikusan minden projektre vagy eszközre.
Védett HTTP-kapcsolatokhoz az MCP OAuth-alapú felhatalmazási folyamatot ír le. A jelenlegi specifikáció ezt megkülönbözteti a helyi STDIO-kapcsolatoktól. A megfelelő védelem a tényleges átviteli módtól függ. Egy tetszőleges kulcs az URL paraméterében vagy egy közös, állandó token nem egyenértékű a differenciált jogosultságkezeléssel.
Konkrét példa: az A projekt az A projekt marad
A munkafolyamat feladata egy egyeztetett szolgáltatás állapotának lekérdezése az A projektben. Az erre szolgáló eszköz ellenőrzött objektumazonosítót fogad, és csak a szükséges eredményt adja vissza. Nem kínál szabadon használható parancsértelmezőt vagy minden titok általános exportját.
Minden hívást a kiszolgáló ellenőriz a felhasználó, a projekt, az eszköz és a művelet alapján. Az ügyfél által módosított projektazonosító sem teheti elérhetővé a B projektet. A célok jóváhagyott hozzárendelésekből származnak; a modell által megadott tetszőleges cím nem elegendő felhatalmazás. A bérlők közötti határok is az ellenőrzés részei.
A token címzettjét is ellenőrizni kell
A védett HTTP-MCP-kiszolgálón a hozzáférési tokent a megfelelő címzett számára kell kiállítani, és ott ellenőrizni. Az audience, az engedélyezett hatókör és az érvényesség összetartozik. A rövid élettartam csökkenti egy ellopott token használhatóságának időablakát; nem helyettesíti sem a kiszolgálóoldali objektumellenőrzést, sem a visszavonási folyamatot.
Az MCP biztonsági dokumentációja tiltja az ellenőrizetlen token-passthrough eljárást: a kiszolgáló nem fogadhat el más erőforrásokhoz kiállított tokeneket saját felhatalmazási bizonyítékként, majd nem továbbíthatja őket változatlanul további API-knak. Az MCP-ügyfél bejelentkezése és a célrendszerhez való jogosultság külön bizalmi kapcsolat. Egy tisztázatlan átmenet miatt egy kiemelt jogosultságú közvetítő más céljait szolgálhatja; ezt nevezik confused deputy problémának.
A titkokat a megfelelő háttérrendszer használja
Egy felügyelt titokkezelő háttérrendszer felelősség és cél szerint biztosíthat hitelesítő adatokat. A végrehajtó szolgáltatás csak a szükséges jogokat kapja. Az adminisztrációs felület kezeli a jóváhagyásokat, hozzárendeléseket és visszavonásokat; nem válik minden kapcsolódó munkafolyamat által olvasható jelszókatalógussá.
Egy korlátozott eszköz például állapotértéket olvashat, vagy kifejezetten engedélyezett üzemeltetési műveletet hajthat végre, és megtisztított eredményt adhat vissza. A titokkezelő nyers adatai nem kerülhetnek mellékesen eszközkimenetekbe, hibaüzenetekbe, nyomkövetésekbe vagy promptokba. Ha egy konkrét ügyfélnek technikailag szüksége van egy titokra, az átadást külön értékelni kell, és hatókör, élettartam, valamint címzett szerint korlátozni. Ekkor téves lenne általános garanciát adni arra, hogy titok soha nem kerül ki.
| Ellenőrzési pont | Elvárt határ | Konkrét teszt |
|---|---|---|
| Felhasználó és projekt | Minden művelet az engedélyezett projekt hatókörében marad. | Projektazonosító módosítása: a jogosulatlan hozzáférés elutasítása. |
| Eszköz és paraméterek | Csak a tervezett műveletek és célok érhetők el. | Tetszőleges célcím vagy másik objektum azonosítójának elutasítása. |
| Token és háttérrendszer | A címzett és a felhatalmazási út egyértelmű. | Hibás audience, lejárat és visszavonás tesztelése. |
| Titkok és eredmények | Csak a szükséges eredmények hagyják el a háttérrendszert. | Eszközkimenetek, hibák és naplók ellenőrzése nyers értékekre. |
| Jóváhagyás és üzemeltetés | A jelentős következményekkel járó változtatásokat célzottan jóváhagyják. | Célhoz kötés, élettartam, korlátok és hibakezelés tesztelése. |
Külső tartalom nem adhat jogosultságot
Egy jegy, weboldal vagy kódtár tartalmazhat olyan szöveget, amely más műveletekre próbálja rávenni az ügynököt. Az eszközleírások és visszaadott eredmények is manipulálhatók. Ezek az adatok nem bizonyítanak jogosultságot. A „csak az A projektet használd” jellegű prompt segíti a feladat leírását, de nem helyettesíti a technikailag kikényszerített projekthatárt.
A szűkre szabott eszközök, ellenőrzött paraméterek, korlátozott célrendszerek és független jogosultságellenőrzés csökkentik a prompt injection hatását. A további jóváhagyások a művelettől függenek: egy állapotlekérdezés más folyamatot igényel, mint egy jelentős következményekkel járó változtatás. A jóváhagyás a konkrét célhoz és a tervezett módosításhoz kötődik.
A naplózást és a visszavonást is meg kell tervezni
A követhető üzemeltetéshez rögzíteni kell a felhasználó vagy szolgáltatás identitását, a projektet, az eszközt, a döntést, az időpontot és az eredményt. A titkos értékek kimaradnak. A megőrzést, a naplóhozzáférést és a szükséges részletességet a környezethez igazítva egyeztetik. Egyetlen sikeres naplóbejegyzés nem helyettesíti annak ellenőrzését, hogy mi történt ténylegesen a célnál.
A hívási és időkorlátok, valamint a háttérrendszer szűk hatóköre tovább csökkentik a váratlan hívások következményeit. Visszavonáskor külön kell kezelni az új hívásokat, a már kiadott jogosultsági igazolásokat és a folyamatban lévő műveleteket. Az MCP- vagy titokkezelő szolgáltatás kieséséhez meghatározott hibakezelési és helyreállítási út szükséges.
Kis pilottal érdemes kezdeni
Egy megfelelő pilot egy projekttel és néhány csak olvasó eszközzel indul. Tesztelni kell az engedélyezett és tiltott objektumazonosítókat, a hiányzó jogosultságokat, a lejárt igazolásokat, a manipulált eredményeket és a háttérrendszer kiesését. Csak ezután értékelhetők a világosan korlátozott írási műveletek. A hatókört a kockázat és a meglévő üzemeltetés határozza meg.
A DAXS segít az architektúrában, az integrációban és az ellenőrizhető eszközkör kialakításában. További részleteket ad az MCP-ről és interfészekről szóló szakmai oldal, a felügyelt SSH-hozzáférésekről szóló cikk és az MI-biztonsági áttekintés. Lehetősége van projekthez kötött MI-integrációról egyeztetni.
Gyakori kérdések
Elrejthet minden hitelesítő adatot a modell elől egy MCP-kiszolgáló?
Megfelelően megtervezett kiszolgálóoldali műveleteknél a modell csak a megtisztított eredményt kaphatja meg. Ellenőrizni kell, hogy ez minden szükséges műveletnél lehetséges-e. Egy titok technikai átadása az ügyfélnek megváltoztatja a kockázatértékelést.
Elég védelmet nyújt egy hosszú, titkos token?
Nem. A címzettet, a hatókört, az érvényességet, a felhasználó- és projekt-hozzárendelést, valamint a konkrét műveletet is ellenőrizni kell. Egyetlen széles jogosultságú token önmagában nem teremti meg ezt az elválasztást.
Hogyan indul egy többprojektű pilot?
Először egy projekt engedélyezett műveleteit határozzák meg és tesztelik. Ezután egy második projektet kifejezetten tiltott kereszthivatkozásokkal is ellenőriznek. Csak a ténylegesen kikényszerített elválasztás ad alapot további feladatokhoz.
Források: MCP: felhatalmazás, 2026.07.28-i változat (külső hivatkozás) · MCP: bizalmi határok és token-passthrough (külső hivatkozás) · OWASP: felhatalmazás hívásonként és objektumonként (külső hivatkozás) · OWASP: titkok kezelése (külső hivatkozás) · OWASP: prompt injection korlátozása (külső hivatkozás)
A konkrét funkciókat és üzemeltetési hatókört az adott környezethez egyeztetik.
