Chiavi MCP con diritti granulari: leggere, creare, modificare, eliminare — per area di dati

"Abbiamo attivato MCP" suona come una casella già spuntata — ma non lo è. Il lavoro vero comincia dopo: chi può fare cosa attraverso questo accesso? È proprio qui che si decide se un accesso IA al tuo sito è uno strumento intelligente o un portone aperto.

Quando ho costruito l'accesso MCP per btlabs Core, per me è stato subito chiaro: una singola chiave universale per tutto sarebbe stata la soluzione più comoda — e quella sbagliata. Proprio come non consegneresti a un nuovo collaboratore il passe-partout di tutte le porte il primo giorno, anche un agente IA dovrebbe avere accesso solo a ciò che il suo compito richiede davvero.

Perché un accesso MCP generico non basta?

Un accesso generico non basta perché consente automaticamente a un agente più di quanto gli serva per il suo compito effettivo. Se un agente IA deve leggere i tuoi orari di apertura, ma tecnicamente potrebbe anche modificare il tuo listino prezzi, hai creato un rischio che non ha nulla a che vedere con il compito reale — indipendentemente dal fatto che quell'agente sia affidabile o configurato male. Il principio alla base è vecchio quanto la sicurezza informatica stessa: accesso solo a ciò che serve per il compito. Con gli agenti IA è solo più urgente, perché agiscono in autonomia, spesso per conto di un utente che non vedrai mai.

Cosa significa concretamente accesso granulare per area di dati?

Accesso granulare per area di dati significa che per ogni area dei tuoi contenuti — ad esempio orari di apertura, articoli del blog, prezzi o richieste di contatto — stabilisci singolarmente se una chiave può leggere, creare, modificare o eliminare in quell'area. Non "MCP acceso o spento", ma una matrice fatta di area e diritto. Una chiave per le pubbliche relazioni può ad esempio poter leggere e creare articoli del blog, ma solo leggere i prezzi e non poterli mai eliminare. Una seconda chiave, che usi solo tu, può avere permessi molto più ampi — perché sei tu dall'altra parte e ti assumi la responsabilità.

• Leggere: l'agente può interrogare i dati, ma non modificare nulla — la base per ogni risposta IA pubblica su di te.
• Creare: l'agente può creare nuove voci, ad esempio bozze o nuove richieste di contatto — i contenuti esistenti restano intatti.
• Modificare: l'agente può modificare voci esistenti — utile per la gestione autonoma, rischioso per accessi esterni.
• Eliminare: l'agente può rimuovere voci — il diritto dalle conseguenze più gravi, da concedere nel modo più mirato.

Perché un agente che legge gli appuntamenti non deve poter modificare anche i prezzi?

Un agente che legge gli appuntamenti non deve poter modificare anche i prezzi perché i due compiti non hanno nulla in comune, e un unico accesso mal configurato o compromesso metterebbe altrimenti a rischio più aree di dati insieme. Immagina un servizio esterno di prenotazione appuntamenti che riceve accesso al tuo calendario — sensato e pratico. Se per comodità la stessa chiave avesse anche diritti di scrittura sui prezzi dei tuoi prodotti, un errore in un sistema completamente indipendente finirebbe per toccare il tuo core business. Diritti separati, ritagliati sull'area di dati, evitano esattamente questo: un problema in un'area resta confinato a quell'area.

Quali due modi di usare MCP dovresti tenere distinti?

Esistono due modi fondamentalmente diversi di usare MCP, ed entrambi richiedono diritti su misura, ritagliati apposta. Il primo: un servizio IA esterno — ChatGPT, Perplexity, l'assistente di un tuo cliente — legge dati pubblici sulla tua attività per rispondere a domande di terzi. Qui la chiave, di norma, ha bisogno solo di diritti di lettura sulle aree pubblicamente visibili, niente di più. Il secondo, spesso trascurato: sei tu stesso — o un assistente IA di tua scelta che ti sei configurato — a lavorare direttamente con il tuo sito. "Parli" con il tuo sistema: curi i contenuti, interroghi i tuoi dati, deleghi compiti ricorrenti, senza doverti destreggiare in un menu di amministrazione.

Proprio questo secondo caso è uno dei vantaggi centrali di btlabs Core: non ottieni solo un sito leggibile dall'IA dall'esterno, ma un accesso proprio e protetto con cui tu stesso — o la tua IA preferita per tuo conto — gestisci direttamente il sito. Entrambi i modi d'uso passano per lo stesso standard aperto, ma con diritti di ampiezza diversa: generosi per te stesso, ritagliati stretti per i servizi esterni. Come questo si inserisca nel quadro più ampio di un'automazione IA ben pensata per la tua attività, lo trovi nella pagina collegata.

Come si presenta questo nella pratica per la tua attività?

Nella pratica stabilisci insieme a noi quale chiave può accedere a quale area di dati con quale diritto — prima ancora che l'accesso venga attivato. Un esempio: una chiave per un assistente esterno di prenotazione riceve diritti di lettura su orari e disponibilità, ma nessun accesso ai dati di contatto o ai prezzi. La tua chiave personale per la gestione quotidiana riceve diritti di lettura, creazione e modifica sui contenuti, ma consapevolmente nessun diritto automatico di eliminazione sui dati dei clienti. Ogni accesso viene registrato, così puoi sempre ricostruire chi ha avuto accesso a cosa e quando.

In cosa si differenzia questo dall'essere "agent-ready"?

Essere agent-ready — cioè leggibile in modo pulito per agenti IA esterni — è metà del quadro, ma è indipendente da chi accede a quei dati e con quale diritto. I diritti granulari per area di dati sono il livello sottostante: il controllo degli accessi che garantisce che leggibilità non significhi accesso incontrollato. L'uno ti rende reperibile, l'altro mantiene il controllo nelle tue mani.

Come avviene concretamente la configurazione di un accesso di questo tipo?

La configurazione avviene in un colloquio comune, in cui chiariamo per prima cosa chi userà effettivamente questo accesso, prima ancora che venga generata una chiave. All'inizio c'è sempre la domanda sullo scopo: un servizio IA esterno deve leggere i tuoi orari per rispondere ai clienti? Il tuo assistente IA deve aiutarti a curare gli articoli del blog? Solo da questa risposta emerge quali aree di dati siano rilevanti e quale dei quattro diritti — leggere, creare, modificare, eliminare — abbia senso per ciascuna area.

Da qui nasce una chiave ritagliata esattamente su questo scopo, né più né meno. Se lo scopo cambia in seguito — ad esempio perché arriva un nuovo servizio IA o vuoi affidare più compiti al tuo assistente — adattiamo i diritti in modo mirato, invece di creare un nuovo accesso generico. Così mantieni la visione d'insieme: sai sempre quale chiave è pensata per chi e cosa può fare, anche quando nel tempo nascono più accessi per scopi diversi.

Se vuoi scoprire come potrebbero apparire diritti MCP granulari per le tue aree di dati — sia per servizi IA esterni sia per il tuo assistente IA personale —, parliamone in un breve colloquio senza fronzoli.