Politica di accesso tramite abbonamento
Un criterio di progettazione che separa l'uso quotidiano degli agenti dai canali commerciali richiesti da altri prodotti.
In breve
Sezione intitolata “In breve”Questa wiki adotta una regola circoscritta: il lavoro personale degli agenti usa, quando il prodotto lo consente, l’identità e i diritti dell’utente già inclusi in un abbonamento. Il repository non deve avere bisogno di una credenziale condivisa per eseguire un normale incarico editoriale o di sviluppo. È una decisione di progetto, non una proprietà dei modelli e non un modo alternativo per autorizzare filesystem, rete o strumenti.
La regola diventa utile soltanto se distingue l’operatore dal prodotto. Un’applicazione distribuita ad altri utenti, un backend o un servizio vocale hanno un’identità e un contratto commerciale propri: non possono ereditare implicitamente la sessione personale di chi li sviluppa. Questa distinzione completa quella fra canali di accesso ai modelli.
Matrice di decisione
Sezione intitolata “Matrice di decisione”| Scenario | Identità effettiva | Esito della policy |
|---|---|---|
| Agente interattivo usato dal titolare del piano | Utente autenticato nel client supportato | Dentro il perimetro |
| Comando headless ufficialmente collegato alla stessa sessione | Utente, ma su un canale diverso da verificare | Dentro solo dopo un probe |
| Automazione condivisa fra più persone | Identità non chiaramente attribuibile | Fuori perimetro |
| Backend o funzione server invocata da un prodotto | Applicazione o servizio | Richiede un contratto dedicato |
| Esempio che incorpora una credenziale nel repository | Segreto condiviso | Vietato |
La terza colonna non giudica se uno scenario sia lecito in assoluto. Dice soltanto se rispetta questa politica. Le decisioni di accesso restano separate: il modello ABAC di NIST SP 800-162, per esempio, riguarda attributi e autorizzazione, non entitlement commerciali.
Test di identità ed entitlement
Sezione intitolata “Test di identità ed entitlement”La verifica non deve chiedere genericamente se «il modello funziona». Deve stabilire quale identità attribuisce il canale, quale diritto sta usando e se quel diritto copre proprio la superficie invocata. Una sessione valida in un’applicazione non prova che un comando headless sia supportato, e l’accesso personale non può essere reinterpretato come identità di un backend.
Il test parte dal consumer reale, distingue “non autenticato” da “canale non incluso” e fallisce senza stampare sessioni o dati di autenticazione. La pagina Verificare il canale eseguito descrive come provare l’effetto operativo dopo questa classificazione.
Criteri osservabili
Sezione intitolata “Criteri osservabili”La policy è rispettata quando il repository resta utilizzabile senza distribuire segreti, il canale previsto è dichiarato, l’assenza del login produce un errore esplicito e l’accesso dell’agente non viene presentato come autorizzazione generale. Se uno di questi punti non regge, il flusso va escluso oppure progettato come integrazione di prodotto con proprietario, costi, revoca e monitoraggio propri.
Un abbonamento non garantisce disponibilità, parità fra superfici o diritto di impiego in un prodotto. Piani e condizioni cambiano; prima di affidarsi a un canale vanno controllati documentazione corrente e termini applicabili. La policy riduce l’esposizione di segreti nel lavoro personale, ma non sostituisce minimo privilegio, revoca o revisione dell’output.
Voci correlate
Sezione intitolata “Voci correlate”Non esiste una fonte normativa per questa policy locale. I riferimenti seguenti delimitano autorizzazione e configurazione, ma non dimostrano un diritto commerciale.
- NIST SP 800-162, riferimento per il controllo degli accessi basato su attributi; non tratta entitlement commerciali e non definisce questa policy.
- The Twelve-Factor App: Config, riferimento generale sulla separazione della configurazione dal codice.
Questa voce resta una sintesi editoriale di un criterio di progetto e non fa affermazioni correnti su piani o prezzi.