Identity & Access Management offre l'insieme completo di funzionalità che un'azienda si aspetta da un'autorità centrale per gli accessi. Predispone e gestisce gli account utente, conservando i dettagli del profilo, le informazioni di contatto e lo stato dell'account, e distingue con chiarezza tra la gestione amministrativa di un qualsiasi account e la modifica in self-service del proprio profilo. L'autenticazione è basata su credenziali con hashing robusto delle password, potenziata dall'autenticazione a due fattori basata sul tempo e da un insieme di codici di ripristino monouso conservati sotto cifratura per il caso in cui un secondo fattore venga smarrito.

Oltre al momento dell'accesso, il modulo mantiene un controllo attivo delle sessioni, così che le sessioni attive siano visibili, attribuibili a un principal, delimitate da una scadenza e revocabili singolarmente. L'autorizzazione è espressa mediante ruoli denominati che portano con sé autorizzazioni granulari, e tali autorizzazioni si estendono a ogni soggetto esposto dalla piattaforma. Il single sign-on è disponibile tramite connettori verso identity provider, consentendo all'organizzazione di federare l'autenticazione con la propria directory esistente pur mantenendo le decisioni di autorizzazione locali alla suite. La gestione di ruoli e autorizzazioni fa parte di questo modulo, offrendo agli amministratori un unico punto in cui definire ciò che ogni categoria di utente può fare.

Al centro del dominio si colloca il principal: un attore verificato sulla piattaforma, sia esso un dipendente identificato o un AI Worker, che possiede un'identità univoca, dettagli di contatto e uno stato dell'account che determina se possa agire o meno. Ogni principal è vincolato a esattamente un ruolo, ed è il ruolo, non l'individuo, a portare con sé le abilitazioni. Questa separazione deliberata mantiene le decisioni di accesso coerenti e verificabili: modificando un ruolo, ogni principal che lo detiene si muove insieme, anziché derivare verso un mosaico di eccezioni individuali.

Un ruolo è definito dal suo permission set, un'espressione strutturata di quali azioni il ruolo può compiere su quali parti della piattaforma. Azioni come lettura, creazione, aggiornamento, eliminazione e accesso sono associate ai soggetti di business a cui si applicano, e la piattaforma riconosce soggetti per ogni area funzionale che copre. I ruoli predefiniti spaziano da un amministratore senza restrizioni, passando per responsabili funzionali e tecnici, fino a un utente standard in sola lettura, e questi ruoli fondamentali sono protetti dall'eliminazione affinché il sistema mantenga sempre una linea di base coerente. Il concetto finale è la sessione, il registro della presenza autenticata di un principal, che porta con sé il proprio token, il proprio titolare e la propria scadenza. Insieme, queste quattro idee descrivono, in modo pulito e completo, chi è qualcuno, che cosa può fare e se al momento ha effettuato l'accesso.

Il flusso di lavoro più frequente è la predisposizione. Un amministratore crea un account, ne imposta il profilo iniziale e assegna un ruolo, e il nuovo principal è immediatamente governato dalle abilitazioni di quel ruolo senza ulteriori configurazioni. Le reimpostazioni delle password seguono lo stesso percorso amministrativo, mentre gli utenti ordinari mantengono il proprio profilo e registrano il proprio secondo fattore in self-service. La configurazione a due fattori abbina un'applicazione di autenticazione all'account ed emette codici di ripristino, e il titolare dell'account può rigenerare tali codici o riconfigurare il fattore al variare delle circostanze.

La revisione degli accessi è un flusso di lavoro a sé stante. Gli amministratori verificano chi detiene quale ruolo, modificano il permission set di un ruolo tramite un editor che raggruppa i soggetti sotto il modulo di appartenenza e vedono tali modifiche entrare in vigore in tutta la piattaforma senza dover ridistribuire nulla. La supervisione delle sessioni consente a un amministratore di visualizzare le sessioni attive e di revocare quelle che non dovrebbero più persistere, che è la risposta immediata a un dispositivo smarrito o a un dipendente in uscita. La disattivazione chiude il cerchio: un account può essere disabilitato in modo da conservare la propria cronologia e la propria traccia di audit pur perdendo la capacità di autenticarsi, preservando il registro senza preservare l'accesso.

Il modello di autorizzazione è basato su attributi anziché su un elenco grossolano di privilegi. Le autorizzazioni sono conservate come regole esplicite che abbinano un'azione a un soggetto, e la piattaforma dispone di un ricco registro di soggetti che copre ogni modulo, così che le abilitazioni possano essere tanto ampie quanto il controllo completo di un'area funzionale o tanto ristrette quanto la sola visibilità in lettura di un singolo soggetto. È questa granularità che consente a un responsabile tecnico e a un responsabile funzionale di coesistere, ciascuno con autorità sul proprio dominio e visibilità in sola lettura su quello dell'altro. Quando un principal si autentica, il permission set effettivo viene risolto e trasportato in un token firmato, e tale token viene aggiornato con un ciclo breve così che una modifica a un ruolo si propaghi alle sessioni attive nell'arco di minuti anziché permanere fino all'accesso successivo.

Il modulo è costruito secondo controlli di sicurezza consolidati. Le credenziali non sono mai memorizzate in chiaro, il materiale di ripristino è cifrato a riposo e i cookie di sessione sono emessi con i flag di protezione che impediscono l'accesso lato client e la trasmissione cross-site. L'accesso è soggetto a limitazione della frequenza per attenuare i tentativi di forza bruta, e ogni decisione di accesso è applicata al confine dell'interfaccia in modo che un controllo delle autorizzazioni non possa essere aggirato invocando direttamente un'operazione. Poiché lo stesso varco di applicazione copre sia l'uso interattivo sia l'accesso programmatico, le garanzie reggono che una richiesta arrivi da un browser, da un'integrazione o da un agente autonomo.

Identity & Access Management è la dipendenza condivisa da ogni altro modulo. Opera fianco a fianco con Security Management, che verifica la postura della piattaforma e utilizza il modello di accesso quando ragiona sull'esposizione, e con Privacy Management e Compliance Management, che ad esso si affidano per dimostrare che l'accesso ai dati personali e regolamentati è confinato ai principal abilitati. Connector Management fornisce le integrazioni con gli identity provider che rendono possibile il single sign-on, federando l'autenticazione con la directory dell'organizzazione. Il Notification Engine veicola gli eventi rilevanti per la sicurezza che questo modulo genera, come una nuova sessione o un cambio di ruolo, verso le persone che hanno bisogno di vederli.

Ogni modulo di business, da Accounting & Control passando per Marketing & Sales, Fleet Management, Human Resource Management e la Knowledge Base, esprime le proprie regole di accesso come soggetti all'interno del modello di autorizzazione di questo modulo, così che vi sia un'unica autorità e un unico vocabolario per le abilitazioni nell'intera suite. Module Management e la più ampia area di System Administration considerano l'identità come il substrato su cui è autorizzata ogni attività amministrativa.

Qui gli AI Worker sono principal al pari di ogni altro, predisposti con una propria identità, vincolati a un ruolo e limitati esattamente dalle autorizzazioni che quel ruolo concede, il che significa che un agente non può mai agire oltre l'autorità che gli è stata conferita. Operando in modalità conversazionale, un amministratore può chiedere a un AI Worker di riferire chi detiene un determinato ruolo, quali account hanno il doppio fattore abilitato o quali sessioni sono attualmente attive, e il Worker risponde interrogando i dati stessi del modulo. Data l'abilitazione appropriata, esegue anche azioni: predisporre un account, assegnare o modificare un ruolo, reimpostare una credenziale o revocare una sessione su richiesta.

I Worker osservano oltre che agire. Fanno emergere anomalie ed eccezioni, segnalando account privi di un secondo fattore, sessioni dal comportamento insolito o ruoli le cui abilitazioni si sono discostate dalla policy, e le sollevano attraverso il percorso di notifica per l'attenzione umana. Estraggono struttura dai documenti di supporto, trasformando un elenco di assunzioni e cessazioni o un modulo di richiesta accesso in proposte concrete di predisposizione e rimozione, e offrono supporto alle decisioni quando si valuta un cambio di ruolo, spiegando che cosa consentirebbe un determinato permission set. Aspetto più importante, un AI Worker può fungere da nodo di approvazione o revisione in un flusso di lavoro di accesso, così che l'assegnazione di un ruolo sensibile o una richiesta di predisposizione privilegiata si arresti in attesa del suo esame, con ogni giudizio registrato a fronte dell'identità stessa del Worker nella traccia di audit.