06/09/2026 TuaGPT

Console multitenant TuaGate: controllo, sicurezza e scalabilità della flotta AI

Come governare nodi, tenant e policy da un unico piano di controllo, senza disperdere credenziali né perdere il perimetro dati

Un nodo TuaGate è già un gateway: autentica i client, applica DLP, instrada i modelli, misura i token e scrive l’audit. Quando i nodi diventano due, tre o venti, sedi, clienti, ambienti Dev/Test/Prod, il problema non è più “far funzionare l’AI”. È governarla da un solo posto, con isolamenti chiari e operazioni ripetibili. Quella superficie è la console multitenant di TuaGate: il control plane web su administration.tuagate.com.

Due piani, una piattaforma

TuaGate separa volutamente il data plane dal control plane. I client — TuaGPT, Cursor, automazioni OpenAI-compatible — parlano sempre con il nodo locale: chat, completions, immagini, voce restano sul gateway dell’host. La console non è un proxy LLM e non emette licenze: orchestra i nodi, mostra lo stato della flotta e applica i controlli amministrativi via API.

Operatori (IT / MSP / direzione)
        │  login Identity sulla console
        ▼
administration.tuagate.com  ←  control plane multi-tenant
        │  HTTPS + Bearer tgcp_*  (chiave M2M per nodo)
        ▼
Nodo TuaGate (sede / cliente / ambiente)
        │  /api/v1/admin/*   utenti, backend, DLP, budget, audit, licenza
        │  /api/v1/chat …    data plane (resta sul nodo)
        ▼
Client TuaGPT  ·  provider locali/cloud  ·  portale licenze tuagpt.com

In pratica: le persone continuano a lavorare in TuaGPT. L’azienda decide chi può fare cosa, su quale nodo, con quali modelli e quali limiti dalla console, senza copiare credenziali da un PC all’altro.

Cosa significa “multitenant” in TuaGate

Nella console un tenant è un’organizzazione o un cliente (slug, ad esempio tenant-acme). Sotto il tenant stanno i gruppi, sede, ambiente, regione, e i nodi gestiti: ciascuna istanza TuaGate in esecuzione, con URL, stato heartbeat, etichette e licenza.

Tenant: Confine amministrativo: un cliente MSP, una business unit, un contratto. L’operatore TenantAdmin vede solo i propri nodi.
Gruppo: Partizione operativa: sede-milano, prod, edge-eu. Serve a filtrare, applicare policy e leggere lo stato per insieme, non nodo per nodo.
Nodo: Gateway Windows (o servizio) con identità persistente, hardware ID e pairing verso la console. Il SQLite locale resta sul nodo: la console tiene l’inventario, non il database di inferenza.
Operatore console: Utente Identity distinto dagli utenti TuaGate. Chi chatta in TuaGPT non accede alla dashboard; chi amministra la flotta non deve essere un utente LLM.

Questa griglia è ciò che rende la console versatile: lo stesso prodotto serve una PMI con tre sedi, un system integrator con venti clienti, o un’azienda che replica identiche policy su Dev, Test e Produzione.

Onboarding: pairinge-time, poi solo M2M

Il nodo non espone le credenziali Admin alla console. Il collegamento nasce da un codice pairing a TTL breve (default 15 minuti), generato in locale dal pannello Fleet di TuaGate o via API Admin.

L’operatore sul nodo avvia TuaGate e genera il codice.
Fuori banda (chiamata, ticket, runbook) comunica URL del nodo e codice a chi opera su administration.tuagate.com.
La console completa il pairing: riceve nodeId, hardware ID e una chiave tgcp_ mostrata una sola volta.
Da quel momento ogni chiamata admin usa Bearer M2M + header X-Dashboard-Id. La chiave è cifrata nel database della console (Data Protection); sul nodo resta solo l’hash.

La revoca pairing è un atto deliberato sul nodo (JWT Admin locale): se una console viene compromessa o un contratto MSP termina, il gateway smette di accettare quella chiave senza spegnere il data plane. Il pannello WinForms resta disponibile per emergenza sul singolo host.

Controlli possibili dalla console

Dopo il pairing, la dashboard non “guarda” il nodo: lo orchestra proxyando le API /api/v1/admin/*. I segreti (password, JWT secret, API key dei backend) non tornano mai in chiaro nelle GET.

Flotta e osservabilità

Inventario — nome nodo, versione, bind, SSL, tenant, gruppi, label (env, site), stato licenza.
Heartbeat — poll periodico (tipicamente 60 s); badgeline / Offline / Degraded; soglia offline configurabile.
Statistiche — utenti, backend, uptime, tipo licenza: la home della console è un cruscotto di flotta, non una chat.

Identità e accesso sul nodo

CRUD utenti TuaGate, attivazione/disattivazione, reset password.
Token persistenti generati una sola volta e revocabili da remoto.
Matrice modelli consentiti per utente: marketing può usare i tier quality, HR solo modelli locali.

Backend e routing

Registrare, testare e attivare backend (Ollama, LM Studio, OpenRouter, Hugging Face, 1min.ai, ComfyUI…).
Configurare il router virtuale tuagate-auto: tier fast / balanced / quality e fallback, senza che i client conoscano il provider reale.
La chiave API del backend è presente o assente (hasApiKey), mai esposta.

Governance, dati e costi

Budget token giornalieri/mensili per utente, soglia soft, ledger append-only, report per intervallo.
DLP sul nodo (policy globale, override utente/backend): Allow, Warn, Redact, Tokenize, Block — applicato prima del forward al modello.
Sharing RAG — esclusioni di condivisione gestibili da remoto, con documenti e vettori che restano sul client proprietario.

Configurazione e compliance

Bind IP/porta, SSL, firewall di ingresso, ban IP, JWT (secret mascherato; rotazione con invalidazione token).
Logging, retention audit, ottimizzazioni (cache, sampling, compressione contesto TuaCompress).
Audit richieste e security event log interrogabili per utente, IP, path, esito, severità — evidenze per ISO/GDPR, non screenshot di chat.

Licenze, senza confondere l’autorità

L’unica autorità di emissione resta www.tuagpt.com. La console avvia sul nodo richiesta NEW/RENEWAL, fa poll dello stato e mostra la flotta verde/rossa. Non genera chiavi, non bypassa l’hardware ID, non tiene il portale “in tasca”: orchestra lo stesso flusso che l’admin locale farebbe dalla scheda Licenze.

Sicurezza del control plane: cosa è già nel disegno

Una console che governa gateway AI è un bersaglio più interessante del singolo PC. TuaGate tratta il piano di controllo come un perimetro distinto, con mitigazioni esplicite.

Rischio	Controllo
Furto della chiave `tgcp_`	Cifratura a riposo; hash BCrypt sul nodo; chiave in chiaro una sola volta; revoca locale; mai nei log.
Pairing brute-force	Codice a TTL 5–60 minuti, rate limit sul nodo, tentativi limitati in UI.
Credenziali Admin TuaGate in un DB centrale	Non succede: la console non memorizza password del nodo, solo chiavi M2M per path admin.
Cross-tenant	Ogni query filtra per `TenantId` dell’operatore; SuperAdmin è l’unico ruolo trasversale.
Abuso di privilegi in console	Ruoli SuperAdmin, TenantAdmin, Operator (niente revoca pairing), ReadOnly.
Superficie LLM esposta alla dashboard	La chiave M2M vale solo su `/api/v1/admin/*`, non su chat/completions.
Nodo irraggiungibile o TLS debole	Heartbeat → Offline; certificati validi in produzione; ignore TLS solo lab.
Operazioni non tracciate	Audit strutturato: operatore console, nodo, endpoint, esito — più audit nativo del gateway.

Il data plane continua a vivere sul nodo: JWT client, rate limit, firewall UA, DLP fail-closed. La console aggiunge chi ha cambiato le regole, non sostituisce chi ha fatto la richiesta LLM.

Versatilità di business e come scala

Scalare l’AI in azienda non significa un cluster unico nel cloud. Significa aggiungere nodi dove servono —-prem per i dati, edge per la latenza, cloud per i modelli quality — tenendo una policy e un inventario.

Orizzontale — un nuovo sito è un pairing, un gruppo, un heartbeat. Non un nuovo “progetto AI”.
Verticale — sullo stesso nodo crescono utenti, backend e feature di licenza (Trial → Base → Premium → Enterprise/Custom) senza cambiare i client.
Organizzativa — tenant per cliente o BU; gruppi per sede/ambiente; label per automazioni e filtri.
Operativa — Operator e ReadOnly per NOC e direzione; SuperAdmin per il provider; emergenza sempre possibile in locale.
Economica — budget token e report usage per nodo o aggregati in dashboard: il costo cloud diventa un limite, non una fattura a consuntivo.

I client restano ignari del numero di nodi: chiedono tuagate-auto o un modello in ACL. Chi scala è l’IT, non l’utente finale.

Casi d’uso: TuaGate sotto la console

I casi seguenti non sono scenari da brochure: sono combinazioni di controlli già previsti da inventario, pairing, API admin e governance sul nodo.

1 · PMI multi-sede: un tenant, tre gateway, una policy

Un’azienda con uffici a Milano, Roma e Bari installa un nodo TuaGate per sede. I client TuaGPT di ciascun ufficio parlano con il gateway locale (latenza, continuità se il WAN cade). Nella console il tenant tenant-acme ha tre gruppi. L’IT imposta da remoto: backend Ollama in sede per documenti interni, OpenRouter solo per il tier quality, DLP in Redact su PII italiane, budget mensile per utente.

Quando Roma aggiunge un nuovo commerciale, l’utente e l’ACL modelli si creano dal dettaglio nodo, senza RDP sul server. La home mostra tre heartbeat verdi e le licenze in scadenza.

Risultato: AI federata, regole uniche, nessuna “chat non ufficiale” su endpoint cloud personali.

2 · MSP / system integrator: un tenant per cliente

Il partner gestisce venti PMI. Ogni cliente è un tenant isolato: TenantAdmin del cliente (se previsto) non vede gli altri; l’MSP SuperAdmin vede la flotta.boarding: tecnico in loco genera il codice, l’MSP completa il pairing da administration.tuagate.com, verifica hardware ID, avvia richiesta licenza Enterprise sul nodo.

Operatività quotidiana: test backend, rotazione token persistenti, lettura audit dopo un incidente, rinnovo licenza orchestrato. Fine contratto: revoca pairing sul nodo, il cliente resta con il gateway e l’admin WinForms, senza lasciare una backdoor M2M.

Risultato: servizio gestito ripetibile, isolamento contrattuale, exit pulita.

3 · Dev / Test / Prod: stessi controlli, blast radius diverso

Un gruppo IT replica tre nodi con label env=dev|test|prod. In Dev si sperimenta un backend Hugging Face e DLP in Warn (osservazione). In Test si attiva Tokenize e i budget soft. In Prod: Redact o Block, router con fallback, SSL obbligatorio, IgnoreTlsErrors spento.

La console evita il classico “funzionava sulla macchina del collega”: utenti, modelli consentiti e config JWT si allineano per gruppo, con audit di chi ha pubblicato il cambio.

Risultato: promozione controllata delle policy AI, come si farebbe con un applicativo business.

4 · HR e Legale: dati sul perimetro, modelli scelti dal centro

Il rischio non è il modello, è il copia-incolla. Sotto console, l’IT assegna al gruppo HR solo backend locali e policy DLP più strette (Block su IBAN/CF, pattern custom per matricole). Marketing, sullo stesso tenant ma altro gruppo, può usare cloud quality con Redact.

In ispezione, Request Audit Log e Security Event Log del nodo — interrogati dalla console — mostrano path, IP, modello virtuale/risolto, esito DLP, senza riversare il contenuto del prompt nei log.

Risultato: un’unica piattaforma TuaGPT, due regimi di rischio, evidenze pronte.

5 · Costi prevedibili su flotta ibrida

Customer Care su tier fast (locale), R&D su quality (OpenRouter / 1min.ai). Senza metering, il secondo mangia il budget del primo. Dalla console si impostano budget per utente, si legge lo usage aggregato per nodo e si spegne o si limita un backend cloud su un gruppo edge senza toccare i client: continuano a chiedere tuagate-auto.

TuaCompress sul nodo riduce il contesto delle conversazioni lunghe; il ledger dice se il risparmio è reale.

Risultato: mix locale/cloud sotto lo stesso tetto di spesa.

6 · Incident response: togliere l’accesso, non spegnere l’azienda

Token persistente di un collaboratore uscito: revoca da dettaglio utente sul nodo, da console. Sospetto sulla workstation di amministrazione: revoca pairing (solo Admin locale), nuovo pairing verso la dashboard legittima, rotazione JWT se necessario (regenerateSecret). IP abusivo: ban/firewall di ingresso sul nodo, visibile nello stato config.

Il data plane degli altri utenti resta su. La console coordina; il nodo enforce.

Risultato: risposta a incidente con perimetro esplicito, non “formattiamo il server AI”.

7 · PA e filiali: continuità locale, visibilità centrale

Un ente con sedi periferiche e connettività discontinua tiene l’inferenza-prem. La console, quando la WAN è su, raccoglie heartbeat, licenze e audit; quando è giù, TuaGPT continua a parlare col nodo. Nessun lock-in “l’AI è solo nel SaaS”.

Risultato: controllo centrale dove la rete lo consente, autonomia dove non lo consente.

Cosa la console non fa (e perché è un vantaggio)

Non sostituisce TuaGPT come strumento di lavoro.
Non inoltra chat: niente prompt aziendali in transito sul control plane.
Non emette licenze al posto di tuagpt.com.
Non elimina l’admin locale: è il piano B quando il nodo è isolato o il pairing va revocato.

Questa modestia architetturale è ciò che la rende adatta al business: meno dati nel SaaS di amministrazione, più enforcement dove i dati già stanno — sul gateway.

Conclusione

La console multitenant di TuaGate è il punto in cui una flotta di gateway diventa un servizio aziendale: tenant e gruppi per l’organizzazione, pairing M2M per la fiducia, API admin per i controlli, heartbeat e audit per la prova, licenze orchestrate senza confondere chi le emette.

Per una PMI è il modo di non avere tre TuaGate “fatti a mano”. Per un MSP è il modo di vendere governance AI senza mescolare i clienti. Per IT e compliance è il modo di scalare modelli, sedi e budget tenendo TuaGPT come interfaccia delle persone e TuaGate come regola eseguibile.

Il passo operativo è concreto: avviare il nodo, generare il codice Fleet, completare il pairing su administration.tuagate.com, e da lì governare utenti, backend, DLP, token e licenze come si governa qualsiasi piattaforma critica — con ruoli, isolamento e tracciabilità, non con una password condivisa su un PC in sala server.