L'agente di autenticazione di un fornitore di servizi può funzionare per molti clienti, ma ogni operazione deve avere un contesto cliente verificato. Il nome di un cliente in un prompt non è una decisione di controllo dell'accesso. Associa la sessione e il lavoro al tenant identificato dall'applicazione attendibile, quindi conserva tale identità attraverso il recupero, la proposta, l'approvazione, l'esecuzione e l'archiviazione delle prove.
Stabilire il confine del cliente
Durante l'onboarding, ottieni l'inventario dei domini approvati e l'autorizzazione dell'amministratore del cliente per il servizio richiesto. Registra identificatori tenant stabili e univoci, anziché fare affidamento su nomi visualizzati simili. Verificare che le zone DNS e le destinazioni dei report appartengano all'ambito previsto prima di concedere l'accesso.
Utilizzare credenziali con ambito cliente o un meccanismo di autorizzazione downstream ugualmente applicabile. Un'identità di servizio centrale con ampio accesso necessita di controlli approfonditi a ogni ricerca di risorse. OWASP descrive il rischio che identità privilegiate generiche accedano a risorse oltre il contesto utente pertinente. OWASP LLM06.
Mantieni le prove separate
Applica l'ambito del tenant all'archiviazione dei report, agli indici di ricerca, alle cache, al contesto delle conversazioni e ai file esportati. Limitare il recupero prima che le prove raggiungano il modello. Escludere il materiale di un altro cliente dalla risposta finale è troppo tardi se è già entrato nel contesto lavorativo. Anche i log necessitano di controlli di accesso; un dashboard di debug condiviso può impedire una separazione altrimenti attenta.
Un IP o un nome di provider condiviso da due clienti non consente di unire le loro prove private. Registra i fatti sull'infrastruttura pubblica separatamente dalla proprietà dell'account specifico del cliente, dall'attività del servizio e dai contatti. Un suffisso di dominio simile o un rivenditore comune non rendono due tenant un limite di autorizzazione.
Traccia un lavoro in coda attraverso una sovvenzione revocata
Supponiamo che un lavoro venga creato con la concessione valida del cliente A, quindi l'amministratore dell'accesso revoca tale concessione prima dell'esecuzione. L'esecutore deve ricontrollare l'autorità attuale piuttosto che fare affidamento sulla sessione precedente. Se una cache contiene anche il record del cliente B con lo stesso nome breve, la ricerca deve rimanere nell'ambito di A; infrastrutture condivise e nomi simili non possono giustificare il recupero delle prove private di B.
Si tratta di casi limite ipotetici, non di un connettore testato o di un runbook fornito. Assegnare responsabilità distinte per l'approvazione dell'ambito, le modifiche operative, la revisione indipendente degli accessi e l'offboarding. Definire condizioni di accettazione misurabili per la distribuzione effettiva, tra cui una richiesta A consentita e una richiesta B negata, lavori in coda revocati e recupero della cache con ambito appropriato. Non dichiarare alcuna esposizione tra tenant pari a zero finché i percorsi pertinenti non sono stati effettivamente testati.
Controlla i lavori e le sessioni
Vincolare l'approvazione al locatario e verificare la stessa identità al momento dell'esecuzione. Non lasciare che sia il modello a scegliere quale credenziale utilizzare da un nome cliente con testo libero. Ricontrollare l'autorizzazione quando viene eseguito un lavoro in coda; una sovvenzione potrebbe essere stata revocata dopo la creazione del posto di lavoro. Le relazioni con i clienti scadute o trasferite richiedono una gestione esplicita anziché l'accesso ereditato.
Test con nomi di clienti volutamente simili, IP di provider sovrapposti, nomi di record riutilizzati e una risposta memorizzata nella cache di un tenant diverso. Includere una lettura cliente consentita in modo che il test dimostri l'accesso con ambito, non un connettore disabilitato a livello globale. Gli esempi ipotetici precedenti non eseguono nessuno di questi test di distribuzione. Conservare il contesto effettivo della richiesta, le decisioni di autorizzazione e gli effetti osservati durante la valutazione.
Chiudi la relazione in modo pulito
L'offboarding dovrebbe interrompere il nuovo lavoro, revocare l'accesso, gestire i lavori in coda e applicare il processo di conservazione delle prove concordato. Conferma ogni azione attraverso il sistema responsabile. Conservare la cronologia minima degli audit necessaria per spiegare il lavoro precedente ai sensi dell'accordo applicabile. Non cancellare automaticamente le prove né mantenere l'accesso indefinito semplicemente perché l'agente potrebbe dover rispondere a una domanda successiva.