Governance MCP, ruoli utente e permessi — perché conta per le aziende

Il problema nascosto della maggior parte dei setup MCP

Il Model Context Protocol ha aperto una corsia pulita per far parlare gli agenti AI con sistemi reali. La prima ondata di server MCP è arrivata sotto forma di CLI binari: installi sul portatile di uno sviluppatore, punti Claude Desktop, fine. Funziona per un singolo utente avanzato.

Non funziona per un'azienda.

Nel momento in cui più di una persona dentro un'azienda deve usare MCP, emergono subito tre domande di governance:

1. Chi può usare quale connettore?
2. Cosa può fare ogni utente una volta connesso (read? write? delete?)
3. Dove vive l'audit trail?

I server MCP CLI rispondono "chiunque abbia il binario" / "qualunque cosa l'API permetta" / "stdout, perso domani". Per un'azienda regolamentata è un blocco netto.

Questo è il gap che AnythingMCP è costruito per chiudere.

Cosa significa governance in un contesto MCP

In un SaaS classico, governance significa utenti, gruppi, ruoli, permessi e un audit log. Le stesse primitive valgono per MCP, ma con una dimensione in più: il tool.

Un server MCP espone una lista di tool al client AI. Ogni tool è una capability discreta — list_invoices, create_quote, delete_account. Senza access control per tool, dare "il connettore CRM" a un utente significa dargli tutti i tool che il connettore espone. È l'equivalente di dare l'SSH root a uno stagista perché deve fare tail su un log.

AnythingMCP tratta quattro livelli come first-class:

Ogni invocazione viene verificata contro tutti e quattro, poi loggata.

Il modello di governance AnythingMCP

Utenti e SSO

Puoi creare utenti manualmente dalla dashboard, oppure — ed è quello che fanno davvero i clienti enterprise — agganciare il tuo identity provider esistente:

• SAML 2.0 per Okta, Azure AD, OneLogin, Ping, Auth0, Keycloak
• SCIM 2.0 per provisioning e de-provisioning automatici (quando una persona lascia l'azienda, l'accesso MCP sparisce con il suo account AD, non tre settimane dopo quando ops ci pensa)
• Mapping gruppo → ruolo: il gruppo AD eng-platform diventa automaticamente il ruolo developer in AnythingMCP

Nessuna password separata da ruotare, nessuna lista utenti shadow da tenere in sync.

Ruoli

Un ruolo è un bundle di permessi con nome. AnythingMCP arriva con default sensati — admin, developer, viewer — e ti permette di definire i tuoi.

Una definizione di ruolo, concettualmente, è così:

role: finance
description: Team finanza — read fatture ovunque, post in DATEV
connectors:
  - slug: datev
    tools:
      list_clients: read
      list_invoices: read
      create_booking: write
      delete_booking: off
  - slug: weclapp
    tools:
      list_invoices: read
      list_orders: read
  - slug: sap-erp
    tools:
      "*": off    # negato esplicitamente

Il wildcard "*" è importante: quando aggiungi un nuovo tool al connettore SAP più tardi, il ruolo finance eredita automaticamente off — fail-closed invece di fail-open.

Accesso per connettore

Il pattern enterprise più comune: separare i connettori per perimetro di team.

• Sales vede il CRM.
• Finance vede ERP e contabilità.
• Engineering vede i database di produzione (read-only).
• Customer support vede il sistema di ticketing.

L'agente AI di ogni team — Claude, ChatGPT, Copilot, è indifferente — vede solo i tool che il suo ruolo permette. Una persona del sales che chiede a ChatGPT di "cancellare il record cliente" riceve un diniego pulito dal gateway, non un 500 da SAP dopo che l'azione è già parzialmente completata.

Permessi per singolo tool

È la granularità che i server CLI non possono offrire.

Un singolo connettore MCP per Salesforce può esporre 30+ tool: list_accounts, get_opportunity, create_opportunity, update_opportunity, delete_opportunity, list_leads, … Per ciascuno, AnythingMCP supporta tre modalità:

• read — il tool è chiamabile e ritorna dati, ma le mutazioni vengono filtrate
• write — il tool è completamente chiamabile
• off — il tool è completamente nascosto all'agente (non appare nemmeno nella risposta MCP tools/list)

"Nascosto" è il punto importante. Un modello non può essere jailbreak-ato per chiamare un tool di cui non sa l'esistenza. Tagliando il catalogo di tool per ruolo, riduci la superficie d'attacco al minimo davvero necessario per ogni utente.

Audit log

Ogni invocazione di tool scrive una riga: chi, quando, quale tool, quale connettore, con quali argomenti, cosa è stato restituito (o quale errore). Il log vive nel tuo PostgreSQL — non nel nostro cloud, non nell'S3 di un terzo — ed è interrogabile come qualsiasi altra tabella.

Per industrie regolamentate (banche, sanità, settore pubblico) è proprio questo che rende MCP utilizzabile. Puoi rispondere a "qualcuno ha letto la cartella paziente 1234 nell'ultimo trimestre?" con una sola query SQL.

Perché è impossibile con i server MCP CLI-only

L'ecosistema MCP è pieno di server CLI single-purpose — mcp-server-postgres, mcp-server-github, ecc. Sono ottimi per uso personale. Sono strutturalmente incapaci di fare governance enterprise per quattro motivi:

1. Niente concetto di utente. Un binario CLI gira come l'utente OS che l'ha invocato. Non c'è "Mario" vs "Anna" — c'è solo whoami. Due persone che condividono lo stesso install di Claude Desktop condividono la stessa identità MCP, by design.

2. Niente scoping per tool. Se la CLI espone query_database, ogni utente con il binario può chiamarlo con qualsiasi SQL. Non puoi restringerlo a sole SELECT, o a tabelle specifiche, senza forkare il binario.

3. Niente audit centrale. Ogni binario logga sul proprio stdout. Non c'è un posto dove chiedere "mostrami tutte le chiamate MCP fatte dall'azienda la settimana scorsa".

4. Niente deprovisioning. Quando una persona se ne va, dovresti rintracciare ogni laptop con il binario installato e tirargli via le credenziali. Nella pratica, nessuno lo fa.

Non sono bug dei server CLI — sono inerenti all'architettura. Un binario che gira sulla macchina di uno sviluppatore non ha alcun concetto di identità organizzativa.

Perché i gateway SaaS hosted hanno il problema opposto

L'altra risposta ovvia è "usa un gateway MCP SaaS hosted". Questo risolve la governance ma ne introduce una peggiore: le tue credenziali di produzione ora vivono in un terzo.

Per una GmbH tedesca o un'entità regolamentata, tipicamente fallisce:

• Compliance — GDPR, BDSG, HIPAA, SOX rendono complesso (o vietano) consegnare credenziali service account a un terzo
• Blast radius — se il SaaS viene compromesso, i sistemi di produzione connessi di ogni cliente sono esposti tutti insieme
• Vendor lock-in — credenziali, audit log, definizioni dei ruoli, tutto vive in un sistema che non controlli

AnythingMCP è self-hosted by design. Il gateway gira nel tuo VPC, nel tuo cluster Kubernetes, sulla tua box Hetzner, sul tuo laptop — dove vuoi tu. Le credenziali non lasciano mai il tuo perimetro. L'audit log vive nel tuo database. Le policy di governance sono versionate nel tuo repo git, se lo vuoi.

Hai la governance di un gateway hosted con il trust posture di un binario self-hosted.

Perché conta specificamente per le aziende

Tre pattern che vediamo ripetutamente con buyer enterprise:

Pattern 1 — il cancello della security review

Un pilot parte in IT o innovation. Nel momento in cui il progetto va in produzione, parte la security review e chiede:

• Possiamo revocare l'accesso a un utente specifico?
• Possiamo provare chi ha chiamato quale tool?
• Dove sono salvate le credenziali, e chi può decifrarle?

I server CLI falliscono tutte e tre. AnythingMCP risponde a ciascuna con uno screenshot della dashboard.

Pattern 2 — il cancello legal/compliance

Legal chiede: "Se un regolatore ci convoca per una decisione AI-driven, possiamo produrre il call trail?"

La risposta deve essere sì, con timestamp, identità utente, e gli argomenti completi del tool. L'audit log di AnythingMCP è strutturato esattamente per questo — ogni invocazione è una riga con timestamp, utente, connettore, tool, args, status di risposta. Esportarlo in CSV per legal è una query da una riga.

Pattern 3 — il cancello cross-team

Quando un team ha MCP funzionante, altri tre lo vogliono. Senza governance, ogni team o:

• Si fa il proprio install CLI (perdita di oversight centrale)
• Condivide un install senza isolation (l'errore di un team rompe i dati di un altro)

AnythingMCP permette a una singola istanza di servire tutti i team in sicurezza — sales vede solo CRM, finance vede solo ERP, eng vede solo il DB metrics. Il client AI di ogni team riceve un URL /mcp diverso con il proprio catalogo di tool scoped.

Un setup pratico, end-to-end

Ecco come si presenta un rollout enterprise tipico in AnythingMCP, passo per passo:

1. Deploy del gateway nella tua infrastruttura (Docker, Helm, Railway, DigitalOcean — scegli tu). 60 secondi circa.

2. Wire dell'SSO. Punta Okta o Azure AD all'endpoint SAML del gateway. Mappa i tuoi gruppi AD sui ruoli AnythingMCP.

3. Aggiungi i connettori. Dalla dashboard, punta AnythingMCP alle tue API (URL OpenAPI, WSDL, connection string database). Genera il catalogo di tool MCP automaticamente.

4. Definisci i ruoli. Per ogni ruolo, scegli quali connettori e quali tool può chiamare (read / write / off). I wildcard default a off, così aggiungere un nuovo tool dopo non concede mai accesso per sbaglio.

5. Distribuisci l'endpoint MCP agli utenti. Il client Claude / ChatGPT / Copilot di ogni utente riceve lo stesso URL del gateway — AnythingMCP ritorna il catalogo di tool scoped in base al ruolo dell'utente autenticato.

6. Monitoring via audit log. Ogni invocazione vive nel tuo Postgres; costruisci una dashboard Metabase sopra in un pomeriggio.

TL;DR — perché AnythingMCP per la governance

Se la governance è sulla tua roadmap AI e il self-hosted è non negoziabile — AnythingMCP è l'unica opzione che ti dà entrambi.

Per iniziare

Puoi provare il modello di governance su AnythingMCP Cloud (7 giorni gratis, niente carta) oppure fare self-host della build open-source con un comando solo. Entrambi spediscono lo stesso engine RBAC.

→ Inizia gratis su Cloud → Self-host su GitHub → Parla con il team per rollout enterprise