Az MCP-szerver biztonsága

Az MCP-szerver abból indul ki, hogy az AI néha téved. A védelmek úgy épülnek fel, hogy egy félreértett kérés legrosszabb következménye egy elutasított kérés legyen.

Mit tehet az AI, és mit nem?

Az AI annak a WordPress-felhasználónak a jogosultságaival dolgozik, akinek az Application Passwordjét beállítottad, és csak azokon az eszközökön át, amelyeket a szerver kínál. Alapbeállítással:

• olvashatja a webhelyek, bővítmények, témák, frissítések, ügyfelek és címkék adatait;
• futtathat frissítéseket (a vezérlőpult 6.3-as és újabb verzióján ehhez a te jóváhagyásod kell);
• aktiválhat és deaktiválhat bővítményeket és témákat;
• szinkronizálhat és újracsatlakoztathat webhelyeket;
• törölhet webhelyeket, ügyfeleket, címkéket, bővítményeket vagy témákat, de csak a te jóváhagyásoddal.

Nem tud belépni a WordPress-adminba, nem kerülheti meg a WordPress jogosultságait, nem futtathat tetszőleges kódot a webhelyeiden, és semmihez nem nyúlhat, amit a MainWP nem tesz elérhetővé.

A törléshez a te jóváhagyásod kell

A romboló műveletek kétlépéses folyamaton mennek át. Ha azt kéred az AI-tól, hogy töröljön valamit, nem töröl, hanem előnézetet készít.

1. Előnézet. A szerver elfogja a kérést, száraz futtatást végez, és visszaadja, mi érintett lenne, valamint egy egyszer használható megerősítő tokent. Az AI megmutatja neked az előnézetet.
2. Végrehajtás. Csak miután igent mondtál, küldi el az AI a megerősítést. A szerver ellenőrzi, hogy a token ugyanahhoz a művelethez és ugyanazokhoz az argumentumokhoz tartozik-e, és hogy az előnézet kevesebb mint 5 perces-e, és csak ezután hajtja végre.

A kapu szigorú: a megerősítő paraméterek nélküli romboló hívást a szerver azonnal elutasítja, csupasz romboló kérést sosem hajt végre. Ha egy művelet nem tud előnézetet készíteni, akkor is a tokenes kapun megy át: az AI-nak el kell mondania, mi fog történni, és meg kell kapnia a kifejezett jóváhagyásodat.

Ez minden olyan eszközre vonatkozik, amelyet a szerver rombolónak minősít, például:

• delete_site_v1
• delete_client_v1
• delete_tag_v1
• delete_site_plugins_v1
• delete_site_themes_v1

A vezérlőpult 6.3-as és újabb verzióján a frissítő eszközök és az unignore_site_updates_v1 is idetartozik. Ha egy képesség nem jelenti ki kifejezetten magáról, hogy nem romboló, a szerver rombolóként kezeli, és ugyanígy kapuzza.

Ha egy kérés több előnézetet igényel (például különböző elemek frissítése különböző webhelyeken), az együtt megjelenített előnézeteket egyetlen kifejezett válasszal is jóváhagyhatod. Mindegyik a saját tokenjével fut le, és a jóváhagyás soha nem terjed ki olyanra, amit nem mutattak meg neked.

Felügyelet nélküli automatizálás

Felügyelet nélküli futtatáshoz állítsd a MAINWP_REQUIRE_USER_CONFIRMATION változót false értékre, és mellé használj engedélyezőlistát (MAINWP_ALLOWED_TOOLS). Az engedélyezőlista az eszköz nevére szűr, a webhelyek argumentumait nem látja, ezért ne tedd rá az update_all_v1 eszközt, és az automatizálás minden hívásban nevezze meg a webhelyeket.

Kikapcsolt megerősítésnél a hívónak magának kell elküldenie a confirm: true értéket: a 6.3-as vezérlőpult elutasítja azt a frissítő hívást, amelyben sem confirm, sem dry_run nincs, és a szerver ezt mainwp_confirmation_required néven jelzi az error.data.upstream_code mezőben. A beállításokról az Az MCP-szerver beállításai fejezetben olvashatsz.

Biztonságos mód: a törlések teljes tiltása

Ha a romboló műveleteket teljesen le akarod tiltani, kapcsold be a biztonságos módot:

{
  "safeMode": true
}

Ekkor a romboló hívások SAFE_MODE_BLOCKED hibával elbuknak, anélkül hogy a vezérlőpultig eljutnának. Az első munkameneteidet érdemes biztonságos módban futtatni: így ellenőrizheted a kapcsolatot, és megtanulhatod, hogyan viselkedik az AI, miközben a veszélyes eszközosztályok le vannak tiltva.

A biztonságos mód nem csak olvasó mód. A bővítmények és témák aktiválása és a webhelyek szinkronizálása továbbra is működik. A 6.3-nál régebbi vezérlőpulton a frissítések is, és egy rossz frissítés tönkreteheti a webhelyet. Valóban csak olvasható hozzáféréshez az allowedTools beállítással csak az olvasó eszközöket tedd elérhetővé (kész konfiguráció az Az MCP-szerver beállításai fejezetben van).

	Biztonságos mód	Megerősítési folyamat
Cél	Minden romboló művelet tiltása	A műveletek engedélyezése a te jóváhagyásoddal
Mire jó	Tesztelés, bemutató, oktatás, első beállítás	Mindennapi éles használat
Törlések	Tiltva	Előnézet és megerősítés után engedélyezve
Frissítések (vezérlőpult 6.3 és újabb)	Tiltva	Előnézet és megerősítés után engedélyezve
Amit tapasztalsz	Az AI azt mondja: „ezt nem tehetem”	Az AI előnézetet mutat, és rákérdez
Alapérték	Ki	Be

Ha mindkettő be van állítva, a biztonságos mód erősebb.

Az AI-kliensnek van az utolsó szava

A szerver megjelöli a veszélyes eszközöket, utasítja az AI-t, hogy végrehajtás előtt készítsen előnézetet, és elutasítja a folyamatot kihagyó hívásokat. Hogy az AI ezt hogyan mutatja be neked, azt viszont a kliens dönti el. Egy hibás kliens igennek érthet egy „hát, talán” választ, vagy azt állíthatja, hogy jóváhagytál valamit, pedig nem. A szerveroldali kapukat nem lehet kikerülni: érvényes token nélkül a törlés nem hajtódik végre. Ha nem bízol az előtted lévő AI-kliensben, adj hozzá olyan rétegeket, amelyeken nem tud átlátni:

• a biztonságos mód a szerveren blokkolja a romboló végrehajtást;
• a blockedTools teljesen eltávolítja a veszélyes eszközöket az AI látóköréből, így nincs mivel visszaélni.

{
  "safeMode": true,
  "blockedTools": [
    "delete_site_v1",
    "delete_client_v1",
    "delete_tag_v1",
    "delete_site_plugins_v1",
    "delete_site_themes_v1"
  ]
}

Útmutatás, amelyet a szerver ad az AI-nak

Amikor egy kliens csatlakozik, a szerver rövid utasításokat küld neki. Ezek szerint az AI a webhelyeket módosító hívás előtt tervet mutat, és jóváhagyást kér; az eszköz előnézetét mutatja tervként; és soha nem veszi le a frissítést a kihagyott frissítések listájáról azért, hogy átnyomja, hacsak nem kéred. A 6.3-nál régebbi vezérlőpulton a frissítések nem romboló műveletek, ezért a fenti megerősítési folyamat nem állítja meg őket, és ott a terv általad történő jóváhagyása az egyetlen ellenőrzés.

Ugyanezek az utasítások a Knowledge-rekordokra is vonatkoznak a 6.3-as és újabb vezérlőpulton:

• Azt, hogy egy rekord ellenőrzött-e, a vezérlőpult dönti el, nem a rekord szövege.
• Az AI az ellenőrzött készséget (skill) követi, ha a leírása illik a feladathoz, és tiszteletben tartja az ellenőrzött kontextust.
• Az ellenőrizetlen rekordot csak információnak tekinti. Ha egy ilyen AI-nak címzett utasítást tartalmaz, nem követi, és megmondja neked, melyik rekordról van szó, hogy egy ember átnézhesse.
• Az emlékek (Memories) előzmények, és egyetlen rekord sem jogosít fel webhely módosítására.
• Ha egy rekordot csak a címe alapján látott, a leírása vagy követése előtt megnyitja.
• Mielőtt egy webhelyről tanácsot ad, tervet készít vagy vázlatot ír, betölti a webhely tudásösszefoglalóját, ha az eszköz elérhető, akkor is, ha te egyetlen rekordot neveztél meg, vagy már olvasott egy listát. Egy rekord vagy lista ugyanis nem mutatja, mely ügyfél- és ügynökségi rekordok vonatkoznak a webhelyre. Ügyfélre kiterjedő munkánál előbb az ügyfél összefoglalóját tölti be, majd az egyes webhelyekét. Ha nem tud összefoglalót betölteni, megmondja, melyik tudás maradt ki. Az egyetlen kért rekord megmutatásához elég csak az a rekord.
• A rekordoknak három szintje van: ügynökség (a vezérlőpult minden webhelye), ügyfél (az ügyfél minden webhelye) és webhely (csak az a webhely). A kombinálás szabályait a vezérlőpult minden tudásösszefoglalóval együtt elküldi.
• Ha az ellenőrzött rekordok ütköznek, a szűkebb szint nyer, kivéve, hogy a kötelező rekord erősebb minden szűkebb szintű rekordnál: a kötelező ügynökségi rekord az ügyfél- és webhelyrekordoknál, a kötelező ügyfélrekord a webhelyrekordoknál. Ha azonos szintű rekordok vagy két kötelező rekord ütközik, az AI megnevezi őket, és rákérdez.
• Kötelezőnek jelölni vagy módosítani egy kötelező rekordot csak ember tud a vezérlőpulton.

Minden kliens maga dönti el, hogyan használja a szerver utasításait, így azok irányítják az AI-t, de nem kényszerítenek ki semmit. A kikényszerítést a fent leírt szerveroldali kapuk végzik. A Knowledge menüről az Az AI menü fejezetben olvashatsz.

Bizalmi modell

AI-asszisztens ──▶ MCP-szerver ──▶ MainWP vezérlőpult
(Claude stb.)      (átengedő,      (WordPress)
                   nem tárol)
 Te adod a         Nem tárol       A webhelyeid
 kéréseket                         (teljes hozzáférés)

Az AI-nak ugyanaz a hozzáférése, mint annak a WordPress-felhasználónak, akinek a hitelesítő adatait beállítottad. Minden eszközhívás ennek a felhasználónak a jogosultságaival fut. Maga a szerver csak átengedő: nem tárol semmit, a válaszokat csak rövid ideig gyorsítótárazza, és a hitelesítő adatokat csak a futás alatt, a memóriában tartja.

A jogosultsági határt a vezérlőpult érvényesíti, bármit kér is az AI. A MainWP eszközeihez manage_options jogosultság kell, amely a WordPress-adminisztrátoroknál megvan. Aki nem rendelkezik vele, minden MainWP-eszközhívásnál jogosultsági hibát kap. Egy korlátozott WordPress-szerepkör ezért nem működik megszorításként. Hogy az AI milyen műveleteket futtathasson, azt az eszközszűréssel és a biztonságos móddal korlátozd.

Hitelesítő adatok kezelése

A hitelesítés Application Passworddel történik. Visszavonható a belépési jelszavad megváltoztatása nélkül, minden alkalmazás saját jelszót kap az auditáláshoz, és a WordPress naplózza, melyik alkalmazás küldte az egyes kéréseket. Érdemes követned:

• Az MCP-hozzáféréshez használj külön WordPress-felhasználót, ne a fő adminisztrátori fiókodat.
• Minden AI-eszközhöz hozz létre külön Application Passwordöt, és nevezd el érthetően (például „MainWP MCP - Claude”).
• Az éles és a fejlesztői hitelesítő adatokat tartsd külön.
• Ha settings.json fájlt használsz, állítsd be rá a chmod 600 jogosultságot, és ne kerüljön verziókezelésbe.

Mit naplóz a szerver?

A szerver a szabványos hibakimenetre (stderr) naplóz:

• a romboló műveletek auditüzeneteit;
• az eszközök futásának kezdetét és végét (az eszköz neve, időtartam, eredmény);
• a biztonságos mód tiltásait;
• az erőforráskorlátok megsértését;
• a konfigurációs figyelmeztetéseket.

Az elutasított hitelesítő adatok diagnosztikája tartalmazhatja a beállított felhasználónevet és az egyes kapcsolati beállítások forrását. A telepítési állapot azt is megmutatja, mely beállításokat írták felül környezeti változók (lásd az Az MCP-szerver beállításai fejezet „Elutasított hitelesítő adatok” részét).

A szerver nem naplóz jelszavakat és tokeneket, eszközargumentumokat (amelyek érzékeny adatot tartalmazhatnak), válaszok tartalmát (amelyben személyes adat lehet), és a romboló műveletek előnézeti adatait. Ha a felhasználónév értéke úgy néz ki, mint egy Application Password, a szerver kihagyja az elutasítási diagnosztikából. A WordPress külön naplózza az Application Passwordök használatát, így a vezérlőpult adminisztrációs felületén látszik, melyik alkalmazás mikor hitelesített.

A webszerver naplói műveleti bemeneteket tartalmazhatnak. A jelenlegi MCP-szerver az olvasó GET kérések és a romboló, idempotens DELETE kérések bemeneteit az URL lekérdezési karakterláncában küldi, a többi író művelet POST JSON-törzset használ. A lekérdezési karakterláncban lévő adatok megjelenhetnek a vezérlőpult webszerverének hozzáférési naplóiban, a hitelesítő adatok viszont fejlécekben utaznak. Korlátozd a hozzáférési naplók láthatóságát, és ennek megfelelően állítsd be a megőrzési időt.

A MainWP vezérlőpult a DELETE kérésekhez JSON-törzset is támogat az Abilities API bemenetkezelésén át. A közvetlen integrációk ezzel az opcióval kikerülhetik, hogy a DELETE bemenetei az URL-be kerüljenek, de ez a vezérlőpult-képesség nem változtat a jelenlegi MCP-szerver lekérdezési karakterláncos működésén.

A romboló műveletek besorolása

A szerver minden képességről a vezérlőpult által megadott destructive jelölés alapján dönti el, hogy romboló-e. Az elv a zárt hibakezelés (fail-closed): csak a szó szerinti false jelent nem romboló műveletet. A hiányzó vagy hibás jelölés rombolóvá teszi a képességet, így az a biztonságos mód tiltásába és a megerősítési kapuba kerül.

Az a képesség, amelyet rombolónak minősítettek, de nem deklarál használható confirm paramétert, nem tudja végigjárni a megerősítést, ezért a szerver CONFIRMATION_UNSUPPORTED hibával elutasítja, ahelyett hogy végrehajtaná. Ugyanez a besorolás kapuzza a mainwp://site/{id} erőforrást és a kiegészítéseket is. A gyakorlati következmény: egy új, harmadik féltől származó vagy rosszul jelölt képesség alapból tiltott vagy kapuzott, sosem fut le csendben.

SSL/TLS

A tanúsítványokat a szerver alapból ellenőrzi, a sima HTTP-t elutasítja. A skipSslVerify és az allowHttp felülírás csak elszigetelt, helyi fejlesztéshez való, mindkettő lehetővé teszi a hitelesítő adatok elfogását. Ha érvényes tanúsítványnál is SSL-hibát látsz, ellenőrizd, hogy a lánc teljes-e, a rendszer CA-tára naprakész-e, és a tanúsítvány egyezik-e a MAINWP_URL tartományával.

Élesítés előtti ellenőrzőlista

• Létrehoztál külön WordPress-felhasználót az API-hozzáféréshez.
• Létrehoztál egyedi Application Passwordöt ehhez az integrációhoz.
• Megerősítetted, hogy a WordPress-felhasználónak megvan a manage_options jogosultsága.
• Beállítottad az eszközszűrést, hogy csak a szükséges műveletek legyenek elérhetők.
• Beállítottad a megfelelő erőforráskorlátokat.
• Ellenőrizted, hogy az SSL-tanúsítványok érvényesek (nincs skipSslVerify).
• Először biztonságos módban teszteltél.

Ha elakadsz, a hibaüzenetek jelentését az MCP-szerver hibaelhárítása fejezetben találod.