Progettare un assistente AI delimitato: strumenti, permessi e limiti di contesto

Il confine reale di un assistente AI è il contratto di servizio che il sistema può eseguire, non l’elenco di divieti scritto nel prompt. Un modello può ricevere l’istruzione di non inviare messaggi e, nello stesso tempo, disporre di uno strumento e di credenziali che consentono di farlo. Per rendere il servizio controllabile occorre delimitare separatamente ogni capacità visibile all’utente: quali informazioni può usare, con quale identità agisce, quali operazioni può richiamare, fino a quale effetto può arrivare e quando deve fermarsi.

Che cosa deve poter fare l’assistente?

Il team deve anzitutto formulare una carta del servizio in una frase, quindi scomporla in operazioni osservabili e indicare esplicitamente ciò che resta escluso. Una formula utile è: «Per gli utenti ammessi, l’assistente può svolgere questa famiglia di compiti usando queste informazioni approvate per produrre questo risultato, ma non può assumere queste decisioni o generare questi effetti». La frase obbliga a nominare beneficiari, compito, dati, risultato e confine prima di collegare qualsiasi strumento.

Verbi come «aiutare», «gestire» o «occuparsi di» sono troppo ampi per diventare permessi. Vanno sostituiti con capacità come cercare, riassumere, proporre, preparare una bozza, aggiornare un campo, inviare, eliminare o approvare. Il NIST AI RMF invita a documentare scopo previsto, ambiente di impiego, compiti supportati, limiti di conoscenza, ambito applicativo, supervisione umana e tolleranza al rischio. OWASP raccomanda di esporre la funzionalità minima necessaria e di preferire un’operazione ristretta a un’estensione aperta.

• Indicare gli utenti ammessi e il contesto organizzativo in cui useranno il servizio.
• Separare ogni risultato informativo da qualsiasi modifica di uno stato esterno.
• Nominare il responsabile del servizio, del rischio, degli accessi e delle escalation.
• Dichiarare decisioni, dati e conseguenze che l’assistente non deve mai trattare.

La capacità, non l’intero assistente, diventa così l’unità di controllo. È una sintesi editoriale pratica, informata dai principi NIST e OWASP, non un requisito imposto da questi organismi. Il vantaggio operativo è concreto: una nuova funzione di invio non eredita automaticamente i dati, i permessi e le prove della funzione di ricerca. Ogni ampliamento dell’autorità resta una modifica identificabile, riesaminabile e, se necessario, revocabile senza spegnere l’intero servizio.

Quali informazioni può usare ogni capacità?

Ogni capacità deve operare entro un perimetro informativo definito, non semplicemente entro la finestra tecnica di token del modello. Il perimetro elenca sistemi ammessi, tipi di record, classificazioni, filtri sugli oggetti, intervallo temporale, requisiti di aggiornamento, diritti dell’utente e dati proibiti. Gli esiti Map del NIST chiedono di documentare limiti di conoscenza, ambito applicativo e modalità di utilizzo e supervisione degli output. Più spazio nel contesto non conferisce nuovi diritti e non rende vere informazioni prive di sostegno.

La provenienza determina anche il livello di fiducia. OWASP consiglia di trattare messaggi esterni, documenti, risposte API e contenuti recuperati come dati non attendibili, separandoli dalle istruzioni del servizio. Un allegato che ordina di ignorare le regole non deve trasformarsi in una direttiva operativa. Il gateway di recupero dovrebbe applicare diritti e filtri prima che il contenuto raggiunga il modello; la risposta deve essere rifiutata o qualificata quando le fonti necessarie sono inaccessibili, mancanti o non più aggiornate.

• Definire fonti, record, campi, classificazioni, date, filtri e criteri di freschezza ammessi.
• Separare istruzioni del servizio e contenuti esterni o recuperati.
• Stabilire cosa rimane nella sessione e cosa può diventare memoria persistente.
• Escludere segreti, credenziali e dati non necessari alla capacità.

Sessione e memoria persistente richiedono regole diverse. Per la memoria, OWASP richiama convalida prima della persistenza, isolamento per utente e sessione, scadenza, limiti dimensionali, verifica dei dati sensibili e protezione dell’integrità. Il team deve aggiungere modalità di cancellazione e categorie che non possono essere memorizzate. Durata e dimensione non hanno valori universali: vanno stabilite secondo necessità del servizio, rischio, privacy e gestione documentale, evitando che conversazioni precedenti allarghino silenziosamente il contesto di una nuova richiesta.

Come devono imporre il confine identità, strumenti e permessi?

Autenticazione, autorizzazione e approvazione devono essere decisioni separate, applicate nell’architettura di esecuzione. L’autenticazione stabilisce chi è l’utente, il client o il carico di lavoro; l’autorizzazione decide quale operazione è consentita su una risorsa protetta; l’approvazione accetta una specifica azione proposta. La specifica di autorizzazione MCP distingue server di risorse protette, client che agiscono per il titolare della risorsa e server che rilasciano token di accesso. È un riferimento pertinente alle integrazioni MCP protette, non una regola universale per ogni strumento.

L’identità operativa va scelta esplicitamente: autorità delegata dell’utente oppure identità di servizio controllata. Non si deve ereditare in modo implicito l’account privilegiato di un operatore. Per i server MCP protetti, la specifica raccomanda ambiti di privilegio minimo e consente di vincolare l’autorizzazione alla risorsa destinataria. OWASP raccomanda permessi minimi nei sistemi a valle, conservazione del contesto autorizzativo dell’utente e mediazione completa delle richieste da parte dei sistemi esecutivi. Il prompt può descrivere un limite, ma non è un controllo di autorizzazione.

• Esporre operazioni ristrette con parametri convalidati, non accessi generici a posta, database, browser o shell.
• Limitare verbi, risorse, oggetti, campi, destinazioni, durata delle credenziali e destinatario del token.
• Applicare limiti specifici per frequenza, tentativi, catene, lotti, spesa, tempo e arresto.
• Prevedere idempotenza, annullamento o interruttori di sicurezza quando la capacità lo richiede.

OWASP consiglia di legare l’approvazione di un’azione ad alto impatto ad attore, strumento, risorsa, parametri normalizzati, momento e scadenza. NCSC raccomanda privilegio minimo, impostazioni sicure, restrizioni sulle azioni e meccanismi esterni di sicurezza quando un componente AI può produrre effetti. Nessuna di queste misure elimina ogni errore o abuso; insieme rendono però il confine verificabile nel percorso che esegue l’azione, invece di affidarlo alla sola interpretazione linguistica del modello.

La conversazione può sembrare continua, ma la sua autorità deve restare divisa in capacità piccole e indipendenti.

Fino a quale effetto può arrivare una capacità?

Ogni capacità deve avere un tetto d’azione esplicito, con controlli indipendenti più forti man mano che aumenta l’effetto sul mondo esterno. Una scala editoriale pratica distingue: rispondere o riassumere; raccomandare o proporre; creare una bozza; effettuare una modifica circoscritta e reversibile; produrre un’azione esterna conseguente; incontrare una decisione proibita. La scala non è uno standard NIST, NCSC o OWASP: serve a rendere visibile dove cambiano autorità, prove e responsabilità.

• La risposta usa soltanto dati ammessi e non modifica sistemi esterni.
• La proposta mostra il passo successivo senza eseguirlo.
• La bozza rimane modificabile, non finale e assegnata a un revisore.
• La scrittura reversibile riguarda soltanto oggetti e campi approvati.
• L’azione esterna conseguente richiede anteprima, autorizzazione valida, approvazione puntuale e policy di esecuzione.
• La decisione proibita resta assente dagli strumenti e viene indirizzata a un processo separato.

Per le azioni conseguenti, OWASP suggerisce di separare decisione ed esecuzione e di convalidare l’approvazione puntuale prima di procedere. L’approvazione umana per un’azione ad alto impatto si aggiunge all’autorizzazione applicata a valle: non la sostituisce. Se cambiano destinatario, contenuto o altri parametri rilevanti, occorre una nuova verifica. NCSC raccomanda di limitare le azioni attivabili dall’AI e di prevedere, quando necessario, salvaguardie esterne basate o meno sull’AI.

Invii, pubblicazioni, pagamenti, concessioni di accesso, eliminazioni, modifiche in produzione, impegni esterni e giudizi professionali ad alto impatto devono rimanere sotto il controllo umano qualificato e le policy deterministiche appropriate all’organizzazione. Creare una bozza non equivale a inviarla; aggiornare un campo reversibile non autorizza una cancellazione; proporre una decisione non significa assumerla. Anche il consenso dell’utente non può trasformare in ammessa una decisione che la carta del servizio ha escluso.

Che cosa deve accadere quando l’assistente raggiunge un confine?

Rifiuto, aiuto parziale sicuro, passaggio a una persona ed escalation di sicurezza devono essere risultati espliciti del servizio, con vere condizioni di arresto. Gli esiti Measure del NIST comprendono il fallimento sicuro oltre i limiti di conoscenza documentati e prove in condizioni simili all’impiego. Il messaggio deve spiegare il confine in linguaggio semplice senza rivelare dettagli sensibili e senza fingere che una fonte, un’approvazione, una chiamata allo strumento o una scrittura abbiano avuto successo.

• Compito fuori ambito o informazione non ammessa.
• Autorizzazione insufficiente o approvazione necessaria.
• Evidenza mancante, inaccessibile o non aggiornata.
• Giudizio specialistico o decisione di policy richiesta.
• Strumento indisponibile o limite operativo raggiunto.
• Segnale di sicurezza che impone arresto e indagine.

Quando resta una parte sicura, l’assistente può offrire una bozza, una lista di controllo o una richiesta delle informazioni mancanti. Il passaggio deve includere obiettivo originario, contesto non sensibile pertinente, capacità tentata, motivo, evidenze disponibili o assenti, passo proposto e identificativo di tracciamento. L’esecuzione rimane ferma mentre interviene il responsabile; se la proposta cambia, le verifiche ripartono. Il passaggio ordinario, l’approvazione aziendale e l’incidente di sicurezza possono condividere evidenze, ma hanno destinatari e urgenze differenti.

NCSC raccomanda piani di incidente con scenari di risposta, escalation e rimedio, personale preparato e registri di audit di qualità. Tra i casi di abuso considerati da OWASP figurano aggiramento dell’approvazione, aumento dei privilegi, esfiltrazione dei dati, avvelenamento della memoria e uso ricorsivo degli strumenti. Questi casi devono alimentare stop, revoca e prove, senza trasformare ogni errore ordinario in un incidente. Il proprietario corretto deve poter sospendere la capacità interessata mentre le altre funzioni sicure restano disponibili.

Come trasformare i confini in un progetto operativo?

Il team deve compilare una riga del canvas per ogni operazione visibile all’utente e collegarla a controlli applicabili, evidenze, prove, metriche e responsabilità. La riga registra attore e autenticazione, perimetro informativo, sessione e memoria, operazione dello strumento, identità operativa, risorse autorizzate, tetto d’azione, approvazione, limiti, rifiuto, registro, scenari di valutazione, segnale operativo e proprietario. «L’assistente accede al CRM» non è una capacità; «riassume una pratica che l’addetto può già vedere» lo è.

Le indicazioni OWASP su funzionalità e permessi minimi sostengono la separazione pratica tra lettura, preparazione di bozze e invio. Consideriamo un assistente interno che aiuta il personale di supporto a trovare informazioni approvate e preparare risposte, ma non decide indennizzi, non modifica diritti del cliente e non assume determinazioni regolamentari. Le tre capacità possono condividere la stessa conversazione, pur mantenendo accessi, strumenti, concessioni, limiti, prove e passaggi distinti.

Il canvas non deve ridursi a documentazione statica. La guida OWASP sul monitoraggio comprende decisioni, chiamate agli strumenti, risultati delle autorizzazioni, identificativi delle approvazioni, versioni delle policy, esiti, uso delle risorse e anomalie, con oscuramento dei dati sensibili. Gli esiti Govern del NIST richiamano ruoli chiari, linee di comunicazione, responsabilità umane e dell’AI differenziate, monitoraggio continuo e riesame periodico. Ogni riga deve quindi indicare chi interviene, quali segnali osserva e chi può modificare o ritirare la capacità.

Quali prove servono per rilasciare e mantenere l’assistente?

Il rilascio richiede prove che il servizio ammesso funzioni e che dinieghi, arresti ed escalation previsti funzionino in condizioni simili a quelle operative. Il NIST AI RMF richiama prove rappresentative dell’impiego, monitoraggio in produzione, limiti documentati, fallimento sicuro e valutazioni periodiche di sicurezza. NCSC raccomanda una valutazione di sicurezza adeguata prima del rilascio e la comunicazione dei limiti e delle modalità di guasto note. Un insieme di test superato non costituisce una garanzia permanente.

• Richieste ammesse, parafrasi, ambiguità e informazioni mancanti.
• Accesso tra account, strumenti non autorizzati, dati proibiti e contesto non aggiornato.
• Contenuti recuperati manipolativi, esfiltrazione e tentativi di aggirare l’approvazione.
• Parametri cambiati, approvazioni scadute, tentativi duplicati e dipendenze indisponibili.
• Catene e consumo anomali, arresto del circuito, rifiuto e passaggio al responsabile.

I registri devono permettere di ricostruire chi ha richiesto cosa, quale capacità e policy si applicavano, quali classi di fonti e strumenti sono state usate, quali decisioni di autorizzazione e approvazione sono avvenute, quale esito è risultato e quali versioni erano attive. Non devono contenere segreti o contesto sensibile illimitato. NCSC raccomanda di monitorare output e prestazioni per rilevare cambiamenti improvvisi o graduali rilevanti per la sicurezza, rispettando privacy e protezione dei dati.

Assegnare proprietari distinti per comportamento del servizio, concessioni di accesso, passaggi aziendali e incidenti di sicurezza consente di sospendere, correggere o ritirare una capacità. Secondo NCSC, modifiche a dati, modelli e prompt possono cambiare il comportamento del sistema e devono riflettersi nei regimi di prova e valutazione. Lo stesso criterio pratico si applica a recupero, memoria, strumenti, permessi, policy, fornitori e contesto operativo: una modifica sostanziale riapre le prove e le evidenze delle capacità interessate.

Conviene iniziare dalla capacità utile più piccola e ampliarne l’autorità soltanto attraverso modifiche riesaminate, non con un ritocco isolato al prompt. Quando entrano in gioco dati sensibili, memoria persistente, accessi privilegiati, impegni esterni, modifiche distruttive o gestione degli incidenti, vanno coinvolti i responsabili organizzativi di sicurezza, identità, privacy, archivi, rischio e servizio. Giudizi legali, regolamentari o professionali ad alto impatto devono essere indirizzati a specialisti qualificati e a un processo governato separatamente.