Token MCP di sola lettura e per progetto per gli agenti IA

“Devo dare a un agente IA l'accesso alla mia lista di attività?” in realtà sono tre domande distinte nascoste in una: quanto può vedere, quanto in fretta posso toglierglielo se qualcosa non va, e che cosa richiede comunque il mio via libera anche mentre è collegato. Nessuna delle tre dipende dal modello che usi: sono proprietà di come il server fa rispettare l'accesso, non del giudizio dell'agente.

Perché l'ambito conta più del modello

Un agente può fare soltanto ciò che le sue credenziali gli permettono, per quanto capace o prudente sia il modello che c'è sotto. È una garanzia volutamente noiosa, data dal server, e non una speranza sul comportamento del modello: lo stesso motivo per cui limiteresti una chiave API di qualsiasi altro servizio esattamente a ciò che le serve, non a tutto ciò che in teoria potrebbe toccare.

Accesso completo, sola lettura o un solo progetto

Ogni account ha il proprio endpoint MCP e i propri token: mai uno condiviso o globale. Con Pro e Teams un token si può restringere ulteriormente: di sola lettura, così un agente può vedere la coda e il contesto dei commenti ma non modificare mai nulla, oppure limitato a un singolo progetto, così vede sempre e solo le attività di quel progetto e nient'altro del tuo account. Parti con un ambito più ristretto di quello che pensi ti serva: allargare dopo è facile, mentre restringere a cose fatte significa fidarsi di un agente che ha già avuto un accesso più ampio.

Revocare l'accesso all'istante

Rigenerare o revocare un token lo invalida immediatamente: nessuna cache da aspettare che scada da qualche parte. E se stai rimediando a qualcosa di cui non sei sicuro, cambiare o reimpostare la password revoca in una volta tutte le credenziali API dell'account, token MCP e app collegate compresi: così una sospetta compromissione non lascia in vita, in silenzio, l'accesso degli agenti dopo che hai già cambiato la password.

Il passaggio di approvazione come seconda briglia

L'ambito riguarda ciò che un agente può vedere e toccare; il passaggio di approvazione riguarda ciò che può concludere senza chiedere. Un'attività con l'Auto-OK può essere chiusa direttamente: va bene per il lavoro a basso rischio e reversibile. Tutto il resto passa da propose_completion e resta in attesa di approvazione finché una persona non dà il via libera, e solo una persona può assegnare l'Auto-OK a un'attività. I due meccanismi coprono rischi diversi: l'ambito limita l'estensione dei danni possibili, il passaggio di approvazione limita ciò che diventa definitivo senza supervisione.

Esecuzioni verificabili e budget

Ogni sessione di un agente è un'esecuzione registrata, con il proprio budget di chiamate agli strumenti e di tempo. check_budget ti dice quanto resta prima che il margine di una sessione si esaurisca, e quando il margine di un'attività con budget finisce, start_run viene rifiutato senza eccezioni, invece di lasciare che la sessione prosegua a credito. È una terza leva, indipendente: non riguarda l'accesso né ciò che diventa definitivo, ma quanto può fare una singola sessione prima di doversi fermare e tornare a riferire.

Una configurazione di partenza sensata

Fai partire un agente in sola lettura o limitato a un progetto, lascia la maggior parte delle attività senza Auto-OK e osserva qualche esecuzione prima di allentare qualcosa. Allarga l'ambito del token, o comincia ad assegnare l'Auto-OK alle attività di routine, quando hai visto davvero che cosa fa l'agente con l'accesso che ha, non prima. Non è sfiducia: è lo stesso atteggiamento che avresti inserendo un nuovo assunto in un sistema con conseguenze reali.