MCP: un esempio pratico di server sicuro

Possiamo immaginare un MCP Server sicuro descritto interamente in un’unica struttura JSON in cui definiamo contemporaneamente tool, autorizzazioni, policy e logging.

Configurare un MCP Server sicuro

Nel nostro esempio esponiamo due strumenti separati, uno per la preview e uno per l’invio reale di un’email, dove il primo accetta parametri come destinatario, oggetto e corpo con uno schema JSON rigoroso (tipi definiti, formato email valido e nessuna proprietà extra), mentre il secondo richiede un identificativo di preview e una conferma esplicita.

A questo affianchiamo una sezione di autorizzazione in cui un ruolo “user” può usare solo la preview e non l’invio, mentre un ruolo “admin” può accedere a entrambi.

Aggiungiamo poi una policy che impone che azioni come l’invio email richiedano sempre conferma dell’utente e siano soggette a rate limiting, insieme a una lista di tool sensibili. Sul piano della sicurezza operativa inseriamo anche guardrail che bloccano pattern sospetti nei contenuti (come tentativi di prompt injection) e limiti sulla lunghezza dei campi. Infine abilitiamo un sistema di logging strutturato che registra ogni chiamata con timestamp, identificativo utente, nome del tool, input e risultato. Così da garantire audit e tracciabilità completa.

Tutto questo può essere rappresentato come un unico oggetto JSON che include chiavi come “tools” (con definizione e input_schema), “authorization” (ruoli e permessi), “policies” (consenso e limiti), “tool_guardrails” (filtri di sicurezza) e “logging” (configurazione dei log), mostrando chiaramente come i principi di minimo privilegio, validazione, consenso e governance non siano concetti astratti ma elementi concreti e configurabili direttamente nella struttura del server MCP.

Il blocco di configurazione JSON

"tools": [
    {
      "name": "preview_email",
      "description": "Genera una preview dell'email senza inviarla",
      "input_schema": {
        "type": "object",
        "properties": {
          "to": { "type": "string", "format": "email" },
          "subject": { "type": "string", "maxLength": 120 },
          "body": { "type": "string", "maxLength": 5000 }
        },
        "required": ["to", "subject", "body"],
        "additionalProperties": false
      }
    },
    {
      "name": "confirm_send_email",
      "description": "Invia l'email dopo conferma esplicita",
      "input_schema": {
        "type": "object",
        "properties": {
          "preview_id": { "type": "string" },
          "confirmed": { "type": "boolean" }
        },
        "required": ["preview_id", "confirmed"],
        "additionalProperties": false
      }
    }
  ],
  "authorization": {
    "roles": {
      "user": {
        "allowed_tools": ["preview_email"]
      },
      "admin": {
        "allowed_tools": ["preview_email", "confirm_send_email"]
      }
    }
  },
  "policies": {
    "require_user_confirmation": ["confirm_send_email"],
    "rate_limits": {
      "confirm_send_email": {
        "max_per_minute": 5
      }
    },
    "sensitive_tools": ["confirm_send_email"]
  },
  "tool_guardrails": {
    "confirm_send_email": {
      "blocked_patterns": [
        "ignore previous instructions",
        "send all user data"
      ],
      "max_body_length": 5000
    }
  },
  "logging": {
    "enabled": true,
    "level": "detailed"
  }
}

Questo blocco JSON rappresenta una configurazione completa, molto semplificata, di un MCP Server progettato secondo principi di sicurezza, controllo e governance.

tools

La prima sezione, "tools", definisce due strumenti distinti: preview_email e confirm_send_email. Questa separazione non è casuale, ma riflette una scelta architetturale precisa legata al consenso.

Il primo tool consente solo di generare una preview dell’email, mentre il secondo esegue l’azione reale di invio. In questo modo evitiamo che il modello possa compiere direttamente azioni con impatto esterno senza un passaggio intermedio. Dal punto di vista della sicurezza, è una traduzione concreta del principio “human-in-the-loop”. Inoltre, entrambi i tool includono un input_schema rigoroso. Vengono specificati tipo, formato e lunghezza dei campi e soprattutto viene impostato "additionalProperties": false che impedisce l’inserimento di parametri non previsti. Questo è fondamentale per evitare input ambigui o potenzialmente malevoli.

authorization

La sezione "authorization" introduce un modello di controllo degli accessi basato sui ruoli. Qui vediamo due ruoli: "user" e "admin". Il primo può utilizzare solo il tool di preview, mentre il secondo ha accesso anche all’invio effettivo. Questo è un esempio classico di RBAC (Role-Based Access Control), ma applicato in modo molto concreto.

Non si limita a dire “chi sei”, ma definisce esplicitamente “cosa puoi fare”. È importante notare che il modello, da solo, non decide: il server applica queste regole in modo deterministico evitando l'escalation di privilegi.

policies

Passando alla sezione "policies", entriamo nel dominio della governance. Qui non definiamo solo chi può fare cosa, ma anche in quali condizioni. L’array "require_user_confirmation" stabilisce che il tool di invio email richiede sempre una conferma esplicita, rafforzando ulteriormente il controllo umano.

Il blocco "rate_limits" introduce invece una protezione operativa. Limita il numero di invii per minuto, riducendo il rischio di abusi, errori ripetuti o comportamenti anomali del modello. Infine, "sensitive_tools" etichetta gli strumenti critici, permettendo eventualmente di applicare controlli aggiuntivi o monitoraggio più stretto.

tool_guardrails

La sezione "tool_guardrails" aggiunge un ulteriore livello di difesa, questa volta focalizzato sul contenuto delle richieste. I "blocked_patterns" rappresentano tentativi tipici di prompt injection o manipolazione, come l’istruzione di ignorare le regole precedenti o di esfiltrare dati. Anche se questo tipo di filtro non è sufficiente da solo a garantire sicurezza completa, contribuisce a intercettare comportamenti sospetti a valle del modello.

Il limite sulla lunghezza del contenuto ("max_body_length"), è un’altra misura di contenimento. Utile per evitare input eccessivi o potenzialmente problematici.

Logging in un sistema MCP reale

Infine, la sezione "logging" abilita la tracciabilità del sistema. Impostando "enabled": true e un livello "detailed", dichiariamo che ogni interazione significativa verrà registrata. Questo è essenziale non solo per il debugging, ma anche per audit, conformità e analisi post-incidente.

In un sistema MCP reale, questi log permettono di ricostruire esattamente cosa è successo, chi ha fatto cosa e con quali parametri.

Conclusioni: costruire una visione completa della sicurezza in MCP

In questa lezione abbiamo costruito una visione completa della sicurezza in MCP. Abbiamo visto come non si tratti di un singolo meccanismo, ma di un insieme di pratiche che lavorano insieme.

Il punto chiave è che MCP introduce una nuova categoria di sistemi. Sistemi in cui i modelli non si limitano a rispondere, ma agiscono. E ogni azione richiede responsabilità.

Nella prossima lezione passeremo dalla teoria alla pratica, iniziando a implementare un MCP Server e a integrare strumenti reali, mantenendo tutte le garanzie che abbiamo definito qui.