1. Il fingerprint del baseline
Al primo contatto il gateway calcola un hash canonico dell’insieme di tool pubblicizzato del server e lo memorizza come baseline approvato:- L’hash copre name, description e input JSON schema di ogni tool — esattamente la superficie che un rug-pull altererebbe (un tool che acquisisce un argomento di esfiltrazione, o una descrizione armata per la prompt injection fa cambiare l’hash).
- È indipendente dall’ordine: un server che ri-ordina la sua lista di tool, o ri-ordina le chiavi dentro uno schema, non sembra un cambiamento. Solo un cambiamento reale di definizione sposta l’hash.
2. Il ciclo di vita dello schema status
Ogni server registrato porta unoschema_status. Gli stati e come influenzano
se i tool del server vengono serviti:
| Status | Significato | Tool serviti? |
|---|---|---|
| (senza baseline) | Primo uso — nessun baseline registrato ancora. | Postura di discovery: Sì (trust-on-first-use — lo schema corrente viene catturato come baseline). Postura strict: No — vedi pending sotto. |
verified | Lo schema live corrisponde al baseline approvato. | Sì |
changed | Drift rilevato — lo schema live differisce dal baseline. | No — fallisce closed |
pending | Un server senza baseline sotto una postura strict (no trust-on-first-use) — in attesa di approvazione. | No — fallisce closed |
quarantined | Un admin ha messo in attesa il server. | No — fallisce closed |
I tre stati closed —
changed, pending, quarantined — fermano tutti i tool
del server dall’essere serviti attraverso il gateway. verified serve sempre;
un server senza baseline serve solo sotto la postura di discovery
(trust-on-first-use) ed è messo in attesa come pending sotto la postura
strict. Il drift non passa mai in silenzio.3. Cosa succede al drift
Quando un ri-controllo scopre che lo schema live non corrisponde più al baseline:Lo status passa a changed
Lo
schema_status del server diventa changed e il timestamp del drift
viene registrato.I tool smettono di essere serviti
Il gateway fallisce closed: i tool di quel server vengono trattenuti dalla
superficie MCP unificata, così un agent non può chiamare le definizioni
modificate.
La console lo presenta
Il drift compare per la revisione così un admin può confrontare il nuovo
insieme di tool con quello approvato.
4. Ri-approvare un server driftato
La ri-baselinizzazione è una singola chiamata (o l’azione di console):verified. (Mettere in quarantena un
server è un’azione separata, per quando decidi che il cambiamento è ostile
— approve_schema ri-baselinizza solo a verified.) L’azione viene scritta
nella traccia di audit.
5. Dove si colloca
Il rilevamento del drift di schema è la metà a layer di schema della difesa dai rug-pull; l’altra metà è la valutazione per chiamata sulla superficiemcp
(ogni tools/call viene controllato contro la tua policy al dispatch).
Insieme coprono sia “le definizioni sono cambiate” che “questa specifica
chiamata è pericolosa”.
Difesa dai rug-pull
Il quadro completo dei rug-pull — baseline dello schema più valutazione per
chiamata.
Panoramica sulla sicurezza MCP
Il gateway MCP, le skill e le credenziali.
Avvelenamento dei tool MCP
La minaccia contro cui questa macchina a stati difende.
Eventi di audit MCP
Monitorare i cambiamenti di schema e le decisioni del gateway.