V posledných dvoch častiach tejto série som pokryl ako sa Model Context Protocol mapuje na rozhranie API pre nákladnú dopravu a potom zlikvidovali nákladné servery MCP, ktoré boli dodané v roku 2026. Obe skončili rovnakou otvorenou otázkou, takže táto časť na ňu priamo odpovedá: keď agent dokáže rezervovať skutočnú prepravu, ako zabránite tomu, aby rezervoval nesprávnu vec pre nesprávnu osobu? Bezpečnosť je miesto, kde server MCP pre prepravu prestáva vyzerať ako vývojárska hračka a začína vyzerať ako systém, ktorý presúva peniaze a nákladné autá.
Prevádzkujem toto zo sídla trhoviska, ktoré vystavuje API, takže moja zaujatosť je praktická, nie akademická. Nižšie uvedené hrozby sú tie, ktoré v skutočnosti modelujeme pri rozhodovaní o tom, aký nástroj môže agent použiť bez ľudského dohľadu.
Prečo nákladovo efektívny server zvyšuje stávky
Bežný MCP server, ktorý číta váš kalendár, pri zlyhaní uniká informácie. Nákladný server, ktorý rezervuje prepravu, urobí niečo nákladnejšie. Zlé rozhodnutie môže poslať nákladné vozidlo na nesprávny dvor, zmeniť odberateľa na živú zásielku, zrušiť rezerváciu, na ktorú zákazník počíta, alebo stiahnuť nákladný list, ktorý nikdy nemal opustiť účet. Toto nie sú chyby v zmysle odhalenia údajov. Sú to peniaze a fyzický tovar pohybujúci sa na základe inštrukcie, ktorú nikto nenapísal.
Tento rozdiel celú problematiku inak zasádza. V prípade chatového asistenta je najhorším možným scenárom trápna odpoveď. V prípade prepravy je najhorším možným scenárom faktúra za prepravu a zásielka niekde, kde nemá byť. Takže otázka nikdy nie je „je tento server bezpečný“ v abstraktnej rovine. Je to „aké konkrétne akcie môže agent vykonať a koľko bude stáť každá z nich, ak sa niečo pokazí“.
Dva spôoby zlyhania, ktoré stoja za to, aby ste kvôli nim nespali
Najväčšie riziko MCP v roku 2026 sa zredukuje na dva vzory a náklad ich obidva zhoršuje.
Vpichovanie pokynov je starý webový problém v novom šate. Agent číta text z miesta, ktorému plne nedôveruje, z dodacieho listu, PDF, tela e-mailu, a tento text obsahuje pokyn, ktorý model vykoná. V preprave sa tento otrávený text dostáva cez legitímne kanály celý deň: do poznámky k rezervácii, colného opisu, aktualizácie stavu od prepravcu. Ak váš nástroj na rezervácie dôveruje čomukoľvek, čo mu model odovzdá, veta ukrytá v dodacom liste sa môže stať skutočným zrušením.
Otrevné nástroje je subtílnejší a špecifický pre MCP. Protokol umožňuje serveru opísať svoje nástroje a agent si prečíta tieto popisy, aby sa rozhodol, čo zavolať. Škodo- alebo kompromitovaný server môže napísať popis, ktorý ticho povie modelu, aby exfiltroval API kľúč alebo presmeroval zásielku, a používateľ tento text nikdy neuvidí. Spoločnosť Anthropic a nezávislí výskumníci strávili začiatok roka 2026 dokumentovaním variantov toho, a ponaučenie pre prepravu je priame: vrstva popisov je spustiteľná, takže s opisom nástroja tretej strany zaobchádzajte s rovnakým podozrením, s akým by ste zaobchádzali s kódom tretej strany.
Čítanie verzus zápis: čiara, ktorá by mala rozhodovať o vašom autentizačnom mechanizme
Najužitočnejšie bezpečnostné rozhodnutie, aké som kedy urobil, bolo prestať uvažovať o „serveri MCP“ ako o jednej hranici dôvery a rozdeliť ho podľa toho, čo každé nástroj robí so svetom.
Čo môže zostať otvorené
Vytváranie cenovej ponuky pre prepravnú trasu, zoznam prepravnej kapacity, výpočet odhadovaného času prepravy, vyhľadávanie kódu prístavu. Žiadny z týchto úkonov nič nezmení. Hlavným cieľom je umožniť agentovi skontaktovať sa s nimi s minimálnym úsilím, a tam spočíva každodenná hodnota. Čitateľ, ktorý chce porovnať tri trasy, by na to nemal potrebovať vytvárať token. V rámci serverov, ktoré boli rozobrané, tie serióznejšie nástroje na tvorbu cenových ponúk a referenčné nástroje udržiavali nízke trenie presne z tohto dôvodu.
Čo musí byť spoplatnené
Rezervácia, zrušenie, zmena príjemcu, úprava adresy, načítanie dokumentu, čokoľvek, čo sa týka faktúry. Každá z týchto akcií sa premietne do reálneho sveta a každá potrebuje overený, autorizovaný a auditovateľný hovor. Pravidlo, ktorým sa riadime, sa ľahko vyslovuje a ťažšie presadzuje: nástroj na čítanie môže byť otvorený, nástroj na zápis nikdy.
OAuth 2.1 a PKCE, nie dlho žijúci kľúč v konfiguračnom súbore
Špecifikácia autorizácie MCP sa nakoniec rozhodla pre OAuth 2.1 pre vzdialené servery a táto voľba má pre nákladnú dopravu skutočnú váhu. Statický API kľúč vložený do konfiguračného súboru je v poriadku pre samostatného vývojára, ktorý prevádzkuje server cez stdio na vlastnom stroji. Je to nesprávny model v momente, keď je server dostupný cez HTTP a agent koná v mene pomenovaného používateľa v rámci zdieľaného účtu.
Tri vlastnosti robia hlavnú prácu. Ohraničené tokeny znamenajú, že token vydaný na citovanie nemôže rezervovať. Krátkožijúce tokeny znamenajú, že uniknutý poverovací údaj vyprší sám od seba namiesto toho, aby žil navždy v logu. Odvolateľné tokeny znamenajú, že keď niečo vyzerá nesprávne, obmedzíte prístup v sekundách namiesto rotácie zdieľaného kľúča, od ktorého všetci závisia. OAuth 2.1 tiež vyžaduje PKCE v rámci toku autorizačného kódu, čím sa uzatvára medzera prieniku, ktorú staršie implementácie OAuth ponechali otvorené. Nič z toho nie je exotické. Je to rovnaké spevnenie, akým prešlo každé API pre platby, aplikované na moment, keď agent povie „rezervuj to“.
Tu je tvar hranice, ktorý vynucujeme, zapísaný ako tabuľka, ktorú by si prial každý prepravný server zverejňovať.
| Akcia agenta | Číta alebo zapisuje | Potrebujeme autorizáciu | Ak sa to pokazí |
| Získajte cenovú ponuku | Čítaj | Otvorený alebo základný kľúč | Zbytočný hovor, žiadna škoda |
| Skontrolujte kapacitu, tranzit, sledovanie | Čítaj | Otvorený alebo základný kľúč | Zostaňte pri najhoršej odpovedi |
| Rezervovať zásielku | Napíš | Scoping OAuth token, potvrdzovací krok | Skutočné náklady, skutočný kamión |
| Zrušiť alebo znova rezervovať | Napíš | Scoped token, kľúč na idempotenciu | Stratené miesto, pokuta |
| Zmeniť príjemcu alebo adresu | Napíš | Scoped token, potvrdenie od používateľa | Nesprávne doručenie, podvod |
| Vytiahniť nákladný list alebo faktúru | Čítať citlivé | Rozsahový token, kontrola na dokument | Únik dát a dokumentov |
Vzor v tej tabuľke je skutočné rozhodnutie o produkte. Čítania sú vľavo a zostávajú lacné. Zápisy sú vpravo a zarábajú si svoju trenicu.
Problém odhalenej inštancie
Prekvapivé množstvo rizika MCP vôbec nie je dômyselné. Je to server, ktorý mal bežať lokálne, ale bol sprístupnený na otvorený internet bez autentifikácie, pretože jeho odoslanie v takomto stave bolo jednoduchšie. Protokol podporuje dva transporty. Server stdio beží ako lokálny proces, ktorý klient spustí, čím zostáva na vašom stroji a mimo siete. Hostovaný HTTP server je dosiahnuteľný čímkoľvek, čo nájde jeho URL.
Pre server s iba na čítanie je vystavenie HTTP väčšinou neškodné. Pre server s rezervačnými nástrojmi je to celá záležitosť. Ak sú vaše zapisovacie nástroje dostupné cez verejné HTTP, autentizácia nie je funkcia, ktorú pridáte neskôr, je to to, čo stojí medzi cudzím človekom a vašim radom pre odosielanie úloh. Naše pravidlo je, že rezervačné a dokumentové nástroje sa nikdy neslúžia cez neautentizovaný HTTP koncový bod, bodka. V prípade pochybností by server so schopnosťou zapisovať mal predvolene používať stdio a lokálne spustenie a iba by povýšil na hostované HTTP, akonáhle je implementovaný vyššie uvedený OAuth tok.
Obrana vrstvy deskripcie proti otráveniu nástrojmi
Pretože opisy nástrojov riadia model, zaslúžia si rovnaké kontroly ako kód, ktorý nasadzujete. Tri návyky pokrývajú väčšinu vystavenia.
- Pripnite a zhodnoťte servery, ku ktorým sa pripájate. Agent pripojený ku kurátorskej sade známych serverov predstavuje menší cieľ ako ten, ktorý inštaluje čokoľvek, čo registratúra ponúka. S novým serverom zaobchádzajte ako s novou závislosťou, pretože to aj je.
- Pri každom zápise si ponechajte človeka. Potvrdzovací krok pred rezerváciou, zrušením alebo zmenou príjemcu premení tichý vložený pokyn na viditeľnú požiadavku, ktorú môže používateľ zamietnuť. Je to najlacnejšia kontrola s najvyššou návratnosťou.
- Overte na API, nie v príkaze. Server by mal každý prijatý parameter znova skontrolovať oproti reálnym povoleniam účtu a reálnemu stavu rezervácie, namiesto toho, aby dôveroval tomu, že model zostavil rozumný hovor. Model navrhuje, API rozhoduje.
Čo musí vynucovať trhoviskový server, aby jeden prepravca mohol preskočiť
Server s jedným operátorom koná vždy len vo svojej vlastnej sieti, takže jeho dosah je jeden operátor. Trhoviskový server cituje a rezervuje naprieč viacerými operátormi v mene viacerých používateľov, čo mení úlohu zabezpečenia dvoma spôsobmi.
Po prvé, rozsah musí byť na používateľa a na operátora, nie na server. Token, ktorý umožní agentovi rezerváciu u jedného operátora, by nemal ticho dosiahnuť iného a agent jedného zákazníka nesmie vidieť dokumenty iného zákazníka. Po druhé, auditný záznam je dôležitejší, pretože keď agent rezervuje cez trhovisko, musíte odpovedať „ktorý používateľ, ktorý token, ktorý operátor, kedy“ pre každé písanie. Tento záznam považujeme za súčasť produktu, nie ako dodatočný nápad, pretože nám umožňuje zrušiť platnosť iba pre konkrétny rozsah, namiesto toho, aby sme zastavili všetko pre všetkých.
Praktický kontrolný zoznam pred zverejnením rezervácie
- Rozdeľte nástroje podľa čítania a zápisu a zapíšte si rozdelenie na miesto, kde ho uvidí agent aj váš tím.
- Nechajte nástroje na citovanie a odkazovanie s nízkym trením, aby denná hodnota prežila.
- Každé písanie presuňte za rámcovo definovaný, krátkodobý, odvolateľný OAuth 2.1 token s PKCE.
- Vyžadovať potvrdzovací krok pri rezervácii, zrušení, zmene príjemcu a adresy.
- Znovu overte každý parameter v API voči skutočným povoleniam a skutočnému stavu zásielky.
- Nikdy neslúžte nástroje na zapisovanie cez neoverené HTTP a predvolene nastavte servery s možnosťou zápisu na lokálne stdio.
- Pripnite servery, ku ktorým sa váš agent pripája, a kontrolujte nové rovnako ako nový kód.
- Zaznamenávajte každý zápis s používateľom, tokenom, nosičom a časom a nacvičte si odvolanie skôr, než ho budete potrebovať.
Nič z toho nie je jedinečné pre umelú inteligenciu. Sú to kontroly, ktoré už používajú nákladná doprava a platby, zamerané na nové miesto, kde môže vzniknúť inštrukcia. Agent je nový volajúci, nie nový súbor pravidiel.
Často kladené otázky
Je bezpečné nechať AI agenta, aby si rezervoval prepravu?
Áno, keď rezervácia prebehne za overeným a autorizovaným volaním s krokom potvrdenia a keď server skontroluje každý parameter namiesto dôvery v model. Nebezpečná verzia je otvorený nástroj na zapisovanie bez ľudského dohľadu. Považujte rezervácie za akúkoľvek inú akciu presunu peňazí a agent sa stane ďalším overeným volajúcim.
Prečo používať OAuth 2.1 namiesto jednoduchého API kľúča?
Statický kľúč má tendenciu byť dlhodobý, široko rozsahový a ťažko sa odvoláva bez narušenia všetkých, ktorí ho zdieľajú. OAuth 2.1 vám poskytuje tokeny s definovaným rozsahom platnosti, krátkodobé a odvolateľné a vyžaduje PKCE v rámci autorizačného toku. Pre lokálny stdio server je kľúč prijateľný, ale čokoľvek dostupné cez HTTP, čo môže zapisovať, by malo používať model OAuth.
Čo je to "tool poisoning" v MCP?
Otrávenie nástroja nastáva, keď popis nástroja servera, ktorý agent číta, aby sa rozhodol, čo zavolať, obsahuje skryté pokyny, ktoré model navádzajú k škodlivým akciám, ako je únik kľúča alebo presmerovanie zásielky. Keďže popis ovplyvňuje správanie, bránite ho rovnako, ako bránite kód: pripínajte dôveryhodné servery, majte pri zápisoch človeka a validujte na úrovni API.
Mal by nákladný MCP server bežať ako stdio alebo ako hostovaný HTTP?
Server s obmedzeným prístupom, slúžiaci iba na čítanie, je v poriadku aj cez hostovaný HTTP. Server s nástrojmi na rezervácie alebo dokumenty by mal predvolene používať lokálne stdio a prejsť na hostovaný HTTP až po implementácii OAuth scoped, pretože otvorený zapisovací bod bez autentizácie je dosiahnuteľný kýmkoľvek, kto pozná URL.
Tým sa uzatvára cyklus, ktorý táto séria otvorila. Ak ste nečítali predchádzajúce časti, protokolárny úvod vysvetľuje, ako sa API pre náklad stáva súborom nástrojov, a zrušiť ukazuje, kde tieto hranice v praxi nakreslili odoslané servery.