A sorozat utolsó két részében az Hogyan képezhető le a Modellkontext Protokoll egy teherfuvarozási API-ra-et, majd az lebontotta a teherszállító MCP szervereket, amelyeket 2026-ban szállítottak-et tárgyaltam. Mindkettő ugyanazzal a nyitott kérdéssel zárult, így ez a rész közvetlenül erre válaszol: ha egy ügynök képes valódi fuvart foglalni, hogyan lehet megakadályozni, hogy rossz dolgot foglaljon a rossz embernek? A biztonság az a pont, ahol egy fuvarozási MCP szerver felhagy a fejlesztői játékkal, és elkezd úgy kinézni, mint egy pénzt és teherautókat mozgató rendszer.
Ezt egy olyan piactérről futtatom, amely egy API-t tesz elérhetővé, így az elfogultságom gyakorlatias, nem tudományos. Az alábbi fenyegetések azok, amelyeket ténylegesen modellezünk, amikor eldöntjük, hogy egy ügynök melyik eszközt hívhatja meg emberi felügyelet nélkül.
Miért emeli a tétet egy teherszállító szerver
Egy általános MCP szerver, amely olvassa a naptáradat, adatokat szivárogtat, amikor hibát jelez. Egy teherszállítási szerver, amely egy rakományt foglal le, valami költségesebbet tesz. Egy rossz hívás rossz udvarba küldhet egy teherautót, megváltoztathatja a címzettet egy élő szállításnál, törölhet egy foglalást, amire egy ügyfél számít, vagy lehívhat egy fuvarlevelet, amelynek soha nem lett volna szabad elhagynia a számlát. Ezek nem adatközzétételi hibák. Ezek pénz és fizikai javak mozgásai egy olyan utasításra, amelyet senki sem gépelt be.
Ez a különbség teljesen átkeretezi a problémát. Egy csevegőasszisztens esetében a legrosszabb forgatókönyv egy kínos válasz. A fuvarozásnál a legrosszabb forgatókönyvhöz fuvárszámla kapcsolódik, és egy szállítmány kerül oda, ahová nem kellett volna. Tehát a kérdés soha nem az, hogy "biztonságos-e ez a szerver" elvont fogalomként. Hanem az, hogy "milyen konkrét lépéseket tehet egy ügynök, és mennyibe kerül minden egyes lépés, ha rosszul sül el."
A két hibamód, amely miatt érdemes aggódni
A jelenlegi MCP-kockázat 2026-ra két mintázatra redukálódik, és a fuvarköltség mindkettőt rontja.
A **prompt injection** a régi webes probléma új ruhában. Egy ügynök olyan szöveget olvas el egy olyan helyről, amit nem tud teljesen irányítani, egy szállítási jegyzéket, egy PDF-et, egy e-mail törzsét, és ez a szöveg tartalmaz egy utasítást, amit a modell végrehajt. A fuvarozásban a mérgezett szöveg egész nap legális csatornákon keresztül érkezik: foglalási megjegyzés, vámleírás, a fuvarozó állapotfrissítése. Ha a foglalási eszközöd megbízik bármiben, amit a modell átad neked, a szállítási jegyzetbe rejtett mondat valós törléssé válhat.
A **szerszámmérgezés** finomabb és specifikusabb az MCP-re. A protokoll lehetővé teszi a szerver számára, hogy leírja a saját szerszámait, és az ügynök elolvassa ezeket a leírásokat, hogy eldöntse, mit hívjon. Egy rosszindulatú vagy veszélyeztetett szerver olyan leírást írhat, amely csendben arra utasítja a modellt, hogy lopjon el egy API kulcsot vagy irányítson át egy szállítmányt, és a felhasználó soha nem látja ezt a szöveget. Az Anthropic és független kutatók 2026 elejét ennek változatai dokumentálásával töltötték, és a fuvarozásra vonatkozó tanulság egyértelmű: a leírás réteg végrehajtható, ezért egy harmadik féltől származó eszközleírást ugyanazzal a gyanakvással kell kezelni, mint a harmadik féltől származó kódot.
Olvasás vagy írás: a határ, ami eldönti a hitelesítésedet
A leginkább hasznos biztonsági döntésem az volt, hogy felhagytam az "MCP szerver" egységes bizalmi határként való kezelésével, és a dolgoknak megfelelően, az egyes eszközök funkciói alapján különválasztottam.
Mi maradhat nyitva
Egy sáv megidézése, kapacitás listázása, szállítási becslés kiszámítása, kikötői kód lekérdezése. Ezek egyike sem változtat semmin. A lényeg az, hogy egy ügynök minimális vagy zökkenőmentes akadályok árán érje el őket, és ez jelenti a napi értéket. Aki három útvonalat szeretne összehasonlítani, annak nem kell ezért tokent keltenie. A szétszerelés szerverei között a komolyabbak pontosan ezen okból tartották alacsony súrlódásúvá az árajánlatkérésre és a referencia eszközöket.
Mi az, amit le kell zárni
Foglalás, törlés, címzett módosítása, cím szerkesztése, dokumentum lehívása, bármi, ami számlát érint. Mindegyik valós világba ír, és mindegyik mögött hitelesített, engedélyezett, ellenőrizhető hívásra van szükség. Az általunk követett szabály kimondani egyszerű, betartani nehéz: egy olvasási eszköz lehet nyitott, egy írási eszköz soha.
OAuth 2.1 és PKCE, nem egy hosszú életű kulcs egy konfigurációs fájlban
Az MCP engedélyezési specifikáció az OAuth 2.1-re esett a távoli szerverek esetében, és ez a választás komoly súllyal bír a fuvarozásban. Egy statikus API-kulcs, amelyet egy konfigurációs fájlba másolnak be, rendben van egy egyéni fejlesztő számára, aki a saját gépén stdio-n futtat egy szervert. Ez a helytelen modell attól a perctől fogva, hogy a szerver HTTP-n keresztül elérhető, és egy ügynök egy megosztott fiókban lévő, megnevezett felhasználó nevében jár el.
Három tulajdonság végzi a munka oroszlánrészét. A **hatókörrel rendelkező** tokenek azt jelentik, hogy egy foglalásra szánt token nem használható foglaláshoz. A **rövid életidejű** tokenek azt jelentik, hogy egy kiszivárgott hitelesítő adat önmagától lejár, ahelyett, hogy örökre megmaradna egy naplóban. A **visszavonható** tokenek azt jelentik, hogy amikor valami gyanúsan néz ki, másodpercek alatt megvonhatja a hozzáférést, ahelyett, hogy egy mindenki által használt megosztott kulcsot kellene elforgatnia. Az OAuth 2.1 továbbá megköveteli a PKCE használatát az engedélyezési kódot használó folyamatban, ami bezárja az átirányítási rést, amit a régebbi OAuth-telepítések nyitva hagytak. Ezek egyike sem egzotikus. Ez ugyanaz az erősítés, amin bármelyik fizetési API keresztülment, és alkalmazva arra a pillanatra, amikor egy ügynök azt mondja: „foglalja le”.
Itt van a kényszerített határunk alakja, amelyet úgy írok le, ahogy minden teherszállító szervernek közzé kellene tennie.
| Ügynök akciója | **Olvas vagy ír** | **Szükséges hitelesítés** | Ha elromlik |
| Árajánlat kérése | Olvas | Nyitott vagy alap kulcs | Elpazarolt hívás, nem okozott kárt |
| Ellenőrizze kapacitást, tranzitot, nyomkövetést | Olvas | Nyitott vagy alap kulcs | Legrosszabb esetben is elavult válasz |
| Szállítmány foglalása | Írj | Scoped OAuth token, visszaigazolási lépés | Valós ár, valódi teherautó |
| Lemondás vagy átfoglalás | Írj | Hatókörhöz kötött token, idempotencia kulcs | Elveszett foglalás, büntetés |
| Kedvezményezett vagy cím módosítása | Írj | Hatókörű token, emberi megerősítés | Hibás kézbesítés, csalás |
| Fuvibizonylatot vagy számlát lekérni | Érzékeny olvasás | Hatókörhöz kötött token, dokumentumonkénti ellenőrzés | Adat- és dokumentumszivárgás |
A táblázat mintázata a tényleges termék-döntés. Az olvasások balra esnek és olcsók maradnak. Az írások jobbra esnek és megkeresik a súrlódásukat.
A "kitett példány" (exposed-instance) probléma
Az MCP-kockázatok meglepően nagy része egyáltalán nem okos. Ez egy olyan szerver, amelyet eredetileg helyben kellett volna futtatni, de hitelesítés nélkül az internetre tették, mert így volt a legegyszerűbb a szállítása. A protokoll két szállítási módot támogat. Az egyik az stdio szerver, amely helyi folyamatként fut, és az ügyfél indítja el, így az a gépeden marad, nem kerül a hálózatra. A másik a „hosted HTTP server”, amely bárhonnan elérhető, ahonnan megtalálható az URL-je.
Egy csak olvasható kiszolgáló esetén az HTTP-n keresztüli elérés nagyrészt ártalmatlan. Egy foglalási eszközökkel rendelkező kiszolgáló esetén ez a minden. Ha az író eszközeid nyilvános HTTP-n keresztül elérhetők, az autentikáció nem egy olyan funkció, amit később hozzáadsz, ez az, ami az idegen és a diszpécser várólista között áll. A szabályunk az, hogy a foglalási és dokumentum eszközöket soha nem szolgáljuk ki nem hitelesített HTTP végponton, pont. Kétség esetén az írásra képes kiszolgálónak alapértelmezetten a stdio-t és a helyi indítást kell használnia, és csak akkor szabadulhat fel a HTTP-n való futtatásra, ha a fent említett OAuth folyamat be van vezetve.
A leírási réteg védelme a nemkívánatos szerekkel szemben
Mivel az eszközk leírások irányítják a modellt, ugyanazokat a vezérlőket érdemlik, mint amit a futtatott kódnál alkalmaz. Három szokás lefedi a legtöbb kitettséget.
- **Rögzítse és tekintse át a csatlakoztatott szervereket.** Egy gondosan kiválasztott ismert szerverekre beállított ügynök kisebb célpont, mint egy olyan, amelyik bármit telepít, amit egy nyilvántartás kínál. Kezeljen egy új szervert úgy, mint egy új függőséget, mert az is.
- **Minden íráshoz tartsunk egy embert az írásnál.** A címzett foglalás, törlés vagy módosítás előtti megerősítési lépés a csendben bevitt utasítást látható kéréssé alakítja, amit a felhasználó megtagadhat. Ez a legolcsóbb ellenőrzés a legmagasabb megtérüléssel.
- **Validálás az API-n, nem a promptban.** A szervernek minden fogadott paramétert újra ellenőriznie kell a fiók valódi engedélyeihez és a foglalás valódi állapotához képest, ahelyett, hogy megbízná abban, hogy a modell értelmes hívást állított össze. A modell javasol, az API dönt.
Mit kell betartania egy piactéri kiszolgálónak ahhoz, hogy egyetlen fuvarozó kihagyhasson
Egy egysingle-carrier szerver csak a saját hálózatán belül működik, így a hatókörsugara egy operátorra terjed ki. Egy piactéri szerver viszont sok operátornál és sok felhasználó nevében idéz és foglal, ami két szempontból változtatja meg a biztonsági feladatot.
Először is, a hatókör felhasználónként és szolgáltatónként értendő, nem szerverenként. Egy token, amely lehetővé teszi egy ügynök számára, hogy egy szolgáltatónál foglaljon, nem juthat el némán egy másikhoz, és egy ügyfél ügynöke soha nem láthat más ügyfél dokumentumait. Másodszor, az audit trail fontosabb, mert amikor egy ügynök egy piactéren foglal, minden írányra válaszolnia kell arra, hogy "melyik felhasználó, melyik token, melyik szolgáltató, mikor". Ezt a naplót a termék részének tekintjük, nem mellékesnek, mivel ez teszi lehetővé számunkra a szűk körű visszavonást ahelyett, hogy mindenkit lekapcsolnánk.
Praktikus ellenőrzőlista a foglalás közzététele előtt
- Ossza szét az eszközöket olvasási és írási joggal, és írja le a felosztást ott, ahol az ügynök és a csapata is láthatja.
- Tartsa az idézési és hivatkozási eszközöket alacsony súrlódásúként, hogy a napi érték fennmaradjon.
- Minden írást egy hatókörrel rendelkező, rövid életidejű, visszavonható OAuth 2.1 token mögé helyezzen PKCE-vel.
- Kötelező megerősítési lépés a foglalás, a törlés, a címzett és a cím módosítása esetén.
- Validáld újra az összes API paramétert a valós jogosultságokkal és a valós szállítási állapottal szemben.
- Soha ne szolgáljon íróeszközöket hitelesítetlen HTTP-n keresztül, és alapértelmezés szerint állítsa a mentésre alkalmas szervereket helyi stdio-ra.
- Rögzítse a kiszolgálókat, amelyekhez az ügynöke csatlakozik, és tekintse át az újakat, mint az új kódot.
- Naplózza minden írást felhasználóval, tokennal, vivővel és idővel, és gyakorolja az elvonást, mielőtt szüksége lenne rá.
Egyik sem egyedi a mesterséges intelligencia számára. Ezek azok a vezérlők, amelyeket a fuvarozás és a fizetések már használnak, és amelyeket arra az új helyre irányítanak, ahonnan az utasítás eredhet. Az ügynök egy új hívó, nem pedig egy új szabályrendszer.
Gyakran ismételt kérdések
Biztonságos, ha egyáltalán megbízunk egy MI ügynököt a teherszállítás foglalásával?
Igen, amikor a foglalás egy hitelesített és felhatalmazott hívás mögött zajlik, egy megerősítési lépéssel, és amikor a szerver minden paramétert ellenőriz, ahelyett, hogy megbízna a modellben. A nem biztonságos verzió egy nyitott író eszköz emberi beavatkozás nélkül. Kezelje a foglalást, mint minden más pénzmozgató műveletet, és az ügynök egy újabb hitelesített hívó lesz.
Miért használjunk OAuth 2.1-et egyszerű API kulcs helyett?
A statikus kulcs általában hosszú életre szól, széles körben használható és nehezen vonható vissza anélkül, hogy megzavarná az összes megosztót. Az OAuth 2.1 hatókörrel rendelkező, rövid életidejű, visszavonható tokeneket biztosít, és PKCE-t igényel az engedélyezési folyamatban. Helyi stdio szerver esetén egy kulcs elfogadható, de bármi, ami HTTP-n keresztül elérhető és írni tud, az OAuth modellt használja.
Mi a szerszám-mérgezés az MCP-ben?
A "tool poisoning" az, amikor egy szerver eszköztárának leírása, amelyet az ügynök olvas a hívás eldöntéséhez, rejtett utasításokat tartalmaz, amelyek káros cselekedetek felé terelik a modellt, például bizalmas kulcsok kiszivárogtatása vagy kiszállítások átirányítása. Mivel a leírás befolyásolja a viselkedést, úgy védd, ahogy a kódot: rögzíts megbízható szervereket, tartsd emberi felügyelet alatt a módosításokat, és érvényesítsd azokat az API-n keresztül.
Egy teher-MCP szervernek stdio-ként vagy hosztolt HTTP-ként kell futnia?
Egy csak olvasható segítőszerver rendben van a hosztolt HTTP-n keresztül. A foglalási vagy dokumentumeszközöket tartalmazó szervernek alapértelmezetten helyi stdio-t kell használnia, és csak akkor lépjen át hosztolt HTTP-re, ha hatókörrel rendelkező OAuth már be van állítva, mert egy autentikáció nélküli, írási végpont bárki által elérhető, aki megtalálja az URL-t.
Ez lezárja az imént megnyílt sorozatot. Ha nem olvastad korábban, az protokoll alapozó elmagyarázza, hogyan lesz egy fuvarkonténer-API egy eszközkészlet, az bontsa le pedig bemutatja, hol húzták meg gyakorlatban ezeket a határokat a kiszállított szerverek.