Tässä sarjassa viimeisissä kahdessa osassa käsittelin miten mallikontekstiprotokolla vastaa tavaraliikenteen API:a ja sitten purettiin vuonna 2026 toimitettujen tavaroiden MCP-palvelimet. Molemmat päättyivät samaan avoimeen kysymykseen, joten tämä osa vastaa siihen suoraan: kun agentti pystyy varaamaan todellisia rahtitoimituksia, miten estät sitä varaamasta väärää asiaa väärälle henkilölle? Turvallisuus on se, missä rahtitoimituksia käsittelevä MCP-palvelin lakkaa näyttämästä kehittäjän leikkikalulta ja alkaa näyttää järjestelmältä, joka siirtää rahaa ja kuorma-autoja.
Toimin teknologiakeskuksessa, joka tarjoaa API:n, joten puolueellisuuteni on käytännöllistä akateemisen sijaan. Alla olevat uhat ovat niitä, joita todellisuudessa mallinnamme päättäessämme, mitä työkalua agentti voi kutsua ilman ihmistä ohjaimissa.
Miksei rahtipalvelin nosta panoksia
Yleinen MCP-palvelin, joka lukee kalenteriasi, vuotaa tietoja epäonnistuessaan. Rahtipalvelin, joka varaa kuorman, tekee jotain kalliimpaa. Huono puhelu voi lähettää rekan väärään pihaan, muuttaa elävän lähetyksen vastaanottajaa, peruuttaa asiakkaan odottaman varauksen tai vetää alkuperäisen rahtikirjan, joka ei olisi koskaan saanut lähteä tililtä. Nämä eivät ole tietojen paljastumisvirheitä. Nämä ovat rahaa ja fyysisiä tavaroita, jotka liikkuvat ilman käyttäjän syöttämää ohjetta.
Tuo ero muuttaa koko ongelman toiseen muotoon. Keskustelevan assistentin tapauksessa pahin tapaus on kiusallinen vastaus. Rahtitavaran tapauksessa pahin tapaus liittyy rahtilaskuun ja siihen, että lähetys on jossain, missä sen ei pitäisi olla. Joten kysymys ei koskaan ole "onko tämä palvelin turvallinen" abstraktisti. Se on "mitä erityisiä toimia agentti voi tehdä, ja mitä kukin niistä maksaa, jos menee pieleen."
Kaksi epäonnistumistapaa, joiden vuoksi kannattaa valvoa öitä
Suurin osa riskeistä vuonna 2026 liittyy kahteen kuvioon, ja rahti pahentaa molempia.
Prompti-injektio on vanha verkkohäiriö uusissa vaatteissa. Agentti lukee tekstiä jostain, mitä se ei täysin hallitse, esimerkiksi lähetysselosteesta, PDF-tiedostosta tai sähköpostin rungosta, ja tämä teksti sisältää ohjeen, jota malli tottelee. Kuljetusalalla myrkytetty teksti saapuu laillisia kanavia pitkin koko päivän: varauskommenttina, tulliselostuksena tai kuljetusliikkeen tilapäivityksenä. Jos varaustyökalusi luottaa kaikkeen, mitä malli sille välittää, toimitusasiakirjaan piilotettu lause voi muuttua todelliseksi peruutukseksi.
Työkaluilla myrkyttäminen on hienovaraisempaa ja liittyy nimenomaan MCP:hen. Protokolla antaa palvelimen kuvailla omia työkalujaan, ja agentti lukee nämä kuvaukset päättääkseen, mitä kutsua. Pahantahtoinen tai vaarantunut palvelin voi kirjoittaa kuvauksen, joka hiljaa kehottaa mallia vuotamaan API-avaimen tai ohjaamaan lähetyksen uudelleen, ilman että käyttäjä näkee tätä tekstiä. Anthropic ja riippumattomat tutkijat viettivät vuoden 2026 alkua dokumentoiden tämän variantteja, ja opetus rahdin osalta on suora: kuvauskerros on suoritettava, joten kohtele kolmannen osapuolen työkalukuvausta samalla epäluulolla kuin kohtelet kolmannen osapuolen koodia.
Luku vs. kirjoitus: raja, joka määrittää valtuutuksesi
Tärkein yksittäinen hyödyllinen turvallisuuspäätös, jonka tein, oli lopettaa "MCP-palvelimen" ajatteleminen yhtenä luottamusrajana ja jakaa se sen mukaan, mitä kukin työkalu tekee maailmalle.
Mikä voi pysyä auki
Linjan hinnoittelu, kapasiteetin listaaminen, kuljetusarvion laskeminen, satamakoodin etsiminen. Mikään näistä ei muUTA mitään. Tarkoitus on antaa agentin ottaa yhteyttä heihin mahdollisimman vähällä kitkalla, ja siinä on päivittäinen arvo. Lukijan, joka haluaa vertailla kolmea reittiä, ei pitäisi joutua luomaan tokenia sitä varten. Purussa olevilla palvelimilla vakavasti otettavat pitivät juuri tämän vuoksi lainaus- ja viittaustyökaluja vähäkitkaisina.
Mitä on rajattava
Varaaminen, peruuttaminen, vastaanottajan vaihtaminen, osoitteen muokkaaminen, dokumentin hakeminen – kaikki, mikä liittyy laskuun. Jokainen näistä muuttaa todellista maailmaa, ja jokainen vaatii sen taakseen todennetun, valtuutetun ja auditoitavan kutsun. Noudattamamme sääntö on helppo todeta ja vaikeampi panna täytäntöön: lukutyökalu voi olla avoin, kirjoitustyökalu ei koskaan.
OAuth 2.1 ja PKCE, ei pitkäikäistä avainta konfiguraatiotiedostossa
MCP-valtuutusmäärittelyyn valittiin OAuth 2.1 etäpalvelimille, ja tällä valinnalla on todellista merkitystä kuljetusalalle. Staattinen API-avain, joka liitetään konfiguraatiotiedostoon, sopii yksittäiselle kehittäjälle, joka pyörittää palvelinta stdio:n yli omalla koneellaan. Se on väärä malli heti, kun palvelin on tavoitettavissa HTTP:n yli ja agentti toimii nimetyllä käyttäjällä jaetun tilin sisällä.
Kolme ominaisuutta tekevät raskaimman työn. Skovatut tokenit tarkoittavat, että lainausta varten luotu token ei voi tehdä varausta. Lyhytikäiset tokenit tarkoittavat, että vuotanut tunniste vanhenee itsestään sen sijaan, että se eläisi ikuisesti lokissa. Peruuttuvat tokenit tarkoittavat, että kun jokin näyttää vialliselta, pääsy katkaistaan sekunneissa sen sijaan, että vaihdettaisiin jaettua avainta, johon kaikki luottavat. OAuth 2.1 vaatii myös PKCE:n valtuutuskoodivirrassa, mikä sulkee vanhempien OAuth-käyttöönottojen jättämän sieppausaukon. Mikään tästä ei ole eksoottista. Se on sama vahvistus, jonka minkä tahansa maksu-API:n läpi kävi, sovellettuna hetkeen, jolloin agentti sanoo "varaa se".
Tässä on raja, jonka toteutamme, esitettynä taulukkona, jonka toivoisin jokaisen tavarapalvelimen julkaisevan.
| Agentin toiminta | Lukee tai kirjoittaa | Vahvistus, jota tarvitsemme | Jos jokin menee vikaan |
| Pyydä tarjous | Lue | Avoin tai perusavain | Hukkaan mennyt puhelu, ei vahinkoa |
| Tarkista kapasiteetti, kuljetus, seuranta | Lue | Avoin tai perusavain | Huonoin tapauksessa vanhentunut vastaus |
| Varaa lähetys | Kirjoita | Scoped OAuth-token, vahvistusvaihe | Todellinen hinta, todellinen kuorma-auto |
| Peru tai uudelleenvaraa | Kirjoita | Scoped token, idempotenssiavain | Hukkunut paikka, rangaistus |
| Muuta vastaanottajaa tai osoitetta | Kirjoita | Määritelty tunniste, ihmisen vahvistus | Virheellinen toimitus, petos |
| Hae konossementti tai lasku | Lue herkkiä | Laajuuskohtainen tunniste, dokumenttikohtainen tarkistus | Tietovuoto ja asiakirjavuoto |
Taulukon kuvio on lopullinen tuotepäätös. Lukutoiminnot ovat vasemmalla ja pysyvät edullisina. Kirjoitustoiminnot ovat oikealla ja ansaitsevat "kitkansa".
Paljastetun instanssin ongelma
Yllättävän suuri osa MCP-riskeistä ei ole lainkaan ovelia. Se on palvelin, jonka oli tarkoitus pyöriä paikallisesti, mutta se on avattu avoimeen internetiin ilman tunnistautumista, koska sen toimittaminen siten oli helpompaa. Protokolla tukee kahta kuljetustapaa. Stdio-palvelin toimii paikallisena prosessina, jonka asiakas käynnistää, mikä pitää sen koneellasi eikä verkossa. Isännöity HTTP-palvelin on kaikkien sen URL-osoitteen löytävien saavutettavissa.
Vain lukutilassa olevan palvelinapuohjelman HTTP-paljastus on enimmäkseen vaaratonta. Varaustyökaluja sisältävälle se on koko peli. Jos kirjoitustyökalusi ovat saavutettavissa julkisen HTTP:n kautta, todennus ei ole ominaisuus, jonka lisäät myöhemmin, vaan se on se asia, joka seisoo muukalaisen ja lähetysjonosi välissä. Sääntömme on, että varaus- ja dokumentointityökaluja ei koskaan tarjoilla todennuksen ulkopuolisen HTTP-päätepisteen kautta, piste. Jos olet epävarma, kirjoitusoikeudet omaavan palvelimen tulisi oletusarvoisesti käyttää stdio-liitäntää ja paikallista käynnistystä, ja siirtyä vasta isännöityyn HTTP:hen, kun yllä oleva OAuth-virta on asetettu.
Kuvauskerroksen puolustaminen työkaluille myrkyttämistä vastaan
Koska työkalujen kuvaukset ohjaavat mallia, ne ansaitsevat samanlaiset hallintakeinot kuin käyttöösi ottamasi koodi. Kolme tapaa kattaa suurimman osan altistuksesta.
- Kiinnitä ja tarkista palvelimet, joihin yhdistät. Agentti, joka on kytketty valikoituun joukkoon tunnettuja palvelimia, on pienempi kohde kuin agentti, joka asentaa mitä tahansa rekisteri tarjoaa. Käsittele uutta palvelinta kuin uutta riippuvuutta, koska sitä se on.
- Pidä ihmisen vahvistus jokaisessa kirjoituksessa. Vahvistusvaihe ennen rahdinkantajan varaamista, peruuttamista tai muuttamista muuttaa hiljaisen, sisään syötetyn ohjeen näkyväksi pyynnöksi, jonka käyttäjä voi evätä. Se on halvin tapa valvoa toimintoja, jolla on suurin hyöty.
- Tarkista API:ssa, älä kehotteessa. Palvelimen tulisi tarkistaa uudelleen jokainen saamansa parametri tilin todellisten käyttöoikeuksien ja varauksen todellisen tilan perusteella sen sijaan, että se luottaisi mallin tuottamaan järkevään kutsuun. Malli ehdottaa, API päättää.
Mitä markkinapaikan palvelimen täytyy valvoa, jotta yksittäinen operaattori voi ohittaa
Yksittäisen verkon palvelin toimii aina vain omassa verkossaan, joten sen vaikutusalue on yksi operaattori. Markkinapaikkapalvelin tarjoaa hintoja ja varaa monilta operaattoreilta useiden käyttäjien puolesta, mikä muuttaa tietoturvatehtävää kahdella tavalla.
Ensinnäkin, rajaukset on tehtävä käyttäjäkohtaisesti ja operaattorikohtaisesti, ei palvelinkohtaisesti. Tokeni, joka antaa asiamiehelle mahdollisuuden varata lentolipun yhdeltä operaattorilta, ei saa salaa ulottua toiseen, eikä yhden asiakkaan asiamies saa koskaan nähdä toisen asiakkaan asiakirjoja. Toiseksi, tarkastusloki on tärkeämpi, koska kun asiamies tekee varauksen markkinapaikan kautta, sinun on vastattava jokaista kirjoitusta koskevaan kysymykseen "mikä käyttäjä, mikä tokeni, mikä operaattori, mihin aikaan". Käsittelemme kyseistä lokia osana tuotetta, emme jälkikäteen tehtävänä, koska sen avulla voimme peruuttaa rajatusti sen sijaan, että lopettaisimme kaiken toiminnan.
Käytännön tarkistuslista ennen kuin julkaiset varauksen
- Jaa työkalut luku- ja kirjoitustoimintoihin ja kirjaa jako ylös paikkaan, jossa agentti ja tiimisi voivat nähdä sen.
- Pidä lainaus- ja viittaustyökalut helppokäyttöisinä, jotta päivittäinen arvo säilyy.
- Aseta kaikki kirjoitukset rajattuun, lyhytikäiseen ja peruutettavaan OAuth 2.1 -tokeniin PKCE:n kanssa.
- Vaaditaan vahvistusvaihe varauksen, peruutuksen, vastaanottajan ja osoitteen muutoksille.
- Tarkista kaikki API:n parametrit uudelleen todellisten käyttöoikeuksien ja todellisen lähetystilan perusteella.
- Älä koskaan tarjoile kirjoitustyökaluja suojaamattoman HTTP:n yli, ja oletuksena kirjoituskelpoiset palvelimet tulisi ohjata paikalliseen stdioon.
- Kiinnitä palvelimet, joihin agenttisi yhdistää, ja tarkista uudet palvelimet samoin kuin uusi koodi.
- Kirjaa kaikki kirjoitukset käyttäjän, tunnisteen, kuljetusliikkeen ja kellonajan mukaan, ja harjoittele peruutusta ennen kuin tarvitset sitä.
Mikään näistä ei ole yksinomaan tekoälylle. Ne ovat ohjaimia, joita rahti ja maksut jo käyttävät, osoitettuna uuteen paikkaan, josta ohje voi alkaa. Agentti on uusi soittaja, ei uusi sääntöjoukko.
Usein kysytyt kysymykset
Onko tekoälyagentin salliminen kuljetusten varaaminen ylipäätään turvallista?
Kyllä, kun varaus tapahtuu autentikoidun ja valtuutetun, todennusvaiheen sisältävän puhelun jälkeen, ja kun palvelin tarkistaa jokaisen parametrin luottamatta malliin. Turvaton versio on avoin kirjoitustyökalu ilman ihmistä prosessissa. Käsittele varausta kuten mitä tahansa muuta rahaa liikuttavaa toimenpidettä, ja agentti tulee toiseksi autentikoiduksi kutsujaksi.
Miksi käyttää OAuth 2.1:tä pelkän API-avaimen sijaan?
Staattinen avain on yleensä pitkäikäinen, laajasti rajattu ja vaikeasti peruutettavissa ilman häiriöitä kaikille sitä jakaville. OAuth 2.1 tarjoaa laajuudeltaan rajattuja, lyhytikäisiä, peruutettavissa olevia tokeneita ja vaatii PKCE:n käyttöä valtuutusprosessissa. Paikalliselle stdio-palvelimelle avain on hyväksyttävä, mutta kaikkeen HTTP:n kautta saavutettavaan, joka voi kirjoittaa, tulee käyttää OAuth-mallia.
Mikä on työkalusalaus MCP:ssä?
Työkalumyrkytys tarkoittaa sitä, kun palvelimen työkalukuvaus, jota agentti lukee päättääkseen, mitä kutsua, sisältää piilotettuja ohjeita, jotka ohjaavat mallia haitallisiin toimiin, kuten avaimen vuotamiseen tai lähetyksen uudelleenohjaamiseen. Koska kuvaus vaikuttaa käyttäytymiseen, puolustat sitä samalla tavalla kuin koodia: kiinnitä luotetut palvelimet, pidä ihminen kirjoittajina ja validoi API:ssa.
Pitäisikö freighthuolinnan MCP-palvelimen käyttää stdio- vai hostattua HTTP-liikennöintiä?
Vain lukuoikeudellinen apupalvelin on ok isännöidyn HTTP:n yli. Varaus- tai dokumentointityökaluja sisältävän palvelimen tulisi oletusarvoisesti käyttää paikallista stdio-liitäntää ja siirtyä isännöityyn HTTP:hen vasta, kun palvelinlaajuinen OAuth on käytössä, koska ilman todennusta käytettävissä oleva kirjoituspäätepiste on kenen tahansa löydettävissä oleva.
Tämä sulkee tämän sarjan avaaman kehän. Jos et ole lukenut aiempia osia, Protokollaprimeri selittää, miten rahtirajapinnasta tulee työkalupakki, ja purku näyttää, missä lähetetyt palvelimet ovat tehneet näitä rajauksia käytännössä.