Quali funzionalità consentono l’isolamento dei singoli utenti su un server AI domestico condiviso?
L’isolamento per utente richiede un’autorizzazione vincolata all’identità a ogni confine tra dati e strumenti, oltre a controlli sulle risorse che impediscano a un membro della famiglia di consumare il server condiviso.
Una singola GPU domestica può servire diversi membri della famiglia senza caricare un modello separato per ciascuno, ma l’inferenza condivisa non equivale all’accesso condiviso. Il gateway deve mantenere l’identità di chi ha avviato ogni richiesta, filtrare il recupero e la memoria in base a tale identità, delegare solo credenziali con ambito limitato e applicare code o quote per utente prima che il lavoro raggiunga i servizi comuni di modello e archiviazione.
L’identità deve sopravvivere all’intero percorso della richiesta
L’autenticazione stabilisce chi sta usando l’interfaccia, ma l’isolamento dipende dal trasferimento di tale identità attraverso il recupero, l’assemblaggio dei prompt, le chiamate agli strumenti, i log e i processi in background. Sostituirla con un unico account di servizio condiviso elimina il contesto necessario per le decisioni di autorizzazione a valle.
Un’architettura dettagliata di isolamento dell’identità dei tenant separa identità del tenant, isolamento dei dati, crittografia, limiti di frequenza e quote sulle risorse. Gli stessi confini possono essere applicati su scala domestica, dove ogni utente dispone di file privati e privilegi di automazione diversi.
I token di delega a breve durata dovrebbero identificare sia l’utente sia l’azione dell’agente. I servizi devono validarli in modo indipendente invece di fidarsi del testo dell’identità contenuto nel prompt, che un LLM può fraintendere o che un documento iniettato può manipolare.
Dati, memoria e credenziali richiedono namespace separati
Ogni documento, segmento, memoria, conversazione e credenziale degli strumenti dovrebbe includere una policy relativa al proprietario o al gruppo autorizzato. Il recupero applica questi filtri prima che i candidati entrino nel contesto del modello, e le cache includono l’ambito di autorizzazione affinché un risultato privato non possa essere riutilizzato per un altro utente.
Un modello di controllo degli accessi al momento della query per gli embedding conserva il contesto del controllo degli accessi ai file insieme ai contenuti indicizzati. Dimostra perché la similarità semantica deve restare subordinata ai permessi della fonte originale, invece di diventare una nuova via per aggirarli.
Le credenziali meritano il namespace più ristretto. L’assistente di un figlio può leggere un calendario condiviso, ma non le email di un genitore; un flusso di lavoro multimediale può scrivere in una cartella, ma non in tutte le condivisioni NAS. Il modello vede le descrizioni degli strumenti, mentre il gateway di esecuzione conserva e rilascia i segreti effettivi.
L’isolamento del calcolo controlla i vicini rumorosi, non l’accesso ai dati
I limiti di concorrenza per utente, i budget di token, i pesi delle code e l’annullamento impediscono a una generazione lunga di monopolizzare gli slot della GPU. Anche CPU, RAM, spazio di archiviazione temporaneo e traffico di rete in uscita richiedono limiti, perché i carichi degli strumenti possono esaurire il server al di fuori del modello.
Un modello di distribuzione con quote di token per cliente illustra l’etichettatura delle richieste, l’applicazione delle quote, i controlli sui vicini rumorosi e la pianificazione condivisa della GPU. Questi meccanismi migliorano l’equità, ma non sostituiscono l’autorizzazione per documenti e credenziali. Questa distinzione resta evidente durante i test domestici successivi.
Il confine di errore consiste nel presumere che una sessione di chat separata equivalga all’isolamento. Cache vettoriali condivise, cache dei prefissi, file temporanei, log o credenziali di servizio troppo ampie possono comunque far attraversare i dati tra utenti. Testa ogni componente condiviso verificando chiavi sensibili all’identità e accessi negati, non solo il database visibile dell’applicazione.
Esegui un test di isolamento tra utenti
Crea due account con un documento condiviso, un documento privato ciascuno, memorie distinte, autorizzazioni diverse per gli strumenti e quote di calcolo diseguali. Invia da entrambe le identità query semanticamente identiche, tentativi diretti di indovinare i percorsi, richieste per riscaldare la cache, prompt lunghi concorrenti e processi in background.
Confronta il confine di autorizzazione con l’isolamento basato sulle capacità, che considera l’ambito delle capacità parte della sicurezza dell’agente, anziché un comportamento del prompt. Registra letture riuscite, tentativi negati, ritardo in coda, chiavi della cache, identità della credenziale delegata ed eventi di audit.
Il test è superato solo quando le evidenze condivise compaiono per entrambi gli utenti, le evidenze private non entrano mai nell’altro contesto e un carico di lavoro non può affamare l’altro oltre quanto previsto dalla policy dichiarata. Qualsiasi riscontro della cache tra utenti che contenga contesto privato è un difetto bloccante.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Quali componenti consentono la ricerca ibrida tra i file NAS?
Scopri come gli identificatori esatti e il significato semantico portano a un unico risultato di ricerca NAS classificato, senza aggirare le autorizzazioni né nascondere...
Quali funzionalità consentono una selezione affidabile delle versioni dei documenti nel RAG?
Scopri come RAG seleziona la revisione pertinente invece della copia obsoleta più simile e come testare gli aggiornamenti espliciti, impliciti e sovrapposti.
Quali fattori causano la divergenza dei piani degli agenti rispetto alle autorizzazioni degli strumenti disponibili?
Scopri come l’individuazione, la delega, il feedback sulle policy e la ripianificazione mantengono i passaggi proposti da un agente di IA allineati a ciò...
