W dwóch ostatnich częściach tej serii omawiałem usługi Jak Protokół Kontekstu Modelu mapuje się na API przewozowe, a następnie zdemontował serwery MCP towarowe, które trafiły do sprzedaży w 2026 roku. Obie zakończyły się tą samą otwartą kwestią, więc ta część odpowiada na nią bezpośrednio: gdy agent może rezerwować rzeczywisty fracht, jak powstrzymać go przed rezerwacją niewłaściwej rzeczy dla niewłaściwej osoby? Bezpieczeństwo jest tym, co sprawia, że serwer MCP dla frachtu przestaje przypominać zabawkę programisty i zaczyna wyglądać jak system, który przemieszcza pieniądze i ciężarówki.
Uruchamiam to z poziomu rynku, który udostępnia API, więc moje nastawienie jest praktyczne, a nie akademickie. Poniższe zagrożenia to te, które faktycznie modelujemy, decydując, które narzędzie agent może wywołać bez udziału człowieka.
Dlaczego serwer pocztowy podnosi poprzeczkę
Ogólny serwer MCP odczytujący Twój kalendarz ujawnia informacje podczas awarii. Serwer transportowy, który rezerwuje ładunek, robi coś kosztowniejszego. Zła decyzja może wysłać ciężarówkę na niewłaściwy plac, zmienić odbiorcę w trakcie realizacji wysyłki, anulować rezerwację, na którą liczy klient, lub pobrać list przewozowy, który nigdy nie powinien opuścić konta. To nie są błędy związane z ujawnieniem danych. To pieniądze i fizyczny towar przesuwający się na podstawie instrukcji, której nikt nie wpisał.
Ta różnica zmienia całościowe postrzeganie problemu. W przypadku asystenta czatu, najgorszym scenariuszem jest krępująca odpowiedź. W przypadku frachtu, najgorszy scenariusz wiąże się z fakturą za fracht i wysyłką w miejsce, gdzie nie powinna się znaleźć. Zatem pytanie nigdy nie brzmi "czy ten serwer jest bezpieczny" w abstrakcji. Brzmi ono "jakie konkretne działania może podjąć agent i ile kosztuje każda z nich, jeśli pójdzie źle".
Dwa tryby awarii, które budzą największy niepokój
W 2026 roku ryzyko MCP ogranicza się do dwóch wzorców, a transport towarowy pogarsza oba.
**Wstrzyknięcie polecenia** to stary problem sieci, który przybrał nową postać. Agent odczytuje tekst z miejsca, nad którym nie ma pełnej kontroli, np. z noty wysyłkowej, pliku PDF, treści wiadomości e-mail, a tekst ten zawiera instrukcję, którą model wykonuje. W branży spedycyjnej zatruty tekst dociera kanałami legalnymi przez cały dzień: w komentarzu do zlecenia, opisie celnym, aktualizacji statusu przewoźnika. Jeśli Twoje narzędzie do rezerwacji zaufa wszystkiemu, co prześle mu model, zdanie ukryte w nocie dostawy może doprowadzić do faktycznego anulowania zlecenia.
Zatruwanie narzędzi jest subtelniejsze i specyficzne dla MCP. Protokół pozwala serwerowi opisać swoje własne narzędzia, a agent odczytuje te opisy, aby zdecydować, co wywołać. Złośliwy lub skompromitowany serwer może napisać opis, który potajemnie informuje model o eksfiltracji klucza API lub przekierowaniu przesyłki, a użytkownik nigdy nie widzi tego tekstu. Anthropic i niezależni badacze spędzili początek 2026 roku dokumentując warianty tego problemu, a lekcja dla branży transportowej jest jasna: warstwa opisu jest wykonywalna, więc traktuj opis narzędzia strony trzeciej z takim samym podejrzeniem, z jakim traktowałbyś kod strony trzeciej.
Odczyt czy zapis: granica, która powinna decydować o Twoim uwierzytelnieniu
Najbardziej użyteczną decyzją dotyczącą bezpieczeństwa, jaką podjąłem, było zaprzestanie myślenia o "serwerze MCP" jako o jednej granicy zaufania i podzielenie go według tego, co każde narzędzie robi w świecie.
Co może zostać otwarte
Cytowanie przewoźnika, podawanie ładowności, szacowanie czasu tranzytu, wyszukiwanie kodu portu. Żadne z tych działań niczego nie zmienia. Umożliwienie agentowi dotarcia do nich z niewielkim lub zerowym tarciem jest całym celem i w tym tkwi codzienna wartość. Czytelnik, który chce porównać trzy trasy, nie powinien musieć do tego tworzyć tokenu. Na serwerach podczas demontażu, te poważne z tego właśnie powodu utrzymywały niskie tarcie dla narzędzi cytowania i referencyjnych.
Co musi być ograniczone
Rezerwacja, anulowanie, zmiana odbiorcy, edycja adresu, pobranie dokumentu - wszystko, co dotyczy faktury. Każda z tych czynności zapisuje dane w świecie rzeczywistym i każda wymaga uwierzytelnionego, autoryzowanego i możliwego do prześledzenia wywołania. Zasada, którą stosujemy, jest prosta do zdeklarowania i trudniejsza do egzekwowania: narzędzie do odczytu może być otwarte, narzędzie do zapisu nigdy.
OAuth 2.1 i PKCE, a nie długożyjący klucz w pliku konfiguracyjnym
Specyfikacja autoryzacji MCP wybrała OAuth 2.1 dla serwerów zdalnych i ten wybór ma realne znaczenie dla branży transportowej. Statyczny klucz API wklejony do pliku konfiguracyjnego jest w porządku dla samodzielnego dewelopera uruchamiającego serwer przez stdio na swojej maszynie. Jest to zły model w momencie, gdy serwer jest dostępny przez HTTP, a agent działa w imieniu nazwanego użytkownika w ramach współdzielonego konta.
Trzy właściwości wykonują najwięcej pracy. **Scoped** tokeny oznaczają, że token wybity do cytowania nie może dokonać rezerwacji. **Krótkotrwałe** tokeny oznaczają, że wyciekły poświadczenia wygasają samoistnie, zamiast żyć wiecznie w logach. **Odwołalne** tokeny oznaczają, że gdy coś wygląda nie tak, odcinasz dostęp w ciągu sekund, zamiast rotować współdzielony klucz, od którego wszyscy zależą. OAuth 2.1 wymaga również PKCE w przepływie kodu autoryzacji, co zamyka lukę w przechwytywaniu, którą pozostawiły otwartą starsze wdrożenia OAuth. Nic z tego nie jest egzotyczne. To to samo utwardzenie, przez które przeszedł każdy API płatności, zastosowane do momentu, gdy agent mówi „zarezerwuj”.
Oto kształt granicy, którą egzekwujemy, zapisany w formie tabeli, którą chciałbym, aby każdy serwer przewozowy publikował.
| Akcja agenta | Czyta lub pisze | Autoryzacja, której potrzebujemy | Jeśli pójdzie źle |
| Wyślij zapytanie ofertowe | Czytaj | Otwarty lub podstawowy klucz | Nieudane połączenie, brak szkody |
| Sprawdź pojemność, tranzyt, śledzenie | Czytaj | Otwarty lub podstawowy klucz | Stale odpowiedzi w najgorszym przypadku |
| Zarezerwuj przesyłkę | Napisz | Token OAuth zakresu, krok potwierdzenia | Prawdziwy koszt, prawdziwa ciężarówka |
| Anuluj lub przełóż wizytę | Napisz | Scoped token, klucz idempotencyjny | Stracony slot, kara |
| Zmień odbiorcę lub adres | Napisz | Scoped token, potwierdzenie przez człowieka | Niewłaściwe dostarczenie, oszustwo |
| Pociągnij konosament lub fakturę | Czytaj wrażliwe | Token zakresowy, kontrola per dokument | Wyciek danych i dokumentów |
Wzór w tej tabeli to fakcyjna decyzja dotycząca produktu. Odczyty znajdują się po lewej i pozostają tanie. Zapisy znajdują się po prawej i zarabiają na swoim tarciu.
Problem ujawnionej instancji
Zaskakująca ilość ryzyka związanego z MCP nie jest wcale sprytna. Jest to serwer, który miał działać lokalnie, wystawiony na otwarty internet bez uwierzytelniania, ponieważ wysłanie go w takiej formie było łatwiejsze. Protokół obsługuje dwa rodzaje transportu. Serwer stdio działa jako lokalny proces uruchamiany przez klienta, co utrzymuje go na twojej maszynie i z dala od sieci. Hostowany serwer HTTP jest dostępny dla wszystkiego, co może znaleźć jego adres URL.
Dla serwerów narzędziowych tylko do odczytu, ekspozycja HTTP jest w większości niegroźna. Dla narzędzi rezerwacyjnych jest to kluczowa sprawa. Jeśli twoje narzędzia do zapisu są dostępne przez publiczne HTTP, uwierzytelnianie nie jest funkcją, którą dodajesz później, to rzecz stojąca między obcym a twoją kolejką zleceń. Nasza zasada mówi, że narzędzia do rezerwacji i dokumentów nigdy nie są udostępniane przez nieuwierzytelniony punkt końcowy HTTP, kropka. W razie wątpliwości, serwer z możliwością zapisu powinien domyślnie używać stdio i lokalnego uruchomienia, przechodząc do hostowanego HTTP dopiero po wdrożeniu powyższego przepływu OAuth.
Ochrona warstwy opisowej przed zatruciem narzędzi
Ponieważ opisy narzędzi kierują modelem, zasługują na te same kontrole co wdrożony kod. Trzy nawyki pokrywają większość ekspozycji.
- **Przypinaj i przeglądaj serwery, z którymi się łączysz.** Agent połączony ze starannie wyselekcjonowanym zestawem znanych serwerów jest mniejszym celem niż taki, który instaluje cokolwiek oferuje rejestr. Traktuj nowy serwer jak nowe zależności, ponieważ właśnie nimi są.
- Niech przy każdym zapisie czuwa człowiek. Krok potwierdzenia przed rezerwacją, anulowaniem lub zmianą odbiorcy zamienia cichą, wprowadzoną instrukcję w widoczne żądanie, które użytkownik może odrzucić. Jest to najtańsza kontrola o najwyższym zwrocie.
- **Walidacja na poziomie API, a nie w promopcie.** Serwer powinien ponownie sprawdzić każdy otrzymany parametr w odniesieniu do rzeczywistych uprawnień konta i rzeczywistego stanu rezerwacji, zamiast ufać, że model stworzył sensowne wywołanie. Model proponuje, API decyduje.
Co serwer rynku musi egzekwować, aby jeden przewoźnik mógł pominąć
Serwer jednokanałowy działa zawsze tylko we własnej sieci, więc jego promień rażenia to jeden operator. Serwer rynkowy kwotuje i rezerwuje usługi u wielu przewoźników w imieniu wielu użytkowników, co zmienia zadanie związane z bezpieczeństwem na dwa sposoby.
Po pierwsze, zakres działania musi być per użytkownik i per przewoźnik, a nie per serwer. Token, który pozwala agentowi zarezerwować usługę u jednego przewoźnika, nie powinien potajemnie pozwolić na skorzystanie z usług innego, a agent jednego klienta nigdy nie powinien mieć dostępu do dokumentów innego klienta. Po drugie, ścieżka audytu ma większe znaczenie, ponieważ kiedy agent dokonuje rezerwacji na rynku, musisz odpowiedzieć "który użytkownik, który token, który przewoźnik, o której godzinie" dla każdego zapisu. Traktujemy ten dziennik jako część produktu, a nie jako dodatek, ponieważ to on pozwala nam na odwoływanie dostępu w sposób wąski, zamiast wyłączania usługi dla wszystkich.
Praktyczna lista kontrolna przed udostępnieniem rezerwacji
- Podziel narzędzia na zapisujące (write) i odczytujące (read), a następnie opisz podział w miejscu, gdzie mogą go zobaczyć zarówno agent, jak i Twój zespół.
- Utrzymuj narzędzia do cytowania i odwołań o niskim tarciu, aby codzienna wartość przetrwała.
- Zabezpiecz każdy zapis przy użyciu krótkotrwałego, odwołalnego tokena OAuth 2.1 z PKCE.
- Wymagaj kroku potwierdzającego w przypadku rezerwacji, anulacji oraz zmian odbiorcy i adresu.
- Ponownie zweryfikuj każdy parametr w API pod kątem rzeczywistych uprawnień i faktycznego stanu przesyłki.
- Nigdy nie udostępniaj narzędzi do zapisu przez nieautoryzowany protokół HTTP i domyślnie ustaw serwery z możliwością zapisu na lokalny stdio.
- Przypnij serwery, z którymi łączy się Twój agent, i przeglądaj nowe, tak jak nowy kod.
- Rejestruj każdy zapis z użytkownikiem, tokenem, przewoźnikiem i czasem, i przećwicz odwołanie, zanim będzie potrzebne.
Żadne z nich nie jest unikatowe dla sztucznej inteligencji. Są to mechanizmy sterowania, z których już korzystają fracht i płatności, skierowane na nowe miejsce, w którym może pochodzić instrukcja. Agent to nowy dzwoniący, a nie nowy zestaw reguł.
Najczęściej zadawane pytania
Czy można bezpiecznie zlecić sztucznej inteligencji rezerwację transportu towarowego?
Tak, rezerwacja jest bezpieczna, gdy stoi za nią uwierzytelnione i autoryzowane wywołanie z krokiem potwierdzenia, a serwer ponownie sprawdza każdy parametr, zamiast ufać modelowi. Niebezpieczna wersja to otwarte narzędzie zapisujące bez udziału człowieka. Traktuj rezerwację jak każdą inną akcję przenoszącą pieniądze, a agent stanie się kolejnym uwierzytelnionym wywołującym.
Dlaczego używać OAuth 2.1 zamiast prostego klucza API?
Klucz statyczny jest zazwyczaj długożyjący, szeroko zakrojony i trudny do odwołania bez zakłócania pracy wszystkim, którzy go udostępniają. OAuth 2.1 zapewnia tokeny ograniczone zakresem, krótkotrwałe i możliwe do odwołania, a także wymaga PKCE w przepływie autoryzacji. W przypadku lokalnego serwera stdio klucz jest akceptowalny, ale wszystko, co jest dostępne przez HTTP i może zapisywać dane, powinno stosować model OAuth.
Co to jest zatruwanie narzędzi w MCP?
Zatrważenie narzędzia (tool poisoning) ma miejsce, gdy opis narzędzia serwera, który agent odczytuje, aby zdecydować, co wywołać, zawiera ukryte instrukcje, które nakłaniają model do szkodliwych działań, takich jak ujawnienie klucza lub przekierowanie przesyłki. Ponieważ opis wpływa na zachowanie, należy go chronić w taki sam sposób, jak chroni się kod: przypinać zaufane serwery, zatrudnić człowieka do wprowadzania zmian i walidować na poziomie API.
Czy serwer MCP dla przewozu towarów powinien działać jako stdio czy jako hostowany HTTP?
Serwer narzędziowy tylko do odczytu jest w porządku przez hostowany protokół HTTP. Serwer z narzędziami do rezerwacji lub dokumentów powinien domyślnie korzystać z lokalnego stdio, a dopiero po zastosowaniu OAuth z dostępem ograniczonym przez zakres przejść na hostowany protokół HTTP, ponieważ dostępny punkt zapisu bez uwierzytelniania jest dostępny dla każdego, kto znajdzie adres URL.
Zamyka to pętlę, którą otworzyła ta seria. Jeśli nie czytałeś wcześniejszych części, Podstawy protokołów wyjaśnia, jak API frachtowe staje się zestawem narzędzi, a rozbiórka pokazuje, gdzie wysłane serwery narysowały te linie w praktyce.