Skip to content
Berktug Berke Ates
Berktug Berke Ates

Software Engineer

Blog

Modelli di permesso per copiloti AI multi-tenant

· 7 min di lettura

Un copilota AI multi-tenant che eredita i permessi chat ma ignora le ACL dati citerà con sicurezza il tenant sbagliato. Le tool call devono usare lo stesso percorso di autorizzazione delle vostre API—scoped per tenant, ruolo e risorsa.

L'accesso chat non è accesso ai dati

Gli utenti che possono aprire un pannello copilota non devono leggere automaticamente ogni documento che il modello può recuperare. Separate l'appartenenza alla conversazione dagli entitlement di risorsa. Il modello vede solo ciò che una policy lato server consente per quel principal in quel tenant—mai ciò che un prompt afferma che l'utente 'abbia bisogno'.

Il leak cross-tenant spesso inizia nel retrieval: embedding indicizzati senza predicati tenant, o collezioni vettoriali condivise interrogate solo per similarità. Mettete il tenant id in ogni partizione di indice e in ogni validazione di argomenti tool.

Autorizzare i tool come API pubbliche

Ogni invocazione tool deve passare dallo stesso middleware authz dei vostri handler REST o gRPC: autenticare l'utente (o l'identità di servizio), risolvere il contesto tenant, controllare RBAC/ABAC, poi eseguire con least privilege. Gli agent non devono trattenere token dio di lunga durata che bypassano i controlli row-level.

Preferire credenziali short-lived e scoped emesse per sessione o per tool call. Quando gli agent fan-out, propagare claim subject e tenant—non ampliare lo scope perché uno step del planner 'ha bisogno di più contesto.'

  • Applicare predicati tenant su indici di retrieval e argomenti tool
  • Riutilizzare il middleware authz API per ogni tool call; nessun percorso di permesso ombra
  • Emettere credenziali short-lived scoped invece di dei di servizio condivisi
  • Auditare principal, tenant, tool, risorsa e decisione per ogni chiamata

Modellare il principal per cui agisce l'agent

Decidere se il copilota agisce come utente finale, come ruolo assistente vincolato, o come operatore break-glass con approvazione separata. Documentare la differenza per support e compliance. Impersonation senza audit è un incident di sicurezza in attesa.

Il prompt injection può tentare di elevare i tool. La difesa è enforcement di policy fuori dal modello: deny list, allow list di tool per ruolo e filtri di output che non possono concedere nuovi permessi.

Dimostrare l'isolamento in continuo

Aggiungere test automatici che tentano retrieval e tool call cross-tenant con conversation id rubati. Monitorare tassi di denial e spike di allow inattesi dopo cambi di prompt o indice. I copiloti multi-tenant falliscono rumorosamente in demo e silenziosamente in produzione—strumentate per i fallimenti silenziosi.

I permessi sono superficie di prodotto. Progettateli con la stessa cura del modello che parla dietro di essi.


Pubblicato il 17 settembre 2026 da Berktug Berke Ates.