La nuova specifica MCP trasferisce le responsabilità di sicurezza agli sviluppatori. Scopri i rischi e come mitigarli in produzione.
La nuova specifica del Model Context Protocol (MCP) di Anthropic, lanciata a giugno 2026, trasferisce le responsabilità di sicurezza direttamente agli sviluppatori. Prima le gestiva il protocollo stesso. Adesso tocca a voi.
Questo cambio non è una novità. I team che deployano Claude con MCP in produzione, Simple Booking nel settore ricettivo, X con i suoi MCP server per gli agenti IA, si pongono già la domanda: dove esattamente sono i buchi?
Lo shift di responsabilità: da dove viene il problema
La nuova specifica MCP è enterprise-ready, vero. Ma questa parola nasconde una realtà: Anthropic ha deliberatamente spostato una parte dei controlli di sicurezza verso il layer sviluppatore per guadagnare flessibilità.
Concretamente, significa tre cose:
1. Niente più autenticazione implicita
Prima, MCP includeva meccanismi di sicurezza di default. Adesso, devi costruire tu la catena di autenticazione. Un'agenzia e-commerce Shopify che connette Claude a una base clienti deve gestire come un agente Claude accede ai dati sensibili, nomi, email, numeri di telefono. Non c'è magia qui.
2. I permessi granulari diventano un tuo problema
MCP non dice più "questo tool può leggere ma non scrivere". Lo dici tu. Un agente potrebbe potenzialmente eseguire un'azione per la quale non è autorizzato se non hai messo delle barriere. Simple Booking conosce questo dilemma: i loro MCP connector integrano un CRS (Central Reservation System), tocca direttamente le prenotazioni clienti. Un permesso configurato male = una prenotazione modificata per errore.
3. Le injection prompt diventano più critiche
Claude è intelligente, ma se un agente MCP accetta un'istruzione dall'esterno senza validazione, "chiama lo strumento X con il parametro Y", hai appena creato un'entrata per un attaccante. Gli avversari non cercano di hackare il protocollo. Cercano di manipolare il tuo agente.
I quattro pericoli concreti che incontrate
Pericolo 1: le credenziali esposte nelle variabili d'ambiente
Il classico. Il tuo server MCP ha bisogno di una chiave API per parlare a un database. La metti in .env. OK fino a qui. Se non che il vostro container Docker o la vostra funzione AWS Lambda espone queste variabili nei log se mai va in crash.
Con MCP, ogni errore di connessione al server risale a Claude. Claude lo logga. E se Claude è in debug mode o se i log non sono cifrati, ciao ciao la tua chiave.
Mitigazione: usate un gestore di segreti (Vault, AWS Secrets Manager). Iniettate le credenziali a runtime, mai in duro.
Pericolo 2: fiducia cieca verso il server MCP
Deployi un server MCP che espone 15 strumenti. Claude è connesso. Un dev junior aggiunge un nuovo strumento che cancella registri clienti. Senza una revue di accesso, Claude può chiamarlo.
Peggio: se questo server è sulla tua rete interna e qualcuno compromette un'altra macchina in rete, può fare pivot per inviare comandi MCP falsificati.
Mitigazione: ogni strumento MCP deve avere una lista esplicita di chi può chiamarlo. Claude? Sì, ma solo se risponde a X criteri. Audit degli strumenti regolarmente.
Pericolo 3: i timeout infiniti che bloccano
Un server MCP risponde lentamente o non risponde. Claude aspetta. Nel frattempo, una richiesta utente ristagna, la sessione rimane aperta, la memoria gonfia. Non è una falla di sicurezza diretta, ma crea vettori di DoS.
Peggio se è intenzionale: qualcuno invia una richiesta che forza MCP a fare un'operazione molto lunga (una scansione di database gigantesca, un calcolo costoso).
Mitigazione: timeout rigoroso su ogni chiamata MCP. 5s, 10s massimo. Niente infinito.
Pericolo 4: niente log o log insufficienti
Se Claude chiama uno strumento MCP e non loggi l'azione, il timestamp, i parametri, il risultato, non hai alcuna tracciabilità. Un'agenzia alberghiera che scopre 500 prenotazioni cancellate non avrà alcuna pista per risalire a quello che è successo.
Le difese da mettere in place
1. Autenticazione forte tra claude e il tuo server MCP
MCP usa JSON-RPC su una connessione stdio o HTTP. Se è HTTP, usate HTTPS + un token Bearer valido. Meglio ancora: mTLS con certificati client.
Test: il tuo server MCP deve rifiutare qualsiasi richiesta senza autenticazione valida. Niente eccezioni.
2. Autorizzazione per ruolo (rbac) o per attributi (abac)
Definite esplicitamente chi può chiamare quale strumento.
| Ruolo Agente | Strumenti autorizzati | Parametri limitati |
|---|---|---|
| ReadOnlyAnalyst | GetBookings, GetReviews | Nessun parametro sensibile |
| ReservationManager | CreateBooking, ModifyBooking | Modifiche < 3 giorni prima dell'arrivo |
| Admin | Tutti | Nessun limite |
Implementate questo nel vostro server MCP. Prima di eseguire uno strumento, verificate il ruolo di Claude (o più precisamente, il contesto della sessione che lo usa).
3. Validazione e sanitizzazione rigorosa
Ogni parametro ricevuto da MCP deve essere validato:
- Tipo corretto (stringa, numero, etc.)
- Lunghezza limitata (non 10 MB di testo in un campo)
- Formato validato (una data è veramente una data, un email è veramente un email)
- Nessun carattere escapato che potrebbe fare una injection SQL
// Esempio: endpoint che crea una prenotazione
// SBAGLIATO
app.post('/MCP/create-booking', (req, res) -> {
const booking = req.body; // Pericolo diretto
db.insertBooking(booking);
});
// CORRETTO
app.post('/MCP/create-booking', (req, res) -> {
const schema = z.object({
clientId: z.string().uuid(),
checkIn: z.string().date(),
nights: z.number().min(1).max(365),
roomType: z.enum(['single', 'double', 'suite'])
});
const validated = schema.parse(req.body); // Throw se invalido
db.insertBooking(validated);
});
4. Log esaustivo con contesto
Ogni chiamata MCP deve essere loggata con:
- Timestamp esatto
- Identità dell'agente (o del contesto che lo usa)
- Strumento chiamato + parametri completi
- Risultato (successo, errore, eccezione)
- Durata di esecuzione
- Indirizzo IP sorgente (se pertinente)
Memorizzate questi log in un sistema immutabile (CloudWatch, Splunk, o un semplice file append-only cifrato).
5. Monitoraggio e alert in tempo reale
Rilevate le anomalie:
- Troppi appelli a uno strumento in poco tempo -> tentativo di DoS
- Uno strumento chiamato con parametri anomali -> fuzz attack
- Errori ripetuti -> ricognizione o vuln scanning
Configurate un alert se Claude chiama 100 volte "GetUserData" in 30s.
Il caso studio: X e i suoi MCP server
X (precedentemente Twitter) ha lanciato MCP server affinché Claude, Cursor, Grok Build e altri AI tool potessero accedere a X direttamente. È la stessa logica di Simple Booking e le prenotazioni alberghiere.
La differenza: i dati su X sono pubblici di default. Un agente può recuperare tweet senza danno. Ma se avessi un X MCP server che esponesse i DM privati o gli analytics interni, lo scenario cambierebbe completamente.
Anthropic e X hanno assunto che gli sviluppatori che integrano questi server sapranno mettere delle barriere. Spoiler: non sempre è così.
Domande frequenti
Bisogna cifrare la comunicazione MCP anche su localhost?
Sì se dati sensibili transitano. Se è solo calcolo innocuo (convertire una temperatura Celsius in Fahrenheit), no. Ma non appena c'è cliente, account, pagamento: cifrate.
Qual è la differenza tra MCP e un'API REST classica dal punto di vista della sicurezza?
Fondamentalmente: nessuna. MCP è solo una convenzione JSON-RPC. Gli stessi principi di sicurezza si applicano. La differenza è che molti dev pensano che perché è "per IA", è meno critico. Errore.
Come testare la sicurezza del mio server MCP?
Fare fuzzing: inviare parametri casuali, stringhe giganti, null, caratteri strani. Usare tool come Burp Suite per intercettare le chiamate MCP. Tentare un'injection SQL su ogni parametro. Misurare i timeout. Cercare bypass di ruolo.
C'è una certificazione o uno standard per MCP sicuro?
Non ancora. MCP è troppo giovane. Anthropic pubblica raccomandazioni ma nulla di ufficiale. Al contrario, applicate gli standard di sicurezza API classici: OWASP Top 10, funziona.
Come gestire MCP se l'agente claude ha bisogno di diritti amministrativi?
Scenario da incubo: devi dare a Claude la capacità di cancellare dati. Opzione 1: dargli uno strumento separato "DeleteWithConfirmation" che chiede un'approvazione umana (dici al sistema "approva l'agente per questa azione"). Opzione 2: strumenti granulari con ruoli molto limitati. Opzione 3: non farlo affatto e usare un umano per le operazioni distruttive.
L'autenticazione tra claude e MCP è sufficiente, o bisogna anche proteggere claude -> anthropic?
Entrambi. Devi fidarti del tubo tra Claude e il tuo server. Ma devi anche fidarti di Anthropic per non loggare/esporre i tuoi dati. Anthropic ha garanzie di confidenzialità per i piani Enterprise. Controllate il vostro contratto.
Conclusione
La nuova specifica MCP di Anthropic è più flessibile ma meno sicura di default. La sicurezza non è più incorporata. Dipende da te.
I tre riflessi da avere:
- Autenticazione forte tra Claude e MCP, HTTPS + token, mTLS se possibile.
- Autorizzazione granulare, ogni strumento ha una lista esplicita di chi può chiamarlo e come.
- Osservabilità completa, ogni chiamata è loggata, controllabile, allertabile.
Se deployi MCP in produzione senza questi tre pilastri, stai giocando alla roulette russa. E spoiler: il proiettile finirà per essere nella camera.
Hai bisogno di aiuto per proteggere la tua implementazione MCP? Parliamo della tua architettura su fstck.co, abbiamo casi reali in ricettività, e-commerce e fintech.
