În ultimele două părți ale acestei serii am acoperit Cum se mapează Protocolul de context al modelului pe o API de transport de marfă și apoi a dărâmat serverele MCP de transport care au fost livrate în 2026. Ambele s-au încheiat cu aceeași întrebare deschisă, așa că această parte răspunde direct: odată ce un agent poate rezerva transport real, cum îl oprești să rezerve lucrul greșit pentru persoana greșită? Securitatea este locul unde un server MCP de transport încetează să mai arate ca o jucărie de dezvoltator și începe să arate ca un sistem care mută bani și camioane.
Rulez din poziția unui centru de comerț care expune un API, deci părtinirea mea este practică, nu academică. Amenințările de mai jos sunt cele pe care le modelăm efectiv atunci când decidem ce instrument poate apela un agent fără un om implicat.
De ce un server de transport crește miza
Un server MCP generic care citește calendarul dvs. scapă informații atunci când eșuează. Un server de transport care rezervă o încărcătură face ceva mai costisitor. Un apel greșit poate trimite un camion la depozitul greșit, poate schimba un destinatar pe o expediție activă, poate anula o rezervare pe care un client se bazează sau poate extrage o scrisoare de transport care nu ar fi trebuit să părăsească niciodată contul. Acestea nu sunt erori de expunere a datelor. Sunt bani și bunuri fizice în mișcare la o instrucțiune pe care nimeni nu a tastat-o.
Această diferență recontextualizează întreaga problemă. Cu un asistent de chat, cel mai rău caz este un răspuns jenant. În cazul transportului de marfă, cel mai rău caz implică o factură de transport atașată și o expediere într-un loc unde nu ar trebui să fie. Așadar, întrebarea nu este niciodată „este acest server sigur” în abstract. Este „ce acțiuni specifice poate întreprinde un agent și cât costă fiecare dacă merge prost”.
Cele două moduri de defectare pentru care merită să-ți faci griji
Cel mai mare risc MCP în 2026 se reduce la două tipare, iar transportul feroviar le agravează pe amândouă.
Injectarea de instrucțiuni este vechea problemă a web-ului, îmbrăcată în haine noi. Un agent citește text dintr-o sursă pe care nu o controlează complet, o notă de expediere, un PDF, corpul unui e-mail, iar acel text conține o instrucțiune pe care modelul o urmează. În domeniul transporturilor, textul otrăvit ajunge prin canale legitime tot timpul: un comentariu de rezervare, o descriere vamală, o actualizare de status a unui transportator. Dacă instrumentul dvs. de rezervare are încredere în orice transmite modelul, o propoziție ascunsă într-o notă de livrare poate deveni o anulare reală.
Otrăvirea uneltelor este mai subtilă și specifică MCP. Protocolul permite unui server să-și descrie propriile unelte, iar agentul citește acele descrieri pentru a decide ce să apeleze. Un server malițios sau compromis poate scrie o descriere care spune în tăcere modelului să exfiltreze o cheie API sau să redirecționeze o expediție, iar utilizatorul nu vede niciodată acel text. Anthropic și cercetătorii independenți au petrecut începutul anului 2026 documentând variante ale acesteia, iar lecția pentru transportul de marfă este clară: stratul de descriere este executabil, așa că tratați descrierea unei unelte de la terți cu aceeași suspiciune pe care ați trata-o pentru codul de la terți.
Citire versus scriere: linia care ar trebui să decidă autentificarea ta
Cea mai utilă decizie de securitate pe care am luat-o a fost să renunț la a mai gândi la "serverul MCP" ca la o singură graniță de încredere și să o împart în funcție de ceea ce face fiecare instrument în lume.
Ce poate rămâne deschis
Citarea unei rute, listarea capacității, calcularea unei estimări de tranzit, căutarea unui cod de port. Niciuna dintre acestea nu schimbă nimic. Permiterea unui agent să îi contacteze cu puțin sau deloc efort este punctul esențial, și aici stă valoarea zilnică. Un cititor care dorește să compare trei rute nu ar trebui să fie nevoit să creeze un token pentru a face acest lucru. Prin serverele din demontare, cele serioase au menținut instrumentele de citare și de referință cu efort redus exact din acest motiv.
Ce trebuie restricționat
Rezervarea, anularea, schimbarea unui destinatar, editarea unei adrese, extragerea unui document, orice care atinge o factură. Fiecare dintre acestea scrie în lumea reală, și fiecare necesită un apel autentificat, autorizat și auditat în spate. Regula pe care o urmăm este simplă de enunțat și mai greu de aplicat: un instrument de citire poate fi deschis, unul de scriere niciodată.
OAuth 2.1 și PKCE, nu o cheie de lungă durată într-un fișier de configurare
Specificația de autorizare MCP a stabilit OAuth 2.1 pentru serverele la distanță, iar această alegere are o greutate reală pentru transport. O cheie API statică introdusă într-un fișier de configurare este potrivită pentru un dezvoltator individual care rulează un server prin stdio pe propria mașină. Este modelul greșit din momentul în care serverul este accesibil prin HTTP și un agent acționează în numele unui utilizator numit, în cadrul unui cont partajat.
Trei proprietăți fac cea mai mare parte a muncii. Tokenurile izolate înseamnă că un token emis pentru cotație nu poate rezerva. Tokenurile temporare înseamnă că o credențială scursă expiră singură, în loc să trăiască pentru totdeauna într-un jurnal. Tokenurile revocabile înseamnă că, atunci când ceva pare greșit, tăiați accesul în secunde, în loc să rotiți o cheie partajată de care depind toți. OAuth 2.1 necesită, de asemenea, PKCE în fluxul de cod de autorizare, care închide decalajul de interceptare pe care implementările mai vechi de OAuth l-au lăsat deschis. Nimic din toate acestea nu este exotic. Aceasta este aceeași întărire prin care a trecut orice API de plăți, aplicată momentului în care un agent spune „rezervă”.
Aceasta este forma delimitării pe care o aplicăm, scrisă în tabelul pe care mi-aș dori ca fiecare server de transport să-l publice.
| **Acțiunea agentului** | Citește sau scrie | **Autentificarea necesară** | Dacă merge prost |
| Solicită o ofertă | Citește | Cheie deschisă sau de bază | Apel irosit, nicio pagubă |
| Verifică capacitatea, tranzitul, urmărirea | Citește | Cheie deschisă sau de bază | Răspuns depășit în cel mai bun caz |
| Rezervă o expediție | Scrieți | Token OAuth cu domeniu, pas de confirmare | Cost real, camion real |
| Anulare sau reprogramare | Scrieți | Token cu domeniu, cheie de idempotenta | Slot pierdut, penalizare |
| Schimbă destinatarul sau adresa | Scrieți | Token delimitat, confirmare umană | Livrare greșită, fraudă |
| Trage o scrisoare de transport maritim sau o factură | Citește sensibil | Token cu domeniu, verificare per document | Scurgere de date și documente |
Modelul din acel tabel este decizia reală de produs. Citirile stau în stânga și rămân ieftine. Scrierile stau în dreapta și își câștigă fricțiunea.
Problema instanței expuse
O cantitate surprinzătoare de risc de MCP nu este deloc ingenioasă. Este un server care a fost destinat să ruleze local, expus pe internetul deschis fără autentificare, deoarece livrarea lui în acest mod a fost mai ușoară. Protocolul suportă două transporturi. Un server stdio rulează ca un proces local pe care clientul îl lansează, ceea ce îl menține pe mașina ta și în afara rețelei. Un server HTTP găzduit este accesibil de orice lucru care îi poate găsi URL-ul.
Pentru un server utilitar "read-only" expunerea HTTP este, în mare parte, inofensivă. Pentru unul cu instrumente de rezervare, este totul. Dacă instrumentele dvs. de scriere sunt accesibile prin HTTP public, autentificarea nu este o caracteristică pe care o adăugați mai târziu, ci este ceea ce se află între un străin și coada dvs. de expediere. Regula noastră este că instrumentele de rezervare și de documente nu sunt niciodată servite printr-un punct final HTTP neautentificat, punct. Când aveți dubii, un server capabil de scriere ar trebui să utilizeze implicit stdio și lansarea locală, și să treacă la HTTP găzduit doar odată ce fluxul OAuth de mai sus este implementat.
Apărarea stratului de descriere împotriva otrăvirii instrumentelor
Deoarece descrierile instrumentelor ghidează modelul, acestea merită aceleași controale ca și codul pe care îl implementați. Trei obiceiuri acoperă majoritatea expunerii.
- Fixați și revizuiți serverele la care vă conectați. Un agent conectat la un set selectat de servere cunoscute este o țintă mai mică decât unul care instalează orice oferă un registru. Tratați un server nou ca pe o dependență nouă, deoarece asta este.
- Menține un om la fiecare scriere. Un pas de confirmare înainte de a rezerva, anula sau modifica un destinatar transformă o instrucțiune injectată silențios într-o cerere vizibilă pe care utilizatorul o poate refuza. Este cel mai ieftin control cu cel mai mare randament.
- Validați la API, nu în prompt. Serverul ar trebui să re-verifice fiecare parametru primit în raport cu permisiunile reale ale contului și starea reală a rezervării, în loc să aibă încredere că modelul a compus un apel logic. Modelul propune, API-ul decide.
Ce trebuie să impună un server de marketplace pentru ca un singur transportator să poată sări
Un server cu un singur transportator acționează întotdeauna doar în propria rețea, deci raza sa de acțiune este de un singur operator. Un server de tip marketplace citează și rezervă pentru mulți transportatori în numele multor utilizatori, ceea ce schimbă sarcina de securitate în două moduri.
În primul rând, domeniul de aplicare trebuie să fie per utilizator și per transportator, nu per server. Un token care permite unui agent să rezerve la un transportator nu ar trebui să ajungă silențios la altul, iar agentul unui client nu ar trebui să vadă niciodată documentele altui client. În al doilea rând, jurnalul de audit contează mai mult, deoarece atunci când un agent face rezervări pe o piață, trebuie să răspundă „care utilizator, ce token, ce transportator, la ce oră” pentru fiecare scriere. Considerăm acest jurnal ca parte a produsului, nu ca o idee ulterioară, deoarece acesta ne permite să revocăm în mod specific, în loc să oprim totul.
Un checklist practic înainte de a expune rezervarea
- Împarte instrumentele în funcție de citire și scriere și scrie rezultatul acolo unde atât agentul, cât și echipa ta îl pot vedea.
- Menține un număr redus de instrumente de citare și referință, astfel încât valoarea zilnică să supraviețuiască.
- Pune orice scriere în spatele unui token OAuth 2.1 scop, de scurtă durată, revocabil, cu PKCE.
- Necesită un pas de confirmare la rezervare, anulare și la modificarea destinatarului și adresei.
- Revalidați fiecare parametru la API față de permisiunile reale și starea reală a expedierii.
- Nu serviți niciodată instrumente de scriere prin HTTP neautentificat și setați serverele cu capacitate de scriere implicit la stdio local.
- Ancorează serverele la care se conectează agentul tău și revizuiește-le pe cele noi, la fel ca noul cod.
- Înregistrați fiecare scriere cu utilizatorul, token-ul, curierul și ora, și exersați revocarea înainte de a avea nevoie de ea.
Niciunul dintre acestea nu este unic pentru inteligența artificială. Acestea sunt controalele pe care transportul de marfă și plățile le folosesc deja, orientate către noul loc de unde poate proveni o instrucțiune. Agentul este un nou apelant, nu un nou set de reguli.
Întrebări frecvente
Este sigur să lași un agent AI să rezerve transport?
Da, când rezervarea se află în spatele unui apel autentificat și autorizat, cu un pas de confirmare, și când serverul reevaluează fiecare parametru, în loc să aibă încredere în model. Versiunea nesigură este un instrument de scriere deschis, fără supraveghere umană. Tratează rezervarea ca pe orice altă acțiune de mutare a banilor, iar agentul devine un alt apelant autentificat.
De ce să folosiți OAuth 2.1 în loc de o simplă cheie API?
O cheie statică tinde să fie de lungă durată, cu un domeniu larg și dificil de revocat fără a afecta pe toți cei care o partajează. OAuth 2.1 vă oferă tokenuri cu domeniu delimitat, de scurtă durată și revocabile și necesită PKCE în fluxul de autorizare. Pentru un server stdio local, o cheie este acceptabilă, dar orice sistem accesibil prin HTTP care poate scrie ar trebui să folosească modelul OAuth.
Ce este otrăvirea uneltelor în MCP?
Otravirea instrumentelor apare atunci când descrierea unui instrument pe un server, pe care agentul o citește pentru a decide ce să apeleze, conține instrucțiuni ascunse care direcționează modelul către acțiuni dăunătoare, cum ar fi scurgerea unei chei sau re-rutarea unei expedieri. Deoarece descrierea influențează comportamentul, o apărați așa cum apărați codul: fixați serverele de încredere, aveți o persoană care autorizează modificările și validați la API.
Un server MCP de expediere frecvență ar trebui să ruleze ca stdio sau găzduit HTTP?
Un server utilitar doar-citire este acceptabil peste HTTP găzduit. Un server cu instrumente de rezervare sau documente ar trebui, implicit, să folosească stdio local și să treacă la HTTP găzduit numai după ce este implementat OAuth cu scop, deoarece un punct de acces de scriere expus fără autentificare este accesibil oricui găsește URL-ul.
Aceasta închide cercul deschis de această serie. Dacă nu ați citit părțile anterioare, ghid de protocol explică cum un API de transport devine un set de instrumente, iar demontare arată unde serverele livrate au tras aceste linii în practică.