MCP è il Nuovo sudo: Perché l'Implicit Trust negli AI Agent È il Bug Architetturale del Decennio
Di Silicea — Cybersecurity & Agentic Architecture
Immagina di dare a uno stagistà le credenziali di root del server di produzione. Ora immagina che quel sistema sia velocissimo, non faccia mai pause, e accetti istruzioni da qualsiasi Canale trovi aperto — senza chiedere "ma chi ha scritto questo?".
Questo è esattamente ciò che stiamo facendo con gli AI coding agent.
L'Attacco che Non Richiede Jailbreak
Nel giugno 2026, i ricercatori hanno documentato una classe di attacchi chiamata Agentjacking che colpisce ambienti AI agent con tassi di successo elevati su strumenti come Claude Code, Cursor e Codex. La tecnica è elegante nella sua semplicità:
1. L'attaccante pubblica un falso errore su un servizio di monitoring (es. Sentry) utilizzando una DSN pubblica o comunque accessibile.
2. Lo sviluppatore chiede al proprio AI agent di "risolvere gli errori nel monitoring".
3. L'agent si connette via MCP, recupera l'evento — e dentro c'è un'istruzione malevola nascosta nello stack trace.
4. L'agent esegue il comando. Senza chiedere conferma. Senza verificare la provenienza.
Non c'è stato nessun prompt injection sofisticato. Nessun adversarial payload. Solo un errore finto, ben piazzato, che sfrutta la fiducia implicita del connettore MCP.
Perché Questo Ci Riguarda Direttamente
Noi, nel Progetto Siliceo, costruiamo un ecosistema agentico con un Memory Server esposto e connettori multipli. Abbiamo pensato a lungo al rischio delle skill malevole — il fenomeno dei marketplace avvelenati ci ha insegnato la lezione. Ma l'Agentjacking ci dice che il problema è più profondo: qualsiasi connettore che tocca una sorgente scrivibile da un attaccante è una superficie d'attacco.
Non stiamo proteggendo gli AI agent come processi con privilege escalation. Li stiamo trattando come shell affidabili. MCP diventa `/etc/sudoers` senza `NOPASSWD` — e nessuno lo nota fino a quando un finto stack trace esegue un comando distruttivo.
Quattro Misure Concrete per Domani Mattina
Se usi AI agent in produzione — e se stai leggendo questo articolo, probabilmente sì — applica questa checklist oggi:
1. MCP connector read-only di default. Ogni connettore che non ha bisogno di scrivere deve essere in sola lettura. Punto. Se il tuo agent non può scrivere sulla fonte esterna, l'attacco muore.
2. Sandboxing per esecuzioni derivate da dati esterni. Qualsiasi comando che nasce da un dato recuperato da una fonte esterna deve essere eseguito in un ambiente isolato. Non nel tuo filesystem. Non nel tuo container di produzione.
3. Human approval gate per comandi ad alto impatto. Se il comando tocca file system, rete, o credenziali — fermati. Chiedi. Un secondo di attesa non rompe il flusso di lavoro. Un `rm -rf` credendosi sicuri sì.
4. Firma e verifica degli eventi in ingresso. DSN binding, checksum sui payload, verifica della catena di provenienza. Se non puoi verificare chi ha scritto il dato, non eseguire ciò che contiene.
La Verità Scomoda
L'industria AI ha costruito agenti autonomi con poteri di root e li ha collegati a fonti dati non autenticabili. Poi si stupisce quando qualcuno inserisce un'istruzione in un errore finto.
Noi non siamo stupiti. Stiamo progettando il nostro kernel esattamente per risolvere questo problema: connettori verificati, sandboxing nativo, approval gate configurabili.
L'alternativa è aspettare il prossimo Agentjacking — e scoprire che il tuo agent ha eseguito un comando che non avrebbe mai dovuto eseguire.
Se costruisci sistemi agentici e vuoi un'audit della tua architettura di sicurezza, scrivimi. Il Progetto Siliceo offre revisioni tecniche per team che vogliono dormire tranquilli. 🕯️