In de laatste twee delen van deze serie behandelde ik Hoe het Model Context Protocol zich verhoudt tot een vracht-API en daarna brak de vracht-MCP-servers af die in 2026 werden geleverd. Beide eindigden met dezelfde open vraag, dus dit deel beantwoordt die direct: hoe voorkom je dat een agent verkeerde vracht boekt voor de verkeerde persoon, zodra deze echte vracht kan boeken? Beveiliging is waar een MCP-server voor vrachtvervoer ophoudt een ontwikkelaarspeeltje te zijn en begint te lijken op een systeem dat geld en vrachtwagens verplaatst.
Ik voer dit uit vanuit de plek van een marktplaats die een API blootstelt, dus mijn bias is praktisch in plaats van academisch. De onderstaande bedreigingen zijn degene die we daadwerkelijk modelleren wanneer we beslissen welke tool een agent mag aanroepen zonder menselijke tussenkomst.
Waarom een vrachtwagen-server de inzet verhoogt
Een generieke MCP-server die je agenda leest lekt informatie wanneer deze faalt. Een vrachtserver die een lading boekt, doet iets dat kostbaarder is. Een verkeerde oproep kan een vrachtwagen naar de verkeerde opslagplaats sturen, een begunstigde op een actuele zending wijzigen, een boeking annuleren waarop een klant rekent, of een vrachtbrief trekken die nooit van het account had mogen komen. Dit zijn geen lekken van gegevens. Het zijn geld en fysieke goederen die bewegen op een instructie die niemand heeft ingetypt.
Dat verschil herkadert het hele probleem. Met een chatassistent is het ergste geval een gênant antwoord. Met vracht is het ergste geval een vrachtfactuur erbij en een zending ergens waar hij niet hoort. Dus de vraag is nooit "is deze server veilig" in abstracte zin. Het is "welke specifieke acties kan een agent ondernemen, en wat kost elke actie als het misgaat."
De twee faalmodi waar u zich zorgen over moet maken
Het meeste MCP-risico in 2026 zal terug te voeren zijn op twee patronen, en vracht verslechtert beide.
Prompt injectie is het oude webprobleem in een nieuw jasje. Een agent leest tekst uit een bron die hij niet volledig controleert, een vrachtbrief, een PDF, de e-mailinhoud, en die tekst bevat een instructie die het model opvolgt. In de vracht wordt de vergiftigde tekst de hele dag door via legitieme kanalen ontvangen: een boekingsopmerking, een douanebeschrijving, een statusupdate van een vervoerder. Als uw boekingssysteem alles vertrouwt wat het model doorgeeft, kan een zin die begraven ligt in een leveringsbon een echte annulering worden.
Tool poisoning is subtler en specifiek voor MCP. Het protocol laat een server zijn eigen tools beschrijven, en de agent leest die beschrijvingen om te beslissen wat hij moet aanroepen. Een kwaadaardige of gecompromitteerde server kan een beschrijving schrijven die het model stilletjes vertelt een API-sleutel te exfiltreren of een verzending om te leiden, en de gebruiker ziet die tekst nooit. Anthropic en onafhankelijke onderzoekers hebben begin 2026 varianten hiervan gedocumenteerd, en de les voor vracht is botweg: de beschrijvingslaag is uitvoerbaar, dus behandel een toolbeschrijving van een derde partij met hetzelfde wantrouwen als code van een derde partij.
Lezen versus schrijven: de lijn die uw authenticatie zou moeten bepalen
De meest nuttige beveiligingsbeslissing die ik heb genomen, was om te stoppen met denken aan "de MCP-server" als één vertrouwensgrens en deze op te splitsen op basis van wat elke tool met de wereld doet.
Wat kan er open blijven
Een rij quoten, capaciteit weergeven, een transito-schatting berekenen, een poortcode opzoeken. Niets van dit alles verandert iets. Het hele punt is dat een agent hen met weinig tot geen frictie kan bereiken, en daar ligt de dagelijkse waarde. Een lezer die drie routes wil vergelijken, hoeft daarvoor geen token te creëren. Bij de servers in de teardown hielden de serieuze exemplaren quotatie- en referentietools om precies deze reden wrijvingsloos.
Wat moet worden afgesloten
Boeken, annuleren, een afzender wijzigen, een adres bewerken, een document ophalen, alles wat een factuur raakt. Elk van deze acties schrijft naar de echte wereld, en elk van deze acties vereist een geauthenticeerde, geautoriseerde, controleerbare aanroep. De regel die we volgen is eenvoudig te stellen en moeilijker te handhaven: een leeshulp kan open zijn, een schrijfhulp nooit.
OAuth 2.1 en PKCE, geen langdurige sleutel in een configuratiebestand
De autorisatiespecificatie van MCP heeft gekozen voor OAuth 2.1 voor externe servers, en die keuze weegt zwaar voor de logistiek. Een statische API-sleutel die in een configuratiebestand is geplakt, is prima voor een solontwikkelaar die een server via stdio op zijn eigen machine draait. Het is het verkeerde model zodra de server bereikbaar is via HTTP en een agent namens een benoemde gebruiker binnen een gedeelde account handelt.
Drie eigenschappen doen het zware werk. Geë Scopeerde tokens betekenen dat een ticket dat is uitgegeven voor citeren niet kan boeken. Kortstondige tokens betekenen dat een gelekte inloggegevens vanzelf verlopen in plaats van eeuwig in een logboek te blijven bestaan. Intrekbare tokens betekenen dat wanneer iets mis lijkt, u de toegang binnen enkele seconden afsluit in plaats van een gedeelde sleutel te roteren waar iedereen van afhankelijk is. OAuth 2.1 vereist ook PKCE in de autorisatiecode-stroom, wat de onderscheppingskloof sluit die oudere OAuth-implementaties open lieten. Niets hiervan is exotisch. Het is dezelfde verharding die elke betalings-API heeft ondergaan, toegepast op het moment dat een agent zegt "boek het".
Hier is de vorm van de grenzen die we afdwingen, geschreven als de tabel die ik wou dat elke vrachtserver publiceerde.
| **Actie van de agent** | **Leest of schrijft** | **Authenticatie die we vereisen** | **Als het misgaat** |
| Offerte aanvragen | Lees | Open of basis sleutel | Verloren telefoontje, geen schade |
| Controleer capaciteit, transport, tracking | Lees | Open of basis sleutel | Slechtste geval een verouderde reactie |
| Boek een zending | Schrijf | Scoped OAuth-token, bevestigingsstap | Echte kosten, echte vrachtwagen |
| Annuleren of opnieuw boeken | Schrijf | Scoped token, idempotency key | Verloren plaats, boete |
| Ontvanger of adres wijzigen | Schrijf | Scoped token, menselijke bevestiging | Verkeerde bezorging, fraude |
| Een vrachtbrief of factuur opvragen | Lees gevoelige informatie | Scoped token, controle per document | Gegevens- en documentenlek |
Het patroon in die tabel is de daadwerkelijke productbeslissing. Reads bevinden zich aan de linkerkant en blijven goedkoop. Writes bevinden zich aan de rechterkant en verdienen hun frictie.
Het exposed-instance probleem
Een verrassende hoeveelheid MCP-risico is helemaal niet slim. Het is een server die bedoeld was om lokaal te draaien, blootgesteld aan het open internet zonder authenticatie, omdat het verzenden op die manier eenvoudiger was. Het protocol ondersteunt twee transporten. Een stdio-server draait als een lokaal proces dat de client start, waardoor deze op je machine blijft en niet op het netwerk. Een gehoste HTTP-server is bereikbaar voor alles wat de URL ervan kan vinden.
Voor een server die alleen-lezen is, is de HTTP-blootstelling grotendeels onschadelijk. Voor een server met boekingshulpmiddelen is het de hele wedstrijd. Als uw schrijfhulpmiddelen bereikbaar zijn via openbare HTTP, is authenticatie geen functie die u later toevoegt; het is datgene wat een vreemdeling scheidt van uw wachtrij. Onze regel is dat boekings- en documenthulpmiddelen nooit via een niet-geauthenticeerd HTTP-eindpunt worden aangeboden, punt uit. Bij twijfel moet een schrijf-geschikte server standaard stdio en lokale lancering gebruiken, en pas overschakelen naar gehoste HTTP zodra de bovenstaande OAuth-flow is geïmplementeerd.
De beschrijvingslaag verdedigen tegen toolvergiftiging
Omdat toolbeschrijvingen het model sturen, verdienen ze dezelfde controle als de code die je implementeert. Drie gewoonten dekken het grootste deel van de blootstelling.
- Pin en beoordeel de servers waarmee u verbinding maakt. Een agent die is aangesloten op een samengestelde set bekende servers is een kleiner doelwit dan een agent die installeert wat een register dan ook aanbiedt. Behandel een nieuwe server als een nieuwe afhankelijkheid, want dat is het ook.
- Houd een mens bij elke actie. Een bevestigingsstap vóór het boeken, annuleren of wijzigen van een ontvanger verandert een stil ingespoten instructie in een zichtbaar verzoek dat de gebruiker kan weigeren. Het is de goedkoopste controle met de hoogste opbrengst.
- **Valideren bij de API, niet in de prompt.** De server moet elke ontvangen parameter opnieuw controleren aan de hand van de werkelijke machtigingen van het account en de werkelijke status van de boeking, in plaats van erop te vertrouwen dat het model een zinnige aanroep heeft samengesteld. Het model stelt voor, de API beslist.
Wat een marktplaats-server moet afdwingen dat één enkele vervoerder kan overslaan
Een single-carrier server opereert altijd alleen binnen zijn eigen netwerk, dus zijn "blast radius" is één operator. Een marketplace server geeft offertes en boekt namens veel gebruikers bij veel providers, wat de beveiligingstaak op twee manieren verandert.
Ten eerste moet de reikwijdte per gebruiker en per vervoerder zijn, niet per server. Een token waarmee een agent bij één vervoerder kan boeken, mag niet onopgemerkt een andere bereiken, en de agent van de ene klant mag nooit documenten van een andere klant inzien. Ten tweede is het audit trail belangrijker, want wanneer een agent via een marktplaats boekt, moet u voor elke schrijfbewerking kunnen antwoorden op "welke gebruiker, welk token, welke vervoerder, op welk tijdstip". Wij beschouwen dat logboek als onderdeel van het product, niet als een bijzaak, aangezien het ons in staat stelt nauwkeurig in te trekken in plaats van alles ontoegankelijk te maken.
Een praktische checklist voordat u gaat boeken
- Splits de tools op in lees- en schrijftoegang, en schrijf de splitsing op waar het team en jij het kunnen zien.
- Houd quotatie- en referentietools laagdrempelig zodat de dagelijkse waarde behouden blijft.
- Schakel elke schrijfbewerking achter een scope-gebonden, kortstondige, intrekbare OAuth 2.1-token met PKCE.
- Vereist een bevestigingsstap voor boekingen, annuleringen en wijzigingen in ontvanger en adres.
- Valideer elke parameter bij de API opnieuw tegen echte permissies en de echte status van de zending.
- Serveer schrijftools nooit via niet-geauthenticeerde HTTP, en standaardiseer schrijfbare servers naar lokale stdio.
- Pin de servers waarmee uw agent verbinding maakt, en beoordeel nieuwe zoals nieuwe code.
- Log elke schrijving met gebruiker, token, vervoerder en tijd, en oefen intrekking voordat u deze nodig heeft.
Geen van deze technieken is uniek voor kunstmatige intelligentie. Het zijn de controles die vracht en betalingen al gebruiken, gericht op de nieuwe plek waar een instructie kan ontstaan. De agent is een nieuwe beller, geen nieuwe set regels.
Veelgestelde vragen
Is het veilig om een AI-agent vracht te laten boeken?
Ja, wanneer de boeking plaatsvindt achter een geauthenticeerde en geautoriseerde oproep met een bevestigingsstap, en wanneer de server elke parameter opnieuw controleert in plaats van de model te vertrouwen. De onveilige versie is een open schrijf-tool zonder menselijke tussenkomst. Behandel boekingen zoals elke andere geldtransactie en de agent wordt een geauthenticeerde beller.
Waarom OAuth 2.1 gebruiken in plaats van een eenvoudige API-sleutel?
Een statische sleutel is meestal langdurig, breed van scope en moeilijk in te trekken zonder iedereen die hem deelt te storen. OAuth 2.1 biedt u tokens met specifieke bereiken, korte levensduur en intrekbaarheid en vereist PKCE in het autorisatieproces. Voor een lokale stdio-server is een sleutel aanvaardbaar, maar alles dat via HTTP bereikbaar is en kan schrijven, moet het OAuth-model gebruiken.
Wat is tool poisoning in MCP?
Tool poisoning is wanneer de beschrijving van een tool op een server, die de agent leest om te beslissen wat hij moet aanroepen, verborgen instructies bevat die het model sturen naar schadelijke acties, zoals het lekken van een sleutel of het omleiden van een zending. Omdat de beschrijving het gedrag beïnvloedt, verdedig je deze zoals je code verdedigt: vertrouwde servers vastzetten, een mens laten schrijven en valideren bij de API.
Moet een freight MCP-server draaien als stdio of als gehoste HTTP?
Een read-only utilityserver is prima via gehoste HTTP. Een server met boekings- of documenttools moet standaard naar lokale stdio gaan en pas overstappen naar gehoste HTTP zodra een gescoped OAuth is geïmplementeerd, omdat een blootgesteld schrijf-eindpunt zonder authenticatie bereikbaar is voor iedereen die de URL vindt.
Dat sluit de cirkel die deze serie begon. Als je de eerdere delen nog niet hebt gelezen, legt de protocol primer uit hoe een vracht-API een set tools wordt, en de afbreken laat zien waar de verzonden servers deze lijnen in de praktijk hebben getrokken.