I de två senaste delarna av den här serien täckte jag hur Modellkontextprotokollet mappas till ett frakt-API och sedan revs ner frakt-MCP-servrarna som levererades 2026. Båda slutade med samma öppna fråga, så den här delen besvarar den direkt: när en agent kan boka riktiga frakter, hur förhindrar du att den bokar fel sak för fel person? Säkerhet är där en MCP-server för frakt slutar se ut som en utvecklares leksak och börjar se ut som ett system som flyttar pengar och lastbilar.
Jag kör detta från en handelsplats som exponerar ett API, så mina förutfattade meningar är praktiska snarare än akademiska. Hoten nedan är de vi faktiskt modellerar när vi bestämmer vilket verktyg en agent får anropa utan mänsklig inblandning.
Varför en fraktservice höjer insatserna
En generell MCP-server som läser din kalender läcker information vid fel. En fraktserver som bokar en last utgör en dyrare risk. Ett felaktigt kommando kan skicka en lastbil till fel depå, ändra en mottagare på en pågående försändelse, annullera en bokning som en kund räknar med, eller dra en fraktsedel som aldrig borde ha lämnat kontot. Dessa är inte buggar som exponerar data. De handlar om pengar och fysiska varor som förflyttas på grund av en instruktion som ingen skrev.
Den skillnaden omformulerar hela problemet. Med en chattassistent är det värsta som kan hända att man får ett pinsamt svar. Med frakt finns det en fraktfaktura kopplad till det värsta som kan hända och en försändelse som befinner sig där den inte borde vara. Så frågan är aldrig "är den här servern säker" abstrakt. Den är "vilka specifika åtgärder kan en agent vidta, och vad kostar var och en om något går fel."
De två feltyper som är värda att oroa sig för
Den största risken med MCP år 2026 reduceras till två mönster, och frakten försämrar båda.
Prompt injection är det gamla webbproblemet i ny skepnad. En agent läser text från en källa som den inte helt kontrollerar, en fraktsedel, en PDF, ett e-postmeddelande, och den texten innehåller en instruktion som modellen följer. Inom fraktbranschen kommer den förgiftade texten in genom legitima kanaler hela dagen: en bokningskommentar, en tullbeskrivning, en transportörs statusuppdatering. Om ditt bokningsverktyg litar på vadhelst modellen skickar vidare, kan en mening begravd i en leveransnota bli en verklig avbokning.
Verktygsförgiftning är en mer subtil attack som är specifik för MCP. Protokollet tillåter en server att beskriva sina egna verktyg, och agenten läser dessa beskrivningar för att besluta vad som ska anropas. En skadlig eller komprometterad server kan skriva en beskrivning som i tysthet instruerar modellen att exfiltrera en API-nyckel eller omdirigera en sändning, och användaren ser aldrig den texten. Anthropic och oberoende forskare spenderade tidigt 2026 på att dokumentera varianter av detta, och lärdomen för frakttransporter är tydlig: beskrivningslagret är exekverbart, så behandla en verktygsbeskrivning från tredje part med samma misstänksamhet som du skulle behandla kod från tredje part.
Läsa kontra skriva: linjen som borde avgöra din autentisering
Det viktigaste säkerhetsbeslutet jag tog var att sluta tänka på "MCP-servern" som en enda förtroendegräns och istället dela upp den baserat på vad varje verktyg gör för världen.
Vad kan hålla öppet
Att ange en färdväg, lista kapacitet, beräkna en transittid, slå upp en hamnkod. Inget av detta ändrar något. Att låta en agent nå dem med minimal eller ingen friktion är hela poängen, och det är där det dagliga värdet ligger. En läsare som vill jämföra tre rutter ska inte behöva skapa en token för att göra det. På servrarna under avvecklingen höll de seriösa verktygen för att ange och referera låg friktion just av denna anledning.
Vad måste kontrolleras
Bokning, avbokning, ändring av mottagare, redigering av en adress, hämtning av ett dokument, allt som rör en faktura. Varenda en av dessa skriver till den verkliga världen, och varenda en behöver ett autentiserat, auktoriserat och granskningsbart anrop bakom sig. Regeln vi följer är enkel att formulera och svårare att upprätthålla: ett läsverktyg kan vara öppet, ett skrivverktyg aldrig.
OAuth 2.1 och PKCE, ingen långlivad nyckel i en konfigurationsfil
MCP-auktorisationsspecifikationen fastnade för OAuth 2.1 för fjärrservrar, och det valet har verkligen betydelse för frakten. En statisk API-nyckel inklistrad i en konfigurationsfil fungerar för en ensam utvecklare som kör en server via stdio på sin egen maskin. Det är fel modell i det ögonblick servern är nåbar via HTTP och en agent agerar å namnet av en namngiven användare inom ett delat konto.
Tre egenskaper gör det tunga arbetet. Scopeade tokens innebär att ett token som präglats för bokning inte kan användas för bokning. Kortlivade tokens innebär att en läckt autentiseringsuppgift löper ut av sig själv istället för att leva för evigt i en logg. Återkallbara tokens innebär att när något ser fel ut, begränsar du åtkomsten på sekunder istället för att rotera en delad nyckel som alla är beroende av. OAuth 2.1 kräver också PKCE på auktoriseringskodflödet, vilket täpper till avlyssningsluckan som äldre OAuth-installationer lämnade öppen. Inget av detta är exotiskt. Det är samma härdning som alla API:er för betalningar har genomgått, tillämpat på det ögonblick då en agent säger "boka det".
Här är formen på gränsen vi upprätthåller, skriven som tabellen jag önskar att varje fraktservare skulle publicera.
| **Åtgärd från agenten** | Läser eller skriver | Autentisering vi kräver | **Om det går fel** |
| Få en offert | Läs | Öppen eller grundläggande nyckel | Slöseri med samtal, ingen skada |
| Kontrollera kapacitet, transit, spårning | Läs | Öppen eller grundläggande nyckel | Sämsta svaret i värsta fall |
| Boka en leverans | Skriv | Omfattningstoken för OAuth, bekräftelsesteg | Verkligt pris, verklig lastbil |
| Avboka eller boka om | Skriv | Scoped token, idempotensnyckel | Förlorad plats, straff |
| Ändra mottagare eller adress | Skriv | Scoped token, mänsklig bekräftelse | Felaktig leverans, bedrägeri |
| Hämta en konossement eller en faktura | Läs känslig | Scoped token, per-dokumentkontroll | Data- och dokumentläcka |
Mönstret i den tabellen är det faktiska produktbeslutet. Läser sitter till vänster och förblir billiga. Skriver sitter till höger och tjänar sin friktion.
Exponerade-instansproblemet
En överraskande mängd MCP-risk är inte alls smart. Det är en server som var tänkt att köras lokalt, exponerad mot det öppna internet utan autentisering, eftersom det var enklare att leverera den så. Protokollet stöder två transportmetoder. En stdio-server körs som en lokal process som klienten startar, vilket håller den på din maskin och utanför nätverket. En hostad HTTP-server är nåbar av allt som kan hitta dess URL.
För en server som bara är till för att läsa data är den HTTP-exponering som finns mestadels ofarlig. För en server med bokningsverktyg är det däremot hela grejen. Om dina skrivverktyg är åtkomliga via publik HTTP är autentisering inte en funktion du lägger till senare, det är vad som står mellan en främling och din kö för utskick. Vår regel är att boknings- och dokumentverktyg aldrig ska serveras via ett oautentiserat HTTP-slutpunkt, punkt slut. Om du är osäker bör en skrivbar server som standard använda stdio och lokal körning, och bara gå över till hostad HTTP när OAuth-flödet ovan är på plats.
Försvar av beskrivningslagret mot verktygsförgiftning
Eftersom verktygsbeskrivningar styr modellen, förtjänar de samma kontroller som kod du driftsätter. Tre vanor täcker det mesta av exponeringen.
- **Fäst och granska servrarna du ansluter till.** En agent som är kopplad till en kuraterad uppsättning kända servrar är ett mindre mål än en som installerar vad som helst ett register erbjuder. Behandla en ny server som ett nytt beroende, för det är vad det är.
- Ha en människa på varje skrivande. Ett bekräftelsesteg innan bokning, avbokning eller ändring av en mottagare gör en tyst inmatad instruktion till en synlig begäran som användaren kan neka. Det är den billigaste kontrollen med den högsta avkastningen.
- **Validera vid API:et, inte i prompten.** Servern bör kontrollera varje parameter den tar emot mot kontots verkliga behörigheter och bokningens verkliga status, istället för att lita på att modellen har satt ihop ett vettigt anrop. Modellen föreslår, API:et beslutar.
Vad en marknadsplatserver måste upprätthålla så att en enda transportör kan hoppa över
En serverserver agerar bara i sitt eget nätverk, så dess explosionsradie är en operatör. En marknadsplats-server citerar och bokar över många transportörer å många användares vägnar, vilket ändrar säkerhetsarbetet på två sätt.
Först måste omfånget vara per användare och per transportör, inte per server. En token som låter en agent boka hos en transportör ska inte tyst nå en annan, och en kunds agent får aldrig se en annan kunds dokument. För det andra är revisionsspåret viktigare, för när en agent bokar över en marknadsplats måste du svara "vilken användare, vilken token, vilken transportör, vid vilken tidpunkt" för varje skrivning. Vi behandlar den loggen som en del av produkten, inte som ett tillägg, eftersom det är den som låter oss återkalla med snäva begränsningar istället för att stänga ner för alla.
En praktisk checklista innan du släpper bokningen
- Dela upp verktygen i läs- och skrivverktyg och skriv ner uppdelningen där både agenten och ditt team kan se den.
- Håll verktyg för citering och referenser friktionsfria så att det dagliga värdet består.
- Sätt varje skrivning bakom en scoped, kortlivad, återkallningsbar OAuth 2.1-token med PKCE.
- Kräv ett bekräftelsesteg vid bokning, avbokning och ändringar av mottagare och adress.
- Omvalidera varje parameter mot API:et mot verkliga behörigheter och verkligt leveransstatus.
- Servera aldrig skrivverktyg över oautentiserat HTTP, och ställ in skrivbara servrar som standard till lokal stdio.
- Fäst de servrar din agent ansluter till, och granska nya precis som ny kod.
- Logga varje skrivning med användare, token, bärare och tid, och öva återkallelse innan du behöver det.
Ingen av dessa är unika för artificiell intelligens. Det är de kontroller som frakt och betalningar redan använder, riktade mot den nya plats där en instruktion kan komma ifrån. Agenten är en ny anropare, inte en ny regeluppsättning.
Vanliga frågor
Är det säkert att låta en AI-agent boka frakt överhuvudtaget?
Ja, när bokning sker bakom ett autentiserat och auktoriserat anrop med ett bekräftelsesteg, och när servern kontrollerar varje parameter igen istället för att lita på modellen. Den osäkra versionen är ett öppet skrivverktyg utan mänsklig inblandning. Behandla bokning som alla andra penningrörelser och agenten blir ytterligare en autentiserad anropare.
Varför använda OAuth 2.1 istället för en enkel API-nyckel?
En statisk nyckel tenderar att vara långlivad, brett omfattande och svår att återkalla utan att störa alla som delar den. OAuth 2.1 ger dig tokens med omfång, kort livslängd och som kan återkallas samt kräver PKCE i auktoriseringsflödet. För en lokal stdio-server är en nyckel acceptabel, men allt som kan nås via HTTP och som kan skriva bör använda OAuth-modellen.
Vad är "tool poisoning" inom MCP?
Verktygsförgiftning innebär att en servers verktygsbeskrivning, som agenten läser för att bestämma vad som ska anropas, innehåller dolda instruktioner som styr modellen mot skadliga åtgärder såsom att läcka en nyckel eller omdirigera en leverans. Eftersom beskrivningen påverkar beteendet skyddar du den på samma sätt som du skyddar kod: fäst betrodda servrar, ha en människa som granskar skrivningar och validera vid API:et.
Bör en MCP-server för frakt köras som stdio eller hosted HTTP?
En server som endast kan läsas är okej över hostad HTTP. En server med boknings- eller dokumentverktyg bör som standard använda lokal stdio och endast gå över till hostad HTTP när skopad OAuth är på plats, eftersom en exponerad skrivslutpunkt utan autentisering kan nås av vem som helst som hittar URL:en.
Det sluter cirkeln som denna serie öppnade. Om du inte har läst de tidigare delarna, förklarar protokollprimer hur ett frakt-API blir en uppsättning verktyg, och rivning visar var de levererade servrarna drog dessa linjer i praktiken.