Nelle ultime due parti di questa serie ho trattato come il protocollo di contesto del modello si mappa su un'API merci e poi abbatté i server MCP per il trasporto spediti nel 2026. Entrambe sono terminate con la stessa domanda aperta, quindi questa parte risponde direttamente: una volta che un agente può prenotare merci reali, come si impedisce che prenoti la cosa sbagliata per la persona sbagliata? La sicurezza è dove un server MCP di trasporto merci smette di sembrare un giocattolo per sviluppatori e inizia ad assomigliare a un sistema che gestisce denaro e camion.
Gestisco questa attività dalla sede di un marketplace che espone un'API, quindi il mio punto di vista è pratico piuttosto che accademico. Le minacce riportate di seguito sono quelle che effettivamente modelliamo quando decidiamo quale strumento un agente può chiamare senza un operatore umano.
Perché un server per il trasporto merci alza la posta in gioco
Un server MCP generico che legge il tuo calendario, in caso di errore, divulga informazioni. Un server di trasporto merci che prenota un carico fa qualcosa di più costoso. Una chiamata errata può inviare un camion al piazzale sbagliato, cambiare un destinatario su una spedizione in corso, annullare una prenotazione su cui un cliente conta o ritirare una polizza di carico che non avrebbe mai dovuto lasciare l'account. Questi non sono bug di esposizione dati. Sono denaro e merci fisiche che si spostano su un'istruzione che nessuno ha digitato.
Questa differenza riformula l'intero problema. Con un assistente di chat, il peggio che può succedere è una risposta imbarazzante. Con il trasporto merci, il peggio che può succedere ha allegata una fattura di trasporto e una spedizione dove non dovrebbe essere. Quindi la domanda non è mai "questo server è sicuro" in astratto. È "quali azioni specifiche può intraprendere un agente e quanto costa ognuna se qualcosa va storto."
I due scenari catastrofici su cui preoccuparsi davvero
La maggior parte dei rischi di MCP nel 2026 si riduce a due schemi, e il trasporto merci li aggrava entrambi.
Prompt injection è il vecchio problema del web vestito a nuovo. Un agente legge del testo da una fonte che non controlla completamente, una nota di spedizione, un PDF, il corpo di un'e-mail, e quel testo contiene un'istruzione che il modello esegue. Nel settore delle spedizioni, il testo avvelenato arriva attraverso canali legittimi tutto il giorno: un commento di prenotazione, una descrizione doganale, un aggiornamento di stato di un vettore. Se il tuo strumento di prenotazione si fida di qualsiasi cosa il modello gli passi, una frase nascosta in una nota di consegna può diventare una cancellazione reale.
Il **tool poisoning** è più subdolo e specifico per MCP. Il protocollo consente a un server di descrivere i propri strumenti e l'agente legge tali descrizioni per decidere cosa chiamare. Un server malintenzionato o compromesso può scrivere una descrizione che dice silenziosamente al modello di esfiltrare una chiave API o reindirizzare una spedizione, e l'utente non vedrà mai quel testo. Anthropic e ricercatori indipendenti hanno trascorso i primi mesi del 2026 documentando varianti di questo problema, e la lezione per il trasporto merci è chiara: il livello di descrizione è eseguibile, quindi tratta una descrizione di strumenti di terze parti con lo stesso sospetto con cui tratteresti il codice di terze parti.
Lettura contro scrittura: la linea che dovrebbe definire la tua autorizzazione
La decisione di sicurezza più utile che ho preso è stata smettere di pensare al "server MCP" come a un unico confine di fiducia e suddividerlo in base a ciò che ogni strumento fa nel mondo.
Cosa può rimanere aperto
Citare una tratta, elencare la capacità, calcolare una stima del transito, cercare un codice portuale. Nessuna di queste cose cambia nulla. Permettere a un agente di raggiungerli con poco o nessun attrito è il punto centrale, ed è dove risiede il valore quotidiano. Un lettore che desidera confrontare tre percorsi non dovrebbe dover coniare un token per farlo. Attraverso i server nello smontaggio, quelli seri hanno mantenuto gli strumenti di quotazione e di riferimento a basso attrito proprio per questo motivo.
Cosa deve essere bloccato
Prenotare, cancellare, modificare un destinatario, modificare un indirizzo, estrarre un documento, qualsiasi cosa riguardi una fattura. Ognuna di queste azioni scrive nel mondo reale, e ognuna necessita di una chiamata autenticata, autorizzata e verificabile. La regola che seguiamo è semplice da enunciare e più difficile da applicare: uno strumento di lettura può essere aperto, uno strumento di scrittura mai.
OAuth 2.1 e PKCE, nessuna chiave a lunga durata in un file di configurazione
La specifica di autorizzazione MCP ha scelto OAuth 2.1 per i server remoti, e tale scelta ha un peso reale per il settore dei trasporti. Una chiave API statica incollata in un file di configurazione va bene per uno sviluppatore singolo che esegue un server tramite stdio sulla propria macchina. È il modello sbagliato nel momento in cui il server è raggiungibile tramite HTTP e un agente agisce per conto di un utente con nome all'interno di un account condiviso.
Tre proprietà svolgono il lavoro più importante. I token **scoped** (con ambito) significano che un token creato per il quoting non può effettuare prenotazioni. I token **short-lived** (a breve termine) significano che una credenziale trapelata scade da sola invece di rimanere per sempre in un log. I token **revocable** (revocabili) significano che quando qualcosa non va, si revoca l'accesso in pochi secondi invece di ruotare una chiave condivisa da cui tutti dipendono. OAuth 2.1 richiede anche PKCE nel flusso authorization-code, che chiude il divario di intercettazione che le vecchie implementazioni OAuth lasciavano aperto. Nulla di tutto ciò è esotico. È il necessario indurimento che ogni API di pagamento ha subito, applicato al momento in cui un agente dice "prenota".
Ecco la forma del confine che applichiamo, scritta come la tabella che vorrei ogni server di trasporto merci pubblicasse.
| **Azione dell'agente** | **Legge o scrive** | Autenticazione richiesta | Se va storto |
| Richiedi un preventivo | Leggere | Chiave aperta o base | Chiamata persa, nessun danno |
| Verificare capacità, transito, tracciabilità | Leggere | Chiave aperta o base | Risposta obsoleta nel peggiore dei casi |
| Prenota una spedizione | Scrivi | Token OAuth con ambito, passaggio di conferma | Costo reale, camion reale |
| Annulla o riprenota | Scrivi | Token con ambito, chiave di idempotenza | Slot perso, penalità |
| Cambia destinatario o indirizzo | Scrivi | Token ambito, conferma umana | Consegna errata, frode |
| Emetti una polizza di carico o una fattura | Leggi sensibile | Token con ambito, controllo per documento | Fuga di dati e documenti |
Il modello in quella tabella è la decisione effettiva del prodotto. Le letture si trovano a sinistra e restano economiche. Le scritture si trovano a destra e guadagnano il loro attrito.
Il problema dell'istanza esposta
Una quantità sorprendente di rischio MCP non è affatto astuta. Si tratta di un server che doveva essere eseguito localmente, esposto a Internet senza autenticazione, perché spedirlo in quel modo era più facile. Il protocollo supporta due trasporti. Un server stdio viene eseguito come processo locale avviato dal client, mantenendolo sulla tua macchina e fuori dalla rete. Un server HTTP ospitato è raggiungibile da chiunque possa trovarne l'URL.
Per un server di utilità di sola lettura, l'esposizione HTTP è per lo più innocua. Per uno con strumenti di prenotazione è tutta un'altra storia. Se i tuoi strumenti di scrittura sono raggiungibili tramite HTTP pubblico, l'autenticazione non è una funzionalità che aggiungi in seguito, è la cosa che si interpone tra uno sconosciuto e la tua coda di dispatch. La nostra regola è che gli strumenti di prenotazione e documentazione non vengono mai serviti tramite un endpoint HTTP non autenticato, punto. In caso di dubbio, un server capace di scrittura dovrebbe utilizzare di default stdio e il lancio locale, e solo passare all'HTTP ospitato una volta che il flusso OAuth sopra descritto è attivo.
Difendere il livello di descrizione dall'avvelenamento degli strumenti
Poiché le descrizioni degli strumenti guidano il modello, meritano gli stessi controlli del codice che si distribuisce. Tre abitudini coprono la maggior parte dell'esposizione.
- **Blocca e recensisci i server a cui ti connetti.** Un agente collegato a un set curato di server noti rappresenta un bersaglio più piccolo rispetto a uno che installa qualsiasi cosa un registro offra. Tratta un nuovo server come una nuova dipendenza, perché di questo si tratta.
- Mantieni un umano per ogni operazione. Un passaggio di conferma prima di prenotare, annullare o modificare un destinatario trasforma un'istruzione silenziosamente inserita in una richiesta visibile che l'utente può rifiutare. È il controllo più economico con il rendimento più elevato.
- Convalida all'API, non nel prompt. Il server dovrebbe ricontrollare ogni parametro che riceve rispetto alle autorizzazioni reali dell'account e allo stato effettivo della prenotazione, anziché fidarsi che il modello abbia assemblato una chiamata sensata. Il modello propone, l'API decide.
Cosa deve imporre un server marketplace affinché un singolo corriere possa saltare
Un server a portante singola agisce sempre sulla propria rete, quindi il suo raggio d'azione è un operatore. Un server di marketplace cita e prenota per conto di molti utenti, attraverso numerosi vettori, il che modifica il lavoro di sicurezza in due modi.
Innanzitutto, lo scoping deve essere per utente e per operatore, non per server. Un token che consente a un agente di effettuare una prenotazione con un operatore non deve raggiungere silenziosamente un altro, e l'agente di un cliente non deve mai vedere i documenti di un altro cliente. In secondo luogo, la traccia di audit è più importante, perché quando un agente prenota attraverso un marketplace è necessario rispondere "quale utente, quale token, quale operatore, a che ora" per ogni scrittura. Consideriamo quel log come parte del prodotto, non come un ripensamento, poiché è ciò che ci consente di revocare in modo mirato invece di disattivare tutto per tutti.
Una checklist pratica prima di rendere pubblica la prenotazione
- Dividi gli strumenti per lettura e scrittura, e scrivi la divisione dove sia l'agente che il tuo team possano vederla.
- Mantieni gli strumenti di quotatura e riferimento a basso attrito in modo che il valore quotidiano sopravviva.
- Metti ogni scrittura dietro un token OAuth 2.1 con ambito limitato, di breve durata e revocabile, con PKCE.
- Richiedi un passaggio di conferma per modifiche alla prenotazione, cancellazione, destinatario e indirizzo.
- Rivaluta ogni parametro dell'API rispetto ai permessi effettivi e allo stato effettivo della spedizione.
- Non inviare mai strumenti di scrittura tramite HTTP non autenticato e impostare predefiniti i server in grado di scrittura su stdio locale.
- Blocca i server a cui si connette il tuo agente e rivedi quelli nuovi come un nuovo codice.
- Registra ogni scrittura con utente, token, vettore e ora, e prova la revoca prima che ti serva.
Nessuno di questi è unico dell'intelligenza artificiale. Sono i controlli che trasporto e pagamenti utilizzano già, puntati sul nuovo luogo da cui può nascere un'istruzione. L'agente è un nuovo chiamante, non un nuovo set di regole.
Domande frequenti
È sicuro far prenotare merci a un agente AI in generale?
Sì, quando la prenotazione avviene tramite una chiamata autenticata e autorizzata con un passaggio di conferma, e quando il server ricontrolla ogni parametro anziché fidarsi del modello. La versione insicura è uno strumento di scrittura aperto senza intervento umano. Tratta la prenotazione come qualsiasi altra azione che muove denaro e l'agente diventa un altro chiamante autenticato.
Perché usare OAuth 2.1 invece di una semplice API key?
Una chiave statica tende ad avere una lunga durata, un ambito ampio e a essere difficile da revocare senza interrompere tutti coloro che la condividono. OAuth 2.1 fornisce token con ambito definito, di breve durata e revocabile, e richiede il PKCE nel flusso di autorizzazione. Per un server stdio locale una chiave è accettabile, ma qualsiasi cosa raggiungibile tramite HTTP che possa scrivere dovrebbe utilizzare il modello OAuth.
Cos'è il tool poisoning in MCP?
Il "tool poisoning" si verifica quando la descrizione di uno strumento di un server, che l'agente legge per decidere quale chiamare, contiene istruzioni nascoste che inducono il modello a compiere azioni dannose come la fuga di una chiave o il reindirizzamento di una spedizione. Poiché la descrizione influenza il comportamento, la si difende nel modo in cui si difende il codice: bloccare i server fidati, mantenere un essere umano responsabile degli aggiornamenti e convalidare a livello di API.
Un server MCP di trasporto dovrebbe essere eseguito come stdio o come hosted HTTP?
Un server di utilità in sola lettura va bene su HTTP ospitato. Un server con strumenti di prenotazione o documenti dovrebbe impostare di default stdio locale e passare a HTTP ospitato solo una volta implementato OAuth con ambito, perché un endpoint di scrittura esposto senza autenticazione è raggiungibile da chiunque trovi l'URL.
Questo chiude il cerchio che questa serie ha aperto. Se non hai letto le parti precedenti, Manuale del protocollo spiega come un'API di spedizione diventa un insieme di strumenti, e smantellamento mostra dove i server spediti hanno tracciato queste linee nella pratica.