V posledních dvou částech této série jsem se věnoval jak se Model Context Protocol mapuje na rozhraní pro nákladní dopravu a poté zbourají nákladní servery MCP, které byly dodány v roce 2026. Obě skončily stejnou otevřenou otázkou, na kterou tato část přímo odpovídá: jakmile agent dokáže rezervovat skutečnou přepravu, jak mu zabráníte v rezervaci nesprávné věci pro nesprávnou osobu? Bezpečnost je místo, kde server MCP pro přepravu přestává vypadat jako hračka pro vývojáře a začíná vypadat jako systém, který přesouvá peníze a nákladní automobily.
Spouštím to ze sídla tržiště, které vystavuje API, takže moje zaujetí je spíše praktické než akademické. Níže uvedená rizika jsou ta, která skutečně modelujeme, když rozhodujeme, jaký nástroj může agent volat bez lidského dohledu.
Proč nákladný server zvyšuje sázky
Obecný server MCP, který čte váš kalendář, při selhání uniká informace. Nákladní server, který rezervuje zásilku, udělá něco nákladnějšího. Špatný příkaz může poslat kamion na špatné nádvoří, změnit příjemce u živé zásilky, zrušit rezervaci, na kterou spoléhá zákazník, nebo stáhnout konosament, který nikdy neměl opustit účet. To nejsou chyby v oblasti expozice dat. Jsou to peníze a fyzické zboží pohybující se na základě instrukce, kterou nikdo nenapsal.
Tento rozdíl přerámcuje celý problém. S chatovacím asistentem je nejhorším scénářem trapná odpověď. V případě nákladu je nejhorším scénářem faktura za přepravu a zásilka někde, kde nemá být. Otázka tedy nikdy nezní "je tento server bezpečný" abstraktně. Zní: "jaké konkrétní akce může agent provést a kolik stojí, pokud se něco pokazí."
Dva způsoby selhání, kvůli kterým se vyplatí proplakat noc
Většina rizik MCP v roce 2026 se snižuje na dva vzorce a náklad obě zhoršuje.
Prompt injection je starý webový problém v novém kabátě. Agent čte text z místa, které plně nekontroluje, z dodacího listu, PDF, těla e-mailu, a tento text obsahuje instrukci, kterou se model řídí. V oblasti dopravy se toxický text dostává legálními kanály po celý den: v komentáři k rezervaci, popisu celního odbavení, aktualizaci stavu od dopravce. Pokud váš rezervační nástroj důvěřuje čemukoli, co mu model předá, věta skrytá v dodacím listě se může stát skutečným zrušením.
**Otrava nástrojů** je subtilnější a specifická pro MCP. Protokol umožňuje serveru popsat vlastní nástroje a agent si tyto popisy přečte, aby rozhodl, co zavolat. Zlomyslný nebo kompromitovaný server může napsat popis, který modelu potichu nařídí exfiltrovat API klíč nebo přesměrovat zásilku, aniž by uživatel tento text vůbec viděl. Společnost Anthropic a nezávislí výzkumníci strávili začátek roku 2026 dokumentováním variant této techniky a pro přepravu z toho plyne jasná lekce: vrstva popisů je spustitelná, takže s popisem nástroje třetí strany nakládejte se stejnou podezíravostí, s jakou byste nakládali s kódem třetí strany.
Čtení versus zápis: hranice, která by měla rozhodnout o vaší autorizaci
Jediné nejužitečnější bezpečnostní rozhodnutí, které jsem udělal, bylo přestat uvažovat o „serveru MCP“ jako o jedné hranici důvěry a rozdělit ji podle toho, co který nástroj dělá se světem.
Co může zůstat otevřené
Cenová nabídka pro trasu, uvedení kapacity, výpočet odhadovaného času tranzitu, vyhledání kódu přístavu. Nic z toho nic nemění. Hlavním smyslem je umožnit agentovi je kontaktovat s malým nebo žádným třením a právě v tom spočívá denní hodnota. Čtenář, který chce porovnat tři trasy, by k tomu nemusel razit token. Napříč servery v při demontáži, ty seriózní udržovaly cenové nabídky a referenční nástroje s nízkým třením přesně z tohoto důvodu.
Co musí být řízeno
Rezervace, zrušení, změna příjemce, úprava adresy, stažení dokumentu, cokoliv, co se dotkne faktury. Každá z těchto akcí se projeví ve skutečném světě a každá vyžaduje ověřený, autorizovaný a auditovatelný volání. Pravidlo, kterým se řídíme, se snadno formuluje a hůře dodržuje: čtecí nástroj může být otevřený, zapisovací nástroj nikdy.
OAuth 2.1 a PKCE, žádný dlouhodobě platný klíč v konfiguračním souboru
Specifikace autorizace MCP se ustálila na OAuth 2.1 pro vzdálené servery a tato volba má pro přepravu skutečnou váhu. Statický API klíč vložený do konfiguračního souboru je v pořádku pro sólo vývojáře, který spouští server přes stdio na svém vlastním stroji. Je to špatný model v okamžiku, kdy je server dosažitelný přes HTTP a agent jedná jménem pojmenovaného uživatele v rámci sdíleného účtu.
Tři vlastnosti nesou hlavní tíhu. Omezené tokeny znamenají, že token vydaný pro citaci nelze použít k rezervaci. Krátkodobé tokeny znamenají, že uniklá přihlašovací údaje vyprší samy, místo aby žily navždy v logu. Odvolatelné tokeny znamenají, že když se něco pokazí, omezíte přístup během několika sekund, místo abyste museli měnit sdílený klíč, na kterém jsou všichni závislí. OAuth 2.1 také vyžaduje PKCE v toku autorizačního kódu, což uzavírá mezeru v zachycení, kterou starší nasazení OAuth ponechala otevřenou. Nic z toho není exotické. Je to stejné posílení, kterým prošlo jakékoli platební API, aplikované na okamžik, kdy agent řekne „rezervujte to“.
Zde je tvar hranice, kterou vynucujeme, zapsaný jako tabulka, kterou si přeji, aby každý server pro přepravu zboží publikoval.
| Akce agenta | Čte nebo píše | Autorizace, kterou vyžadujeme | Pokud se to pokazí |
| Získat cenovou nabídku | Číst | Otevřený nebo základní klíč | Zbytečné volání, žádná škoda |
| Zkontrolujte kapacitu, tranzit, sledování | Číst | Otevřený nebo základní klíč | Navždy odpověď v nejhorším případě |
| Objednat přepravu | Napište | Omezený token OAuth, krok potvrzení | Skutečné náklady, skutečný vůz |
| Zrušit nebo přesunout | Napište | Token s rozsahem, klíč pro zaručení jedinečnosti požadavku | Ztracený slot, pokuta |
| Změnit příjemce nebo adresu | Napište | Tokem s rozsahem, lidské potvrzení | Zásilka na špatnou adresu, podvod |
| Vyžádejte si nákladní list nebo fakturu | Přečíst citlivé | Rozsahový token, kontrola na dokument | únik dat a dokumentů |
Vzor v této tabulce je skutečné rozhodnutí o produktu. Čtení sedí vlevo a zůstává levné. Zápisy sedí vpravo a vydělávají si na svém tření.
Problém vystavené instance
Překvapivé množství rizika MCP není vůbec chytré. Je to server, který měl běžet lokálně, vystavený na otevřený internet bez autentizace, protože jeho dodání takto bylo jednodušší. Protokol podporuje dva transporty. Stdio server běží jako lokální proces, který spustí klient, čímž zůstává na vašem stroji a mimo síť. Hostovaný HTTP server je dosažitelný čímkoli, co najde jeho URL.
Pro server s pouze čtecím oprávněním je HTTP expozice většinou neškodná. Pro server s rezervačními nástroji je to celá záležitost. Pokud jsou vaše zápisové nástroje dostupné přes veřejné HTTP, autentizace není funkce, kterou přidáte později, je to to, co stojí mezi cizím člověkem a vaší frontou dispečinku. Naše pravidlo je, že rezervační a dokumentační nástroje nikdy neběží přes neautentizovaný HTTP koncový bod, tečka. V případě pochybností by server se zápisovými schopnostmi měl standardně používat stdio a lokální spuštění a k hostovanému HTTP přejít až po implementaci výše uvedeného OAuth toku.
Obrana vrstvy popisu proti kontaminaci nástrojů
Protože popisy nástrojů řídí model, zaslouží si stejné ovládací prvky jako kód, který nasazujete. Tři návyky pokrývají většinu vystavení.
- **Připněte a zkontrolujte servery, ke kterým se připojujete.** Agent napojený na vybranou sadu známých serverů představuje menší cíl než takový, který instaluje cokoliv, co registr nabízí. S novým serverem zacházejte jako s novou závislostí, protože jí je.
- **Na každé zapsání si ponechte člověka.** Potvrzovací krok před rezervací, zrušením nebo změnou příjemce změní tichou vloženou instrukci na viditelnou žádost, kterou může uživatel odmítnout. Je to nejlevnější kontrola s nejvyšším přínosem.
- Ověřujte na API, ne v promptu. Server by měl znovu zkontrolovat každý přijatý parametr proti skutečným oprávněním účtu a skutečnému stavu rezervace, místo aby se spoléhal na to, že model sestavil smysluplné volání. Model navrhuje, API rozhoduje.
Co musí server tržiště vynutit, aby mohl jeden přepravce přeskočit?
Server s jedním nosičem funguje vždy pouze ve své vlastní síti, takže jeho dopad je omezen na jednoho operátora. Server tržiště cituje a rezervuje napříč mnoha dopravci jménem mnoha uživatelů, což mění bezpečnostní úlohu dvěma způsoby.
Nejprve musí být rozsah nastaven pro každého uživatele a každého dopravce, nikoli pro každý server. Token, který umožní agentovi rezervovat u jednoho dopravce, by neměl tiše přejít k jinému a agent jednoho zákazníka nesmí nikdy vidět dokumenty jiného zákazníka. Zadruhé, auditní stopa je důležitější, protože když agent provádí rezervaci napříč tržištěm, musíte u každého zápisu odpovědět na otázku „který uživatel, který token, který dopravce, kdy“. Tento protokol považujeme za součást produktu, nikoli za dodatečnou úvahu, protože nám umožňuje zrušit oprávnění úzce, místo abychom vypnuli celý systém pro všechny.
Praktický seznam před tím, než zveřejníte rezervaci
- Rozdělte nástroje podle čtení a zápisu a poznamenejte si rozdělení tam, kde ho uvidí jak agent, tak váš tým.
- Udržujte nástroje pro citování a odkazování nízko-třecí, aby denní hodnota přežila.
- Každý zápis zabezpečte pomocí oborově vymezeného, krátkodobého, odvolatelného OAuth 2.1 tokenu s PKCE.
- Požadovat krok potvrzení při rezervaci, zrušení, změně příjemce a adresy.
- Znovu ověřte každý parametr na API oproti skutečným oprávněním a skutečnému stavu zásilky.
- Nikdy nesmíte poskytovat nástroje pro zápis přes neověřené HTTP a výchozí servery schopné zápisu směrujte na místní stdio.
- Připněte servery, ke kterým se váš agent připojuje, a revidujte nové, jako je nový kód.
- Zaznamenávejte každé zapsání s uživatelem, tokenem, nosičem a časem a nacvičte si odvolání, než ho budete potřebovat.
Žádný z těchto problémů není pro umělou inteligenci jedinečný. Jsou to kontroly, které již nyní používá špedice a platby, zaměřené na nové místo, kde může vzniknout instrukce. Agent je nový volající, nikoli nová sada pravidel.
Nejčastější dotazy
Je bezpečné nechat AI agenta vůbec rezervovat přepravu?
Ano, při rezervaci, která je za ověřeným a autorizovaným voláním s potvrzovacím krokem, a když server znovu zkontroluje každý parametr namísto důvěry v model. Nebezpečná verze je otevřený zapisovací nástroj bez lidské kontroly. S rezervací nakládejte jako s jakoukoli jinou finanční transakcí a agent se stane dalším ověřeným volajícím.
Proč používat OAuth 2.1 místo prostého API klíče?
Statické klíče mají tendenci být dlouhodobé, široce rozsahové a obtížně zrušitelné bez narušení všech, kdo je sdílejí. OAuth 2.1 vám dává omezené, krátkodobé a zrušitelné tokeny a vyžaduje PKCE v autorizačním toku. Pro lokální stdio server je klíč přijatelný, ale cokoli dosažitelné přes HTTP, co může zapisovat, by mělo používat model OAuth.
Co je nástrojové otrávení v MCP?
Otrávení nástroje (tool poisoning) nastává, když popis nástroje na serveru, který si agent přečte, aby se rozhodl, co zavolat, obsahuje skryté instrukce, které model navádějí k nebezpečným akcím, jako je únik klíče nebo přesměrování zásilky. Protože popis ovlivňuje chování, chráníte ho stejně jako kód: přišpendlíte důvěryhodné servery, máte člověka pro zápisy a provádíte validaci na API.
Měl by server pro přenos nákladu MCP fungovat jako stdio, nebo jako hostovaný HTTP?
Server s povolením pouze pro čtení je v pořádku přes hostovaný HTTP. Server s nástroji pro rezervace nebo dokumenty by měl ve výchozím nastavení používat lokální stdio a přes hostovaný HTTP by se měl přesunout, až když bude implementováno rozsahové OAuth, protože odhalený koncový bod pro zápis bez autentizace je dosažitelný kýmkoli, kdo najde URL.
Tím se uzavírá cyklus, který tato série otevřela. Pokud jste nečetli předchozí části, Úvod do protokolů vysvětluje, jak se z API pro přepravu zboží stává sada nástrojů, a zrušení ukazuje, kde tyto hranice v praxi nakreslily odeslané servery.