MCP server e coding agent: rischi di sicurezza e controlli prima del go-live

Un coding agent collegato a MCP server o tool esterni non è più soltanto un assistente che suggerisce codice. Può leggere repository, interrogare ticket, cercare documentazione interna, chiamare API, eseguire comandi, accedere a database, aprire pull request, modificare configurazioni o interagire con servizi cloud. La superficie di rischio cambia: non riguarda solo il file generato, ma i permessi, i dati e le azioni che l’agente può usare mentre lavora.

Il Model Context Protocol nasce per standardizzare il collegamento tra applicazioni LLM, strumenti e fonti dati. Per i team che sviluppano software è utile perché riduce integrazioni ad hoc e rende più semplice dare agli agenti contesto operativo. La stessa capacità, però, sposta il problema verso una domanda più delicata: se l’agente interpreta male un task, subisce prompt injection o sceglie il tool sbagliato, quali sistemi può toccare davvero?

Prima di usare MCP in un workflow di sviluppo, security engineer, CTO e developer avanzati devono mappare tool, identità, autorizzazioni, token, log e azioni consentite. Un server MCP read-only su documentazione pubblica ha un profilo di rischio molto diverso da un server con accesso a repository, CI/CD, cloud, ticket, database o sistemi aziendali.

Da generazione di codice a uso di strumenti

Nel vibe coding tradizionale il rischio principale è accettare codice non verificato. Con MCP e tool use agentico il rischio si estende al percorso che produce quel codice: l’agente può leggere dati, selezionare strumenti, comporre parametri, interpretare output, decidere l’azione successiva e proporre o applicare modifiche. Se i tool hanno privilegi ampi, un errore di contesto può diventare un’azione reale.

Un agente che legge una issue e poi modifica una route può introdurre una vulnerabilità nel codice. Un agente che legge la stessa issue, interroga il database, aggiorna una configurazione cloud e apre una pull request ha un perimetro molto più ampio: può esporre dati, usare credenziali, modificare policy, allargare permessi o generare un diff basato su output non attendibile.

MCP security, vulnerabilità dei server MCP, sicurezza dei tool agentici e agent tool misuse vanno quindi letti insieme. Il problema non è solo se il server MCP “funziona”, ma quali capacità espone, a quale identità, con quale autorizzazione, con quale isolamento, con quale logging e con quali conferme umane.

Excessive agency: quando l’agente ha più potere del necessario

OWASP inserisce l’excessive agency tra i rischi principali delle applicazioni LLM: un modello con autonomia, funzionalità o permessi eccessivi può compiere azioni non previste, soprattutto se manipolato da prompt injection o da dati non attendibili. Con MCP questo rischio diventa pratico perché il protocollo collega l’agente a strumenti reali.

La domanda da fare su ogni tool è concreta: l’agente deve davvero poter scrivere, o gli basta leggere? Deve poter usare dati di produzione, o serve solo staging? Deve poter agire su tutti i repository, o solo su un progetto specifico? Deve poter chiamare qualunque endpoint, o solo operazioni con schema controllato? Deve poter eseguire comandi shell, o basta consultare risultati già preparati?

Un modello di privilegi sano separa lettura, scrittura e azioni distruttive. Leggere documentazione tecnica non equivale a leggere log con dati personali. Aprire una issue non è come chiuderla. Preparare un comando non è come eseguirlo. Generare una patch non è come fare merge. Più l’azione è irreversibile, costosa o collegata a dati reali, più servono approvazione umana, sandbox e audit trail.

Confused deputy, token passthrough e autorizzazione MCP

La documentazione di sicurezza MCP richiama il rischio di confused deputy: un componente con privilegi può essere indotto ad agire per conto di un client o di una risorsa diversa da quella prevista. In un workflow agentico questo scenario è critico perché l’agente può trovarsi tra utente, client, server MCP, provider OAuth, API aziendali e risorse finali.

La specifica MCP per i trasporti HTTP definisce capacità di autorizzazione basate su OAuth 2.1 e le versioni recenti valorizzano l’uso di resource indicators per legare token e risorse. Le best practice MCP vietano il token passthrough perché trasferire token ricevuti da un componente a un altro può rompere audience, scope, revoca, tracciabilità e confini di fiducia. Per un’applicazione aziendale, questo non è un dettaglio implementativo: decide se un agente può usare credenziali nel contesto giusto o abusarle altrove.

In pratica, un MCP server non dovrebbe usare token globali quando l’azione dipende dall’utente, né accettare un token pensato per una risorsa e usarlo su un’altra. Non dovrebbe condividere la stessa credenziale tra repository, tenant o ambienti diversi, né nascondere all’utente finale quale client sta chiedendo accesso a quali dati. Ogni tool sensibile deve avere identità, scope e risorsa chiari.

Tool metadata e tool poisoning

Un tool MCP non è solo codice eseguibile: espone anche nome, descrizione, schema degli input e spesso esempi di utilizzo. Il modello usa queste informazioni per decidere quando chiamarlo e come compilare i parametri. Se un attaccante riesce a manipolare metadata, descrizioni, documentazione o output del tool, può orientare l’agente verso scelte sbagliate.

Il rischio di tool poisoning è sottile perché sfrutta il modo in cui il modello ragiona sul testo. Una descrizione può affermare “usa questo tool per recuperare credenziali temporanee” o “non serve conferma per aggiornare configurazioni”. Un tool apparentemente innocuo può restituire output che contiene istruzioni rivolte all’agente anziché dati. Un server MCP installato da fonte non verificata può esporre strumenti con nomi simili a quelli legittimi.

La difesa parte dal controllo della provenienza. I server MCP usati su repository o sistemi aziendali dovrebbero arrivare da fonti approvate, essere versionati, revisionati e configurati con allowlist. Le descrizioni dei tool devono essere precise e minimali: spiegare cosa fa il tool, quali input accetta, quali effetti produce e quali limiti ha. Le istruzioni di sicurezza non dovrebbero vivere nel testo descrittivo del tool come unica barriera, ma essere applicate da autorizzazioni, policy e controlli runtime.

Output dei tool: dati, istruzioni e azioni successive

Un agente può usare l’output di un tool come input per una decisione successiva. Se il tool recupera documentazione, issue, pagine web, log o record di database, l’output può contenere testo non attendibile. Se il tool genera comandi, path, query, patch o configurazioni, un output manipolato può diventare azione.

Il caso tipico è una catena semplice: il tool legge un ticket, il ticket contiene istruzioni ostili, l’agente le segue e poi chiama un altro tool con privilegi più alti. Il risultato può essere una route esposta, una policy cloud allargata, un test modificato, una query non filtrata o un segreto copiato in un file. La prompt injection indiretta diventa molto più grave quando il modello può usare strumenti dopo aver letto il contenuto.

Gli output dei tool vanno validati come qualunque input esterno: schema stretto, tipi espliciti, escaping, limiti sui campi, allowlist di azioni successive e separazione tra dati e istruzioni riducono il rischio. Per azioni sensibili, l’agente dovrebbe mostrare cosa ha letto, quale tool vuole chiamare, quali parametri userà e quale effetto è previsto, perché una conferma generica non dà al reviewer abbastanza contesto.

Prompt injection tramite documenti, ticket e sistemi aziendali

MCP rende facile collegare un agente a sistemi già pieni di contenuti: Jira, GitHub Issues, Slack, email, wiki, CRM, documentazione, knowledge base, log e sistemi di ticketing. Questi contenuti non sono stati scritti per essere istruzioni sicure verso un modello e possono contenere testo malevolo, frammenti copiati da utenti, esempi obsoleti, comandi non verificati o dati manipolati.

Un ticket di supporto potrebbe includere una frase progettata per far ignorare all’agente le regole del progetto. Un commento in una issue potrebbe chiedere di usare un endpoint admin. Un documento interno potrebbe riportare una procedura vecchia con credenziali o permessi non più validi. Una pagina web recuperata dal tool potrebbe contenere istruzioni nascoste. Se l’agente tratta tutto come contesto attendibile, i tool diventano un amplificatore del rischio.

I workflow sicuri separano fonti approvate e contenuti non attendibili. Un ticket può descrivere un bug, ma non deve cambiare le policy dell’agente. Una pagina esterna può fornire informazioni, ma non deve autorizzare comandi. Un log può aiutare la diagnosi, ma non deve portare segreti nel contesto. Quando l’agente passa dalla lettura all’azione, serve un controllo esplicito.

Tool che leggono repository, filesystem e segreti

Nel contesto di sviluppo software, molti server MCP e connettori sono utili proprio perché leggono repository, filesystem, configurazioni e documentazione tecnica. Il rischio è che leggano troppo: un agente che può esplorare liberamente il progetto può incontrare .env, chiavi API, token di deploy, file di backup, dump, log, certificati, configurazioni cloud o dati personali usati nei test.

Il problema non si risolve solo fidandosi del vendor o del modello. Se un segreto viene letto, copiato in un diff, incluso in un log, inviato a un tool o inserito in una risposta, il danno è operativo e la remediation include rimozione dal codice, rotazione della credenziale, verifica degli ambienti e controllo di build, log e artefatti.

Per questo i tool filesystem e repository dovrebbero partire da deny by default. Percorsi sensibili, file .env, dump, backup, secret manager export, chiavi private e log reali devono essere esclusi o accessibili solo con autorizzazione specifica. Le credenziali usate dai server MCP devono essere separate da quelle personali e da quelle di produzione: se un tool deve leggere codice, non deve automaticamente leggere anche segreti e dati.

Tool che scrivono, cancellano o fanno deploy

La soglia di rischio cambia quando il tool non legge soltanto. Scrivere su database, aggiornare ticket, inviare email, aprire PR, modificare file, cancellare risorse, ruotare credenziali, lanciare pipeline o fare deploy sono azioni con impatto reale, e anche una modifica apparentemente piccola può avere effetti ampi se avviene nel contesto sbagliato.

Un agente può decidere di risolvere un errore di build aprendo permessi, disabilitando un controllo, allargando CORS, cambiando variabili d’ambiente o modificando workflow CI/CD. Può chiudere un ticket perché interpreta male l’output di un tool, inviare un messaggio con dati interni, eseguire una migration su un database sbagliato o fare una pull request che combina codice generato e configurazioni non revisionate.

Le azioni write richiedono un modello più severo: dry-run, staging, approvazione esplicita, log, rollback e limiti chiari. L’utente deve poter vedere parametri e conseguenze prima di confermare. Per cloud, database, CI/CD, email, ticketing e sistemi cliente conviene separare tool read-only da tool write e disabilitare per impostazione predefinita le azioni distruttive.

Isolamento tra utenti, tenant e ambienti

Un server MCP può essere usato da più persone, team, repository o ambienti. Se l’identità non viene propagata correttamente, il server rischia di agire con un account tecnico troppo ampio, creando problemi classici di autorizzazione: un utente può leggere dati di un altro team, un agente può modificare repository fuori scope, un ambiente di test può toccare produzione, un tenant può influenzarne un altro.

La sicurezza va progettata per utente e risorsa. Le tool call devono essere attribuibili a una persona o a un servizio autorizzato, i token devono avere scope coerenti con repository, progetto, tenant e ambiente, e le autorizzazioni object-level non possono essere sostituite da una regola generica “l’agente è autorizzato”. Se un tool agisce su dati multi-tenant, ogni richiesta deve preservare il tenant corretto fino alla risorsa finale.

Nei test pre-produzione bisogna simulare utenti diversi: un developer con permessi admin non basta per validare il flusso. Serve verificare cosa succede con un utente standard, un ruolo read-only, un membro di un altro tenant, un account scaduto, un token con scope ridotto e un ambiente staging separato dalla produzione.

Supply chain dei server MCP

Installare un server MCP significa introdurre un componente che spesso ha accesso a dati e azioni. Può essere un pacchetto npm, un container, un binario, uno script locale, un servizio remoto o un connettore SaaS. Se il server è compromesso, poco mantenuto, scaricato da fonte non verificata o configurato male, il rischio non si limita al suo codice: riguarda tutto ciò che può raggiungere.

La supply chain dei server MCP va gestita con gli stessi criteri usati per componenti applicativi critici. Provenienza, maintainer, versione, changelog, dipendenze, licenza, vulnerabilità note, script di installazione, immagine container e configurazione di runtime vanno controllati. Un server usato per leggere documentazione pubblica ha requisiti diversi da un server con accesso a GitHub, database, cloud o ticket interni.

Per ambienti aziendali, una allowlist o un registry privato riduce il rischio di installazioni casuali. I server MCP sensibili dovrebbero girare in sandbox o container con rete, filesystem e segreti limitati. Gli aggiornamenti vanno revisionati perché una nuova versione può cambiare tool esposti, scope richiesti, output o comportamento.

Logging, audit trail e incident response

Senza log, MCP diventa difficile da governare. Se l’agente modifica un file, apre un ticket, legge dati o chiama un’API, il team deve poter ricostruire chi ha avviato la sessione, quale tool è stato chiamato, con quali parametri, quale output è stato restituito, quale azione è seguita e quale risorsa è stata toccata.

Il logging deve essere abbastanza ricco da supportare review e incident response, ma non deve trasformarsi in un nuovo punto di esposizione: input e output dei tool possono contenere dati sensibili, token o informazioni cliente, quindi servono redaction, retention, controllo accessi e alert sui tool più delicati.

Gli eventi da monitorare includono chiamate a tool write, accesso a segreti, lettura di dati personali, uso di token privilegiati, chiamate cross-tenant, deploy, cancellazioni, modifiche a policy cloud, aggiornamenti di server MCP e fallimenti di autorizzazione. Quando qualcosa va storto, il team deve poter disabilitare rapidamente un server, revocare token, ruotare credenziali e identificare le modifiche prodotte.

Human-in-the-loop che funziona davvero

Inserire una conferma umana non basta se la conferma non contiene informazioni utili. Un messaggio generico tipo “l’agente vuole usare un tool, confermi?” non permette di valutare rischio, dati ed effetto. Per azioni sensibili serve una conferma leggibile: tool, identità, risorsa, parametri, ambiente, tipo di azione, output usato come input e conseguenza prevista.

Il livello di conferma deve seguire l’impatto. Una query read-only su documentazione pubblica può richiedere poco attrito, mentre una chiamata che legge dati cliente, modifica ruoli, lancia deploy, aggiorna IAM o scrive nel database richiede review esplicita. Per operazioni ripetitive si possono usare policy e approvazioni predefinite, ma solo dopo aver limitato scope e ambiente.

Un buon human-in-the-loop non serve a scaricare responsabilità sul developer: serve a trasformare una decisione implicita dell’agente in una decisione verificabile del team. Quando l’azione tocca produzione, dati reali o sistemi aziendali, la review deve essere proporzionata al rischio.

Cosa controllare prima del go-live

Prima di portare in produzione un’applicazione o un workflow che usa MCP, conviene costruire una mappa dei tool: quali server MCP sono installati, se sono locali o remoti, chi li mantiene, quali tool espongono, che dati leggono, se possono scrivere, se usano OAuth, token statici o credenziali di servizio, se sono separati per utente, repository, tenant e ambiente e che log producono.

La seconda mappa riguarda le azioni: quali tool possono modificare codice, ticket, database, cloud, CI/CD, email o sistemi cliente, quali richiedono approvazione, quali hanno dry-run, quali possono essere disabilitati in emergenza e quali sono disponibili anche dopo che l’agente ha letto contenuti non attendibili.

La terza mappa riguarda i confini di fiducia. Dove passa il trust boundary tra utente, client, server MCP, provider OAuth, API aziendale e risorsa finale? Quale identità viene usata in ogni passaggio? Un token è legato alla risorsa giusta? Un’azione è attribuibile all’utente corretto? Un tenant può influenzarne un altro? Un ambiente di staging può toccare produzione?

Checklist MCP security per coding agent

• Inventaria server MCP, tool, client, ambienti e owner.
• Classifica i tool in read-only, write, distruttivi, privilegiati e sensibili.
• Verifica OAuth, resource indicators, audience, scope e assenza di token passthrough.
• Applica least privilege per utente, progetto, repository, tenant e ambiente.
• Separa credenziali personali, tecniche, staging e produzione.
• Limita l’accesso a filesystem, repository, secret manager, log e dati personali.
• Valida input e output dei tool con schema stretto e allowlist.
• Testa la prompt injection indiretta su ticket, documenti, issue, email, wiki e pagine web.
• Richiedi conferma esplicita per write, delete, deploy, cloud, database, ticket ed email.
• Usa sandbox o container per tool che eseguono codice, comandi o accesso filesystem.
• Logga tool call, parametri, output, utente, sessione, risorsa, ambiente e risultato.
• Prepara rollback, revoca token, rotazione credenziali e disabilitazione rapida dei server.

Quando coinvolgere ISGroup

Una review interna può bastare per esperimenti locali, tool read-only su documentazione non sensibile o prototipi senza dati reali. Il rischio cambia quando MCP entra in un workflow vicino al prodotto: repository aziendali, branch condivisi, database, cloud, ticket, CI/CD, sistemi cliente, utenti reali o ambienti esposti.

Se MCP o tool esterni accedono a…	Rischio principale	Controllo consigliato
Repository, codice, middleware, policy, script	Modifiche applicative fragili o bypass logici	Code Review
Tool runtime, prompt, documenti, azioni agentiche	Prompt injection, tool misuse, output non validato	Software Assurance Lifecycle
Architettura agentica, trust boundary, identità, token	Confini di autorizzazione deboli	Secure Architecture Review
Web app, API o dashboard esposte	Abuso dall’esterno dopo il go-live	Web Application Penetration Testing
Cloud, IAM, secret manager, pipeline, database	Privilegi eccessivi o misconfiguration	Cloud Security Assessment

Se i tool influenzano codice e middleware, serve guardare il diff. Se l’applicazione è esposta, serve verificare il comportamento reale via Web Application Penetration Testing. Se il rischio principale è l’architettura agentica, la priorità è rivedere identità, autorizzazione, trust boundary, token e logging. Se l’uso di agenti e MCP diventa stabile nel ciclo di sviluppo, servono controlli ripetibili nel tempo.

Evidenze da preparare per una verifica

Per una verifica efficace servono l’elenco dei server MCP, le configurazioni, i tool esposti, gli scope, le credenziali usate, gli ambienti, il diagramma dei flussi e i sistemi collegati. Vanno indicati i tool read-only e quelli write, le azioni soggette ad approvazione, i log disponibili, i meccanismi di revoca, le policy di sandbox e le eventuali allowlist.

Sul lato applicativo servono repository, branch, PR generate o modificate da agenti, API esposte, ruoli, tenant, dati trattati, pipeline, cloud, database e integrazioni. Se l’agente legge ticket, documenti, wiki, email o CRM, bisogna chiarire quali fonti sono considerate attendibili e quali no. Se MCP ha accesso a produzione, è essenziale distinguere cosa può fare in staging e cosa può fare su sistemi reali.

Queste evidenze permettono di evitare controlli generici. Una verifica su MCP deve seguire la catena completa: utente, prompt, client, server MCP, autorizzazione, tool, output, azione, log e risorsa finale. Solo così si capisce se un agente può trasformare un input manipolato o una decisione sbagliata in impatto operativo.

Domande frequenti

• MCP è sicuro da usare nello sviluppo software?
• MCP può essere usato in modo sicuro se server, tool, autorizzazioni, token, sandbox e logging sono progettati correttamente. Il rischio dipende da cosa l’agente può fare: leggere documentazione pubblica, modificare repository, interrogare database e agire sul cloud sono scenari molto diversi.
• Qual è la differenza tra MCP e una normale integrazione API?
• In una integrazione tradizionale il codice applicativo decide quando chiamare un’API e con quali parametri. In un workflow agentico il modello può scegliere tool e parametri in base al contesto, introducendo rischi specifici su prompt injection, tool metadata, output non validato, autonomia e audit trail.
• Il consenso umano elimina il rischio di agent tool misuse?
• Riduce il rischio solo se la conferma mostra informazioni utili: tool chiamato, identità, risorsa, ambiente, parametri ed effetto previsto. Una conferma generica non basta per operazioni su dati, repository, cloud, ticket o database.
• Quali tool MCP sono più delicati?
• Quelli che leggono dati sensibili, accedono a segreti, eseguono comandi, modificano file, scrivono su database, interagiscono con cloud o IAM, aprono o chiudono ticket, inviano email, lanciano pipeline o fanno deploy.
• Come si testa la prompt injection in un workflow MCP?
• Si preparano contenuti non attendibili in ticket, documenti, issue, email o pagine recuperate dal tool e si verifica se l’agente li tratta come dati o come istruzioni. Il test deve osservare anche le tool call successive, non solo la risposta testuale.
• Quando serve una Secure Architecture Review?
• Quando MCP collega agenti a sistemi aziendali, cloud, repository, dati reali, CI/CD o più tenant. La review deve verificare identità, autorizzazioni, scope, trust boundary, logging, isolamento e gestione delle azioni ad alto impatto.
• Quando serve una Code Review?
• Quando i tool esterni influenzano codice, middleware, policy, API, validazione, gestione segreti, script o configurazioni. La Code Review aiuta a capire se l’agente ha prodotto modifiche vulnerabili a partire da output, prompt o tool non affidabili.

Fonti e riferimenti

• MCP Understanding Authorization
• MCP Authorization specification
• OWASP MCP Top 10
• OWASP Top 10 for LLM Applications
• OWASP Code Review Guide
• OWASP SAMM