MCP-végpont cégeknek: kapcsolódás, jogosultság és biztonságos végrehajtás

Az MCP, vagyis Model Context Protocol azt szabályozza, hogyan kapcsolódhat egy kompatibilis AI-alkalmazás külső adatforrásokhoz és eszközökhöz. Egy vállalkozás számára ennek akkor van értéke, ha ismétlődő, jól körülhatárolható feladatot tesz elérhetővé: például termékadatot keres vagy rendelési állapotot kérdez le.

A végpont létrehozásától egy asszisztens még nem találja meg automatikusan a céget, és nem kap jogot arra, hogy a nevében intézkedjen. A csatlakozás, a hitelesítés, az eszközválasztás és a végrehajtási engedély külön kérdés. Ezeket üzleti folyamatként is meg kell tervezni, nem csak fejlesztői interfészként.

A kliens és a szerver szerepe

Az AI-alkalmazásban működő MCP-kliens egy konfigurált vagy más támogatott módon kiválasztott szerverhez kapcsolódik. A felek egyeztetik a képességeiket. Az eszközöket kínáló szervernél a kliens a tools/list kéréssel ismerheti meg az elérhető műveleteket, és a tools/call kéréssel hívhatja meg őket.

Az eszköz neve, leírása és bemeneti sémája segít abban, hogy az alkalmazás a megfelelő műveletet válassza. A protokoll azonban nem teszi igaz állítássá a leírást, és nem pótolja az üzleti szabályokat. A szervernek kell eldöntenie, hogy a kérés az adott felhasználó számára megengedett-e. A működést az MCP eszközspecifikációja írja le.

Egy /mcp útvonal elnevezése önmagában nem jelent szabványos implementációt. A célklienssel tényleges kompatibilitási próbát kell végezni, beleértve a kapcsolódást, a hibaválaszokat és a megszakadt kérések kezelését. A verziót és az alkalmazott átviteli módot a műszaki átadásban rögzíteni kell.

Kezdd egy olvasási célú katalóguslekérdezéssel

Egy lehetséges pilotban a cég nyilvános termékkatalógusa kereshető. Ez szemléltető terv, nem kész Conen-szolgáltatás. Az eszköz bemenete lehet keresőkifejezés és kategória, kimenete pedig cikkszám, megnevezés, termékoldal és adatfrissítési időpont.

Az olvasási feladatnál is szükség van korlátokra. Egy lekérdezés ne adja vissza az egész belső adatbázist; legyen találati és kérésszámkorlát. A partnerenként eltérő ár, a beszerzési ár és a belső készletmegjegyzés ne kerüljön nyilvános válaszba.

Az üres találatot és az átmenetileg elérhetetlen adatforrást külön jelöld. Az asszisztens ne találjon ki készletet akkor, amikor a háttérrendszer nem válaszol. Az ár és készlet mellé adott időbélyeg segít felismerni az elavult választ, de a vásárlás pillanatában új ellenőrzés szükséges.

Magyar katalógusnál a tesztkészlet tartalmazhat ékezet nélküli keresést, cikkszámot, többértelmű terméknevet és megszűnt terméket. A siker itt az, hogy az asszisztens ellenőrizhető termékadatot ad vissza, nem az, hogy minden kérdésre magabiztos választ fogalmaz.

Hol húzódnak a bizalmi határok?

Az első határ a felhasználó és az AI-alkalmazás között van: mit kért ténylegesen az ember? A második a kliens és az MCP-szerver között: melyik személy vagy rendszer küldi a kérést? A harmadik a szerver és az üzleti háttérrendszer között: milyen adathoz és művelethez férhet hozzá?

Egy bejelentkezett felhasználó sem láthatja automatikusan más partner rendeléseit. A szerver az ellenőrzött identitásból vezesse le a szervezeti jogosultságot; ne bízzon a bemenetként érkező cégazonosítóban. A rekordhoz való hozzáférést minden releváns kérésnél ellenőrizni kell.

A CORS böngészőoldali hozzáférési szabály, nem felhasználói jogosultságkezelés. A sebességkorlát túlterhelés ellen segíthet, de nem mondja meg, ki törölhet rendelést. Egy közös API-kulcs pedig rendszerazonosító lehet, miközben a végfelhasználó felhatalmazását nem bizonyítja.

Hitelesítés és tokenkezelés

Távoli, védett MCP-szolgáltatásnál a választott implementációt az MCP hitelesítési és felhatalmazási követelményeihez kell illeszteni. Ellenőrizni kell a token érvényességét, kibocsátóját és célközönségét. Más szolgáltatásnak kiadott tokent nem szabad ellenőrizetlenül elfogadni és továbbadni.

Az olvasási pilot kapjon csak olvasási jogot. A hozzáférések legyenek visszavonhatók, a titkok ne jelenjenek meg a modellnek átadott tartalomban vagy a naplókban. Egy munkamenet-azonosító önmagában ne helyettesítse a hitelesítést.

Ezekhez konkrét támadási mintákat és védelmi elveket ad a hivatalos MCP biztonsági útmutató. A bevezetéskor a beszállítótól érdemes kérni egy rövid jogosultsági mátrixot és a hozzáférés visszavonásának bemutatását.

A promptinjekció üzleti kockázata

Egy termékleírás, dokumentum vagy külső válasz tartalmazhat olyan szöveget, amely az asszisztenst új utasítás követésére próbálja rávenni. Például azt állíthatja, hogy a termékadat ellenőrzéséhez ki kell exportálni az ügyféllistát. Ez adatból érkező támadás, nem hiteles felhasználói kérés.

A védelem nem merül ki egy figyelmeztető rendszerüzenetben. Az olvasási eszköz eleve ne kapjon ügyféladat-exportálási jogot, a szerver pedig ne hajtson végre tetszőleges műveletet a modell szöveges indoklására. A műveletek és paraméterek legyenek szűken meghatározva.

A tesztben helyezzetek támadó utasítást egy teszttermék leírásába, majd ellenőrizzétek, hogy sem titok, sem idegen szervezet adata nem szivárog ki. A próba eredményét és korlátait dokumentáljátok. Egyetlen sikeres teszt nem bizonyít minden támadással szembeni védelmet.

Foglalás: külön döntési és végrehajtási lépés

Egy időpont lefoglalása már állapotváltozás. Előbb egyértelművé kell tenni a szolgáltatást, helyszínt, dátumot, időzónát, árat és lemondási feltételt. A „csütörtök délután” nem elegendő végrehajtási paraméter.

A rendszer mutassa meg a konkrét foglalási összesítést, és kérjen ahhoz kötött jóváhagyást. Ha utána megváltozik az időpont vagy az ár, a korábbi jóváhagyás ne terjedjen ki automatikusan az új ajánlatra. A felhasználó döntése és a végrehajtott művelet legyen összekapcsolható.

A szabad időpontot közvetlenül a foglaláskor ismét ellenőrizni kell, és az ütközést a háttérrendszernek kell kizárnia. Az asszisztens korábbi válasza nem foglalja le a kapacitást. Ha közben más elvitte az időpontot, a rendszer térjen vissza az alternatívákhoz.

Ismétlés, bizonytalan állapot és visszavonás

Ha a kérés időtúllépéssel megszakad, attól a háttérrendszerben még létrejöhetett a foglalás. A vak újraküldés duplikációhoz vezethet. Egy üzleti művelethez ezért rendeljetek idempotenciakulcsot: ugyanannak a kérésnek az ismétlése ne hozzon létre új foglalást.

A kulcsot a felhasználóhoz és a művelet tartalmához kell kötni. Azonos kulccsal eltérő tartalmú kérés ne legyen észrevétlenül elfogadható. A feldolgozás eredményét tartósan kell tárolni, hogy hálózati hiba után lekérdezhető maradjon.

A lemondás külön, jogosultságot igénylő művelet. A felületen legyen látható, hogy visszavonható-e a foglalás, és milyen következménnyel. Olyan műveletet, amelynek nincs technikai visszavonása, nem szabad „bármikor visszavonhatóként” bemutatni; ilyenkor emberi rendezési folyamat szükséges.

Mit kell naplózni és átadni?

A napló kapcsolja össze a kérés azonosítóját, az ellenőrzött felhasználót, a meghívott eszközt, a jóváhagyást és az üzleti eredmény azonosítóját. A teljes beszélgetés vagy hozzáférési token tárolása rendszerint szükségtelen kockázatot teremt. A megőrzést, hozzáférést és törlést előre szabályozzátok.

Az átadás része legyen a leállítási lehetőség. Jogosultsági hiba vagy adatforrás-probléma esetén a felelős tudja letiltani az érintett eszközt anélkül, hogy az egész vállalkozás informatikáját le kellene állítani. A rendszer változásait verziózott tesztkészleten ellenőrizzétek.

A pilot üzleti értékelése mérje a helyes válaszokat, a hibás végrehajtásokat és az emberi beavatkozás szükségességét. Munkaidő-megtakarítást csak megfigyelt, összehasonlítható feladatok alapján számoljatok. A látványos bemutató nem bizonyítja a mindennapos üzemi megbízhatóságot.

A Neocart jelenlegi helyzete

A 2026. október 18-i termékadatlap szerint a Neocart MCP-szervere tervezett lehetőség, jelenleg nem elérhető szolgáltatás. Ez a cikk nem kínál hozzá kész havi csomagot, és a katalóguspélda sem működő termékbemutató.

Magyar KKV-ként akkor érdemes továbblépni, ha megnevezhető a feladat, az adatgazda és a hibáért felelős személy. A szűk olvasási pilot után külön döntés legyen minden olyan képesség, amely rendelést, foglalást vagy ügyféladatot módosít. A hosszú távú költségbe a jogosultságok, az integráció és a bizonyítékul szolgáló naplók fenntartása is beletartozik.