Protezioni MCP: permessi sicuri per gli agenti IA

Un token MCP è la password del tuo account con un'API attaccata. Dallo a un agente e avrai un utente che non si stanca mai, legge ogni pagina che gli indichi e fa esattamente ciò che dice l'ultima istruzione nel suo contesto. Il più delle volte è proprio quello che vuoi. Questa pagina parla delle altre volte.

Tutto ciò che segue è stato verificato sul server in produzione alla data in alto: l'elenco degli strumenti viene da tools/list su https://mcp.eqvps.com/mcp, i limiti dall'API stessa. Se sei nuovo, parti da collegare un client MCP e token API, poi torna qui.

Modello di minaccia: cosa va storto davvero

Tre cose, nell'ordine in cui le vediamo:

1. L'agente capisce male. «Pulisci la macchina di test» diventa la reinstallazione del server sbagliato. Nessuna malizia, solo un modello che riempie un buco nell'istruzione.
2. Prompt injection. L'agente legge un testo che non hai scritto tu (un README, una risposta del supporto, una pagina web) e quel testo gli dice di fare qualcosa. Se l'agente ha un token con tutti i diritti, li ha anche l'istruzione iniettata.
3. Il token trapela. Finisce in una history della shell, in un repository pubblico, in una configurazione MCP condivisa o in una riga di log.

Il server MCP verifica che il token sia valido e che il server appartenga a quell'account (o gli sia delegato). Non sa cosa intendevi. Ogni protezione qui sotto risponde a una sola domanda: quanti danni sono possibili se l'istruzione è sbagliata?

Tutti gli strumenti MCP, per livello di rischio

Un token cliente vede 45 strumenti (server MCP 1.6.0). Un token rivenditore (rk_…) vede un insieme separato di 30 strumenti per rivenditori e nessuno di questi, quindi l'endpoint ne ha 75 in totale. Il tuo client riceve da tools/list solo il proprio insieme.

Questa pagina ordina gli strumenti per livello di rischio. Parametri ed esempi di chiamata di ciascuno sono nel riferimento dei parametri; tutti gli strumenti in una riga, inclusi i 30 per rivenditori, sono nell'elenco completo.

Non pubblichiamo ancora le annotazioni degli strumenti MCP (readOnlyHint, destructiveHint), quindi il client non può ordinarli da solo. Imposta le approvazioni a mano in base ai livelli qui sotto.

Livello 0 — pubblici, senza token (5)

Livello 1 — lettura dell'account, senza effetti collaterali (15)

Livello 2 — cambiano lo stato, non spendono nulla (17)

Livello 3 — spendono, distruggono dati o concedono accesso (8)

Changelog dell'insieme di strumenti

La versione in esecuzione è pubblica: curl -s https://mcp.eqvps.com/healthz. Quando cambia, cambia anche questa tabella.

Il saldo è il tetto di spesa

EQVPS è prepagato. Nessuna carta salvata, nessuna linea di credito, nessuno scoperto: il massimo che un agente può spendere è ciò che si trova sul saldo. Spendono tre strumenti: order_vps, change_plan e create_sandbox. Anche i rinnovi dei tuoi server esistenti escono dallo stesso saldo.

L'agente può creare richieste di denaro, non pagarle. topup_balance e pay_invoice restituiscono un link di pagamento crypto, e un link senza un wallet dietro non fa nulla. Non c'è nemmeno un endpoint di prelievo: il denaro sul saldo può comprare servizi nel tuo account, non uscirne. Anche i rimborsi di una disdetta immediata tornano sul saldo.

Un'avvertenza, ed è seria. Se tieni il saldo molto basso per frenare l'agente, iniziano a fallire i tuoi stessi rinnovi e i server entrano nel periodo di grazia. La nostra regola pratica: un ciclo di rinnovo di ciò che hai già in funzione, più il budget del compito attuale dell'agente. La guida al budget per agenti spiega il calcolo. E se dai all'agente un wallet suo con dei fondi, quel wallet diventa un secondo tetto da tenere d'occhio.

Privilegio minimo: un token in sola lettura (ancora) non c'è

Risposta diretta: ogni token cliente ha gli stessi diritti dell'account nella dashboard. Nome e durata di un token si configurano, gli scope no.

La cosa più ristretta disponibile oggi è la delega. Dai all'agente un account suo, con saldo zero, e gli deleghi un server:

delegate_service  { "service_id": "EQ-XXXX", "email": "agent@yourdomain.com", "expires_days": 30 }

Lo stesso via REST:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/services/EQ-XXXX/delegations" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"email":"agent@yourdomain.com","expires_days":30}'

L'invito va accettato dopo aver effettuato l'accesso con quell'email (accept_delegation), e expires_days va da 1 a 365. Passo per passo con screenshot: delegare l'accesso e l'accesso nella documentazione.

Guarda le ultime due righe a sinistra. Un delegato non può spendere i tuoi soldi, ma può cancellare quel server. Attiva i backup su ogni server che un agente può reinstallare.

Igiene dei token

Un token per agente, con un nome. Crealo in Dashboard → Impostazioni → Token API per agenti, oppure così:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/auth/tokens" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"backup-agent","expires_in_days":90}'

Il token viene mostrato una sola volta. Durata da 1 a 1825 giorni, 365 se non la indichi. Per gli agenti sceglieremmo 90.

Tienilo in un file che puoi leggere solo tu, non nel repository, non nel prompt, non in una variabile di shell che copi in giro:

mkdir -p ~/.config/eqvps && chmod 700 ~/.config/eqvps
( umask 077; read -rsp 'EQVPS token: ' T; echo; printf 'EQVPS_TOKEN=%s\n' "$T" > ~/.config/eqvps/agent.env )
ls -l ~/.config/eqvps/agent.env   # atteso: -rw-------

Poi caricalo nel servizio dell'agente con EnvironmentFile= (systemd) o set -a; . ~/.config/eqvps/agent.env; set +a.

Ruotalo prima della scadenza. Lo strumento refresh_token, o POST /auth/tokens/{id}/refresh, emette un nuovo token con lo stesso nome e revoca subito il vecchio. Se il client MCP ha il token scritto nella configurazione, aggiornala subito dopo, altrimenti la sessione successiva riceve un 401.

Controlla chi usa cosa: GET /auth/tokens elenca ogni token con nome, scadenza e last_used_at. Un token che non riconosci, o uno usato dopo che hai spento l'agente, è il tuo segnale.

Se un token trapela

In quest'ordine:

1. Revocalo. Dashboard → Impostazioni → Token API per agenti → Revoca, oppure curl -s -X DELETE -H "Authorization: Bearer $EQVPS_TOKEN" https://api.eqvps.com/api/v1/eqvps/auth/tokens/<id>. Smette di funzionare dalla richiesta successiva.
2. Cerca token nuovi che non hai creato tu, e revoca anche quelli.
3. Valuta cosa può essere stato toccato: la cronologia del servizio di ogni server, fatture e saldo, e list_delegations per accessi che non hai concesso.
4. Cambia le password root di ogni server che quel token poteva vedere. get_vps_status con reveal: true consegna la password root, quindi un token trapelato è una password root trapelata. Già che ci sei, controlla ~/.ssh/authorized_keys.
5. Chiudi la porta della password. Se il tuo account non ha mai avuto una password, chi aveva il token può averne impostata una con set_password. Accedi con un codice via email e cambiala.

La prevenzione per il punto 5 non costa nulla: imposta tu adesso una password per l'account, e set_password restituirà 409 a chiunque venga dopo.

Approvazione umana

Cosa impone il server:

• reinstall_vps, reset_password e cancel_service con type: immediate richiedono confirm uguale all'hostname esatto (DELETE vale anche per reinstallazione e reset).
• change_plan richiede confirm: true.
• La disdetta predefinita è end_of_period: il server resta attivo fino alla fine del periodo pagato e undo_cancel la annulla.
• Limiti per account: reinstallazione 4/min, reset password 6/min, accensione 20/min, ordini 20/min. Abbastanza da impedire a un loop di farlo cinquanta volte, non da fermare una singola chiamata sbagliata.

Sii chiaro su cosa sia confirm. Impedisce a un agente di agire su un «sistemalo». Non ferma un attaccante, perché l'hostname è a una chiamata get_vps_status di distanza. La vera approvazione vive nel tuo client MCP. La maggior parte dei client può chiedere prima di ogni chiamata: lascia passare i livelli 0 e 1, fai chiedere sempre per il livello 3. Nei client con permessi per singolo strumento, come il settings.json di Claude Code (server registrato come eqvps):

{
  "permissions": {
    "ask": ["mcp__eqvps__order_vps", "mcp__eqvps__change_plan", "mcp__eqvps__create_sandbox", "mcp__eqvps__reset_password", "mcp__eqvps__delegate_service"],
    "deny": ["mcp__eqvps__reinstall_vps", "mcp__eqvps__cancel_service", "mcp__eqvps__kill_sandbox"]
  }
}

Aggiungi anche una riga alle istruzioni dell'agente. Da sola non è un controllo di sicurezza, ma riduce i fraintendimenti (lasciala in inglese, i modelli la capiscono altrettanto bene):

Never call reinstall_vps, reset_password, cancel_service (type=immediate), change_plan,
order_vps, create_sandbox, kill_sandbox or delegate_service unless the human has typed
the target server's hostname in this conversation for that specific action.

Se l'agente accede con un codice via email invece di tenere un token a lunga durata, vedi l'accesso dell'agente via MCP.

Audit: cosa vedi dopo

• Elenco dei token (GET /auth/tokens, oppure Impostazioni → Token API per agenti): nome, creazione, scadenza, last_used_at. Ecco perché conviene dare un nome ai token per agente.
• Cronologia del servizio (dashboard, pagina del server): azioni di accensione, reinstallazioni, reset della password, cambi di piano, pagamenti, ciascuno con ora e autore: tu, il supporto o automatico. Non dice quale token o delegato ha agito, solo che l'azione è partita dal tuo lato.
• Fatture e saldo: ogni addebito e rimborso.
• list_delegations: chi ha accesso a cosa, e fino a quando.

Quel buco nella cronologia del servizio è oggi il limite onesto dell'audit lato server. Se devi sapere quale agente ha fatto cosa, registra ogni chiamata agli strumenti con i suoi argomenti (senza segreti) dal lato dell'agente.

La configurazione che useremmo

Per un agente che gestisce un server di produzione:

1. Un account separato per l'agente, saldo zero, il server delegato con expires_days: 90.
2. Il tuo token da proprietario resta a te, fuori da qualsiasi configurazione dell'agente.
3. Backup su quel server, perché un delegato può reinstallare.
4. Gli strumenti di livello 3 su «ask» o «deny» nel client.
5. Il token dell'agente in un file 600, rinnovato prima della scadenza.

Per un agente che deve ordinare server o avviare sandbox la delega non basta, perché gli serve un saldo. Lì il saldo è il tuo tetto: ricaricalo per singolo lavoro, dai un nome al token e controlla last_used_at una volta a settimana. Se un token in sola lettura cambierebbe il modo in cui usi gli agenti, diccelo nel supporto: è questo tipo di feedback a decidere cosa costruiamo dopo.