Vai al contenuto principale
Compliance

1 MCP server su 4. 2 agosto 2026. Cosa chiederanno gli auditor sui tuoi agent.

Help Net Security ha aperto un articolo di aprile con un singolo dato: uno su quattro MCP server espone gli AI agent a rischi di esecuzione di codice. Quel dato era affiancato da una scadenza apparentemente non correlata — il termine applicativo dell'EU AI Act. I due condividono ora una riga in ogni registro dei rischi europeo.

Mauro MeddaCo-Founder & CTO · HikmaAI
8 min di lettura

Help Net Security ha aperto un articolo nell'aprile 2026 con un singolo dato: uno su quattro MCP server espone gli AI agent a rischi di esecuzione di codice. Quel dato era affiancato da una scadenza apparentemente non correlata — il 2 agosto 2026, il termine applicativo per i sistemi AI ad alto rischio dell'Allegato III dell'EU AI Act. Se operi in Europa, quei due fatti condividono ora una riga nel tuo registro dei rischi.

MCP — il Model Context Protocol — è stato un successo silenzioso da quando Anthropic lo ha introdotto. È ora il modo più comune in cui un agent enterprise raggiunge uno strumento o una fonte dati interna. È anche, per progetto, una concessione di permessi. Il protocollo consente a un client di dire a un server: invoca questo strumento, con questi argomenti. Il server lo esegue. Questo è lo scopo, e questa è la superficie d'attacco.

Cosa stanno davvero dicendo le divulgazioni

Daniel Smith, in un thread ampiamente circolato su X sui risultati di OX Security riguardanti MCP STDIO, lo ha formulato operativamente: 'These flaws allow unsanitized user-controlled input.' Leggi quella frase pensando a un agent. Un agent passa l'istruzione di un utente — a volte mediata, spesso no — in uno strumento MCP. Se l'interfaccia STDIO dello strumento non sanifica ciò che arriva, un prompt sapientemente costruito diventa un comando shell sapientemente costruito. Questo è command injection. È una delle classi di vulnerabilità più antiche nel libro, che emerge in una delle interfacce più nuove del settore.

Il thread su Hacker News che ha catturato il lato pratico della conversazione — 'How are you handling security for AI agents that use MCP tools?' — è la domanda che sento ora alla fine di ogni conversazione di assessment. La risposta onesta è che la maggior parte dei team non la gestisce. Hanno installato il server perché uno sviluppatore l'ha chiesto. Hanno collegato l'agent perché il workflow ne aveva bisogno. Il modello di minaccia è arrivato dopo, se è arrivato.

La struttura di un assessment MCP

Un vero assessment MCP risponde a quattro domande su un server prima che all'agent sia consentito di usarlo.

  1. Step 01

    Quali strumenti espone questo server e qual è lo schema di ciascuno? Un MCP server con otto strumenti offre otto modi in cui un agent può agire attraverso di esso. Enumerazione prima della connessione.

  2. Step 02

    Quali permessi richiede ogni strumento e cosa restituisce? Uno strumento di sola lettura di un directory listing è una classe di rischio diversa da uno strumento che scrive su un database o esegue un comando shell.

  3. Step 03

    Quale validazione dell'input esegue il server sugli argomenti degli strumenti? Command injection STDIO, SQL injection, path traversal — le classiche vulnerabilità web, che emergono in un'interfaccia progettata per un agent.

  4. Step 04

    Come quale identità viene eseguito il server e qual è il blast radius di quell'identità? Un MCP server in esecuzione come root sullo stesso host del tuo database di produzione non è uno strumento; è un confine di privilegi che un agent ora controlla.

Il motivo per cui queste quattro domande contano insieme è che un agent in produzione vi risponde implicitamente ogni volta che esegue una tool call. L'assessment rende quelle risposte esplicite prima che la chiamata avvenga.

Perché il 2 agosto cambia l'urgenza

L'EU AI Act applica gli Articoli da 8 a 15 ai sistemi ad alto rischio dell'Allegato III a partire dal 2 agosto 2026. L'elenco delle categorie ad alto rischio include l'identificazione biometrica, le infrastrutture critiche, l'istruzione, l'occupazione, i servizi essenziali, le forze dell'ordine, la migrazione, la giustizia e il credit scoring. Se la tua organizzazione distribuisce un AI agent che partecipa a uno qualsiasi di quei flussi di lavoro, l'articolo su cui passerai la maggior parte del tuo tempo è l'Articolo 12 — registrazione automatica degli eventi nel ciclo di vita del sistema.

L'Articolo 12 è quello che si traduce più direttamente in un requisito di ingegneria. In sostanza, richiede un log. Non un log qualsiasi — un log che supporti la tracciabilità, il monitoraggio post-commercializzazione e la capacità di ricostruire una decisione a posteriori. Per un AI agent, ciò significa il prompt, le tool call, gli argomenti, le risposte, l'output del modello e l'azione che ne è risultata. Per un agent connesso via MCP, significa che ogni invocazione di strumento deve essere attribuibile, firmata ed esportabile.

La sanzione per la non conformità all'EU AI Act arriva a trentacinque milioni di euro o al sette per cento del fatturato annuo mondiale, il maggiore dei due. Per un'organizzazione regolamentata che ha rilasciato un agent senza pensare esplicitamente all'Articolo 12, la conversazione attorno a quei numeri non è una conversazione di sicurezza. È una conversazione per il CdA.

Come appare un log difendibile in sede di audit

Se mi trovassi di fronte a un auditor a settembre e aprisse con 'mostrami il log per l'agent che ha approvato questa decisione di credito,' vorrei che la risposta fosse a una query di distanza. Ciò significa alcune cose sul lato dell'ingegneria.

  • Il log è strutturato, non testo libero. Ogni evento è un record con un timestamp, un attore, una sorgente, un'azione e un risultato.
  • Il log è firmato crittograficamente — Ed25519 nella nostra implementazione — in modo che il record possa essere presentato come prova piuttosto che come un'affermazione che l'auditor accetta sulla fiducia.
  • Il log cattura l'intera catena di tool call per una decisione dell'agent: il prompt, il MCP server invocato, gli argomenti, la risposta e l'azione risultante.
  • Il log è esportabile in un formato che un auditor può acquisire — JSON, PDF o CSV a seconda dell'articolo — ed è mappato all'articolo del regolamento a cui risponde l'esportazione.

Nessuna di quelle quattro proprietà è concettualmente nuova. Sono stati requisiti per i sistemi ad alta affidabilità per decenni. La novità è che un AI agent deve ora soddisfarli, e il logging predefinito dei provider di modelli non lo fa. Quel divario è il lavoro tra ora e il 2 agosto.

La risposta in quattro ore

Una voce terza sull'AISPM ha espresso l'aspettativa degli auditor in una frase: 'Auditors need answers within four hours.' Li sto citando, non lo promettendo. Ma il framework è quello giusto. La domanda non è se la risposta esiste da qualche parte nel tuo stack. La domanda è se è recuperabile, firmata e mappata all'articolo in tempo per mantenere calma la conversazione.

Il compito di Hikma è garantire che le prove siano lì prima che la domanda venga posta. L'assessment MCP vive al confine che l'agent attraversa sulla strada verso lo strumento. Il logging compatibile con l'Articolo 12 cattura ciò che l'agent ha fatto una volta arrivato lì. L'esportazione converte entrambi in un documento che un auditor può leggere. La piattaforma si trova dove l'agent incontra il resto della tua infrastruttura, perché è l'unico posto in cui tutte quelle domande possono trovare risposta allo stesso tempo.

Uno su quattro MCP server, 2 agosto, risposte in quattro ore. Tre numeri, un calendario. Il lavoro tra di loro è il lavoro dei prossimi novanta giorni.

Scritto da

Mauro Medda

Co-Founder & CTO, HikmaAI

Richiedi Demo

Smettete di sperare.
Iniziate a dimostrare.

Richiedete una demo di 30 minuti. Il nostro team vi guiderà attraverso il modello di minaccia specifico per il vostro footprint agentivo — e come metterlo sotto controllo.