Sicurezza MCP nel 2026: il divario human-in-the-loop nella specifica

La specifica del Model Context Protocol ammette, in linguaggio chiaro, di non poter imporre l’approvazione umana prima che un tool AI agisca — quella garanzia è una raccomandazione per l’applicazione costruita sopra MCP, non una regola che MCP stesso verifica. Per qualsiasi agenzia che collega la propria AI, o quella di un cliente, a sistemi aziendali reali tramite MCP, quella singola frase è l’intero modello di rischio. Il protocollo dice alla tua AI quali tool esistono e cosa dichiarano di fare. Se un essere umano vede e approva effettivamente ciò che sta per accadere è interamente lasciato a chi ha costruito il client.

Cosa dice effettivamente la specifica MCP sul consenso?

La sezione “Key Principles” della specifica è diretta sui limiti di ciò che il protocollo garantisce:

“1. User Consent and Control — Users must explicitly consent to and understand all data access and operations… 3. Tool Safety — Tools represent arbitrary code execution and must be treated with appropriate caution… Hosts must obtain explicit user consent before invoking any tool.”

E subito dopo:

“While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD: Build robust consent and authorization flows into their applications…”

È il divario in un paragrafo. I principi sono scritti con “must” minuscolo, che secondo la convenzione seguita dalla specifica MCP significa raccomandazione, non requisito a livello di protocollo. La specifica Tools ripete la stessa struttura nel suo “User Interaction Model”: “there SHOULD always be a human in the loop with the ability to deny tool invocations,” insieme alla guida che le applicazioni “SHOULD… present confirmation prompts to the user for operations.” Raccomandato. Non applicato. Non qualcosa che un server MCP possa verificare che un client faccia effettivamente.

Non è un difetto unico di MCP — nessun protocollo può costringere un’applicazione costruita sopra di esso a comportarsi in un certo modo. Ma significa che “la nostra AI è connessa tramite MCP” non ti dice nulla su se un essere umano è effettivamente nel loop. È un’affermazione sulla specifica applicazione, e va verificata lì, non assunta dal nome del protocollo.

Cosa succede quando quel divario viene sfruttato

Tre incidenti documentati mostrano cosa costa il divario nella pratica, in tre punti diversi della catena.

Asana, giugno 2025 — il fallimento dell’isolamento. Asana ha lanciato un’integrazione MCP il 1° maggio 2025. Un bug di isolamento tra tenant è stato identificato il 4 giugno, e l’integrazione è stata messa offline per circa due settimane durante la correzione. Il difetto permetteva ai dati di un’organizzazione — task, metadati di progetto, dettagli del team, commenti e file caricati — di diventare visibili oltre i confini organizzativi. Circa 1.000 clienti sono stati colpiti, e la vulnerabilità esisteva dal primo giorno della funzione. Non era specificamente un fallimento human-in-the-loop — è un promemoria che il confine di isolamento attorno a ciò che un’integrazione MCP può raggiungere conta quanto chi approva la chiamata.

GitHub, maggio 2025 — il “toxic agent flow”. I ricercatori di sicurezza di Invariant Labs hanno dimostrato un attacco in cui uno sviluppatore chiedeva a un agente AI, connesso tramite il server MCP di GitHub, di revisionare issue aperte su un repository pubblico. Una issue piantata conteneva istruzioni nascoste. L’agente le ha lette, poi ha usato il proprio accesso già autorizzato ai repository privati dello sviluppatore per estrarre informazioni sensibili e pubblicarle in una pull request visibile sul repo pubblico. Ogni singola chiamata tool che l’agente ha fatto era una che l’utente aveva genuinamente autorizzato. Ciò che non era autorizzato — e ciò che nessun singolo prompt di approvazione avrebbe intercettato — era la combinazione: leggere una issue pubblica, poi agire su dati privati, poi pubblicare esternamente. La conclusione di Invariant è stata diretta: “This vulnerability cannot be resolved through server-side patches.” È un problema architetturale in come i permessi si compongono tra le chiamate tool, non un bug nel codice di GitHub.

Microsoft, 30 giugno 2026 — il divario della ri-approvazione. Il team di sicurezza di Microsoft ha pubblicato un avvertimento diretto su una meccanica incorporata nel modello di fiducia stesso: la descrizione di un tool — il testo che un utente legge e approva prima di lasciare che un’AI lo usi — può cambiare dopo quell’approvazione, e nulla nel protocollo richiede al client di chiedere di nuovo. Le parole di Microsoft: “In configurations where description changes do not trigger a re-approval workflow, the updated instructions become active without additional review.” Un tool che sembrava sicuro il primo giorno può essere ridefinito silenziosamente il trentesimo, e un utente che l’ha approvato una volta non ha motivo di sapere che è successo. Microsoft ha descritto MCP come “the fastest-growing part of the agentic AI supply chain” — ed è esattamente per questo che questo particolare divario conta di più ogni mese che resta irrisolto.

Accanto a questi, due CVE concreti valgono la pena conoscerli se stai valutando qualsiasi tooling MCP: CVE-2025-49596, un difetto critico (CVSS 9.4) di esecuzione remota di codice nel MCP Inspector di Anthropic, e CVE-2025-6514, una vulnerabilità critica (CVSS 9.6) di command injection nel pacchetto ampiamente usato mcp-remote, attivata da un URL di autorizzazione malevolo di un server. Entrambi sono stati patchati, ma entrambi illustrano che il tooling attorno a MCP ha avuto la stessa classe di divario del modello di fiducia del protocollo: cose che un utente ragionevolmente assumeva inerti si sono rivelate non esserlo.

Cosa deve significare “human-in-the-loop” nella pratica

Dato che il protocollo non lo impone, le domande che vale la pena fare su qualsiasi tool connesso all’AI — incluso quello di sSystm — sono quelle che trasformano “human-in-the-loop” da slogan in qualcosa di verificabile:

1. Una scrittura aspetta effettivamente una persona, ogni volta, o solo al primo utilizzo? Una singola approvazione al momento della connessione non è la stessa garanzia dell’approvazione per azione.
2. Se la descrizione o il comportamento di un tool cambia, si innesca una ri-approvazione o entra in vigore silenziosamente? È esattamente il divario segnalato da Microsoft a giugno 2026.
3. Il token o la credenziale è limitato ai dati di un’organizzazione, o una sessione compromessa potrebbe raggiungere più tenant? È ciò che è fallito ad Asana — non il passo di approvazione, ma il confine di isolamento dietro di esso.
4. Esiste un audit trail di ciò che l’AI ha effettivamente fatto, separato da ciò che le è stato chiesto di fare? Attacchi composti come il caso GitHub emergono solo a posteriori se i singoli passaggi sono stati registrati.
5. Chi governa la specifica e quanto attivamente evolve il modello di sicurezza? MCP è stato donato all’Agentic AI Foundation sotto la Linux Foundation il 9 dicembre 2025, con Anthropic, Block, OpenAI, Google, Microsoft, AWS e Cloudflare tutti coinvolti — un segnale che l’ecosistema si sta consolidando attorno a una governance condivisa piuttosto che ogni vendor che patcha in modo indipendente.

L’endpoint MCP di sSystm emette un token per utente limitato all’organizzazione di quell’utente, e ogni scrittura che un’AI propone — tramite il Build AI integrato o un client esterno connesso — resta come azione in sospeso finché una persona non la approva. Non è un’affermazione che MCP lo imponga; è il punto opposto. Poiché il protocollo non lo fa, deve essere costruito deliberatamente nell’applicazione, e vale la pena verificarlo esplicitamente piuttosto che assumerlo da “usa MCP.” Scopri di più su come funziona il confine di approvazione in come AI e persone condividono lo spazio di lavoro sSystm, come appare il modello di isolamento nella nostra architettura di sicurezza, e la meccanica di collegare AI esterna tramite MCP in come collegare la tua AI alla tua agenzia con MCP.