AI agentica: il contesto di sicurezza è fondamentale

AI agentica: il contesto di sicurezza è fondamentale

L’AI agentica può operare anche con accessi minimi, ma ciò non impedisce che possa violare le policy di sicurezza

A cura di James Hendergart, Senior Director, Technical Research, F5

La sfida

Il contesto di sicurezza (security context) definisce chi può fare cosa con un determinato insieme di dati in un’organizzazione. I permessi per creare, modificare o eliminare dati nei sistemi aziendali sono definiti in base ai diversi requisiti che l’organizzazione assegna a specifici ruoli. In un’azienda dove le persone ricoprono ruoli ben delineati, quando utilizzano software, quel software deve disporre di un contesto di sicurezza per poter operare. Questo contesto viene implementato tramite account. Il software, infatti, viene normalmente eseguito come account utente o come account di servizio. Gli account di servizio vengono creati per consentire al software di trattare dati aziendali in modo indipendente dal contesto di sicurezza di un utente specifico.

TI PIACE QUESTO ARTICOLO?

Iscriviti alla nostra newsletter per essere sempre aggiornato.

Assegnare accessi con privilegi minimi alle risorse aziendali è relativamente semplice per gli utenti, in base ai rispettivi ruoli. Tuttavia, per i servizi – sebbene comunque limitati – si tende a configurare accessi con privilegi più ampi, per permettere loro di eseguire tutte le azioni necessarie lungo un processo. Per esempio, un utente potrebbe avere accesso in scrittura solo ai dati relativi ai clienti a lui assegnati, e accesso in sola lettura a quelli degli altri. Gli account di servizio, al contrario, spesso necessitano di accesso in scrittura per tutti gli account.

Quando si utilizza l’AI agentica, le attività degli utenti e quelle dei processi aziendali si intrecciano. I processi aziendali sono progettati per produrre un risultato complessivo (ad esempio per tutti i clienti, dipendenti e istanze). Per funzionare, gli account di servizio richiedono spesso permessi più elevati rispetto a quelli dei singoli utenti, anche se sono questi ultimi ad avviare, monitorare e supervisionare i processi aziendali.

Leggi anche:  Deda Tech potenzia le soluzioni di sicurezza informatica con Google Cloud

Pensiamo ad esempio a un’organizzazione che impiega un assistente AI agentico per supportare l’onboarding dei nuovi dipendenti. Ogni nuovo assunto ha un ruolo specifico e, in base a questo, l’azienda deve accedere ai sistemi aziendali a un determinato livello. L’assistente AI agentico opera nel contesto del personale HR che gestisce l’onboarding. Cosa succede se l’agente AI deve creare un nuovo account utente con permessi superiori a quelli di uno o più membri del team HR?

Se i permessi dell’agente sono impostati in base al processo da eseguire, e non in base all’autorizzazione effettiva dell’utente che lo utilizza, possono verificarsi violazioni della sicurezza, perché il software controllato dall’utente concede accessi a dati che l’utente non dovrebbe visualizzare. D’altra parte, se l’azione viene bloccata per mancanza di permessi, l’utente non riesce a completare il compito.

Questo scenario può essere risolto suddividendo il processo: un sotto-task viene assegnato a qualcuno che ha l’autorità per concedere i permessi richiesti e, una volta approvato, il processo può proseguire. Questa tecnica di segmentazione delle azioni in base al contesto di sicurezza dovrebbe essere applicata anche alle soluzioni agentiche.

Mappare i cambi di contesto di sicurezza

L’utilizzo dell’AI agentica può aumentare la probabilità che il software, inizialmente eseguito nel contesto di un utente, finisca per ottenere privilegi elevati passando al contesto di un agente che opera con un account di servizio. In tal caso, è fondamentale che il sistema agentico operi in modo da evitare che l’elevato livello di accesso e privilegi porti a violazioni delle policy di sicurezza.

Attenzione alle lacune, ma avanti tutta

Progettare agenti AI con un contesto di sicurezza adeguato parte da una domanda fondamentale: il processo che si vuole automatizzare è pensato come assistente personale per uno o più utenti, oppure si tratta di un processo aziendale generalizzato che deve operare su larga scala per conto dell’azienda?

Leggi anche:  Bludis distribuisce Red Sift e rafforza l’area cyber resilience

Se è personale, occorre mappare il processo verificando che tutte le azioni e gli accessi ai dati siano conformi alla policy di sicurezza aziendale per quegli utenti specifici. Se emergono eccezioni, le azioni che richiedono privilegi elevati vanno separate e assegnate a chi ha i livelli richiesti.

Se invece si tratta di un processo aziendale generalizzato, bisogna esaminare il design degli account di servizio per verificare se l’accesso con privilegi massimi genera lacune di sicurezza, come nell’esempio iniziale, e accertarsi che i dati sensibili non vengano esposti a utenti non autorizzati.

Le organizzazioni dovrebbero includere il contesto di sicurezza nella progettazione sia degli agenti personali che di quelli aziendali. Separando i compiti che richiedono privilegi elevati e facendo attenzione a chi – utente o account di servizio – eseguirà l’azione, si riduce il rischio di lacune di sicurezza indesiderate.