Introduzione: il prossimo utente del tuo sistema potrebbe non essere umano
Il prossimo account che accederà ai tuoi sistemi potrebbe non appartenere a un dipendente. Potrebbe appartenere, o dovrebbe appartenere, a un agente AI.
Un responsabile delle operazioni chiede a un agente di preparare un rapporto settimanale. Apre una dashboard, scarica un CSV, legge una cartella di lavoro di Excel, confronta i risultati della settimana scorsa, crea un report e restituisce la bozza.
Il flusso di lavoro ha esito positivo, ma ogni registro registra alex@company.com. L'organizzazione non è in grado di stabilire cosa ha eseguito Alex, se l'agente ha superato il suo compito o se l'accesso è continuato.
Se un agente AI può interagire con i sistemi come un utente, dovrebbe continuare a prendere in prestito l’identità di un utente?
Questo è dove Identità non umana diventa centrale per la governance dell’IA. Le organizzazioni devono separare l'entità che svolge il lavoro dalle credenziali che utilizza e dalle autorizzazioni che riceve.
Cos'è un Non-Human Identity?
UN Identità non umana è un'identità digitale utilizzata da software, servizi, processi automatizzati, dispositivi, carichi di lavoro o agenti di intelligenza artificiale per autenticare e accedere ai sistemi senza agire come un utente umano.
Gli esempi includono account di servizio, entità servizio, identità gestite, carichi di lavoro, dispositivi, bot, script, pipeline CI/CD, integrazioni API e agenti AI.
Un Non-Human Identity non è automaticamente una chiave API, una password, un token, un certificato, una macchina, un bot o un modello. Queste possono essere credenziali, meccanismi di autenticazione, entità di esecuzione o risorse connesse.
Il modello ha tre domande:
- Identità: Chi o cosa recita?
- Credenziali: Come dimostra tale identità?
- Autorizzazione: A cosa può accedere o modificare?
Identità, credenziali e autorizzazione
| Concetto | Risposta alla domanda | Esempio |
|---|---|---|
| Identità | Chi o cosa recita? | Agente di segnalazione settimanale |
| Credenziali | Come dimostra la sua identità? | Token di accesso di breve durata |
| Autorizzazione | A cosa può accedere o modificare? | Leggi i dati del dashboard e scrivi file di report |
| Sponsor umano | Chi è responsabile dell'identità? | Responsabile delle operazioni |
| Ciclo vitale | Quando dovrebbe iniziare e terminare l'accesso? | Active per il flusso di lavoro e rivisto trimestralmente |
Una credenziale non è l'identità stessa. È una prova utilizzata da un'identità per autenticarsi.
I principali tipi di Non-Human Identity
Conti di servizio
Questi account supportano applicazioni, script, pianificazioni e integrazioni. I rischi includono proprietà condivisa, password statiche, accesso eccessivo e nessuna data di pensionamento.
Identità dell'entità applicazione e servizio
Rappresentano le applicazioni che accedono ad API, servizi cloud o risorse, inclusi SaaS e automazione interna.
Identità gestite e del carico di lavoro
Questi rappresentano carichi di lavoro software come macchine virtuali, contenitori, funzioni serverless, lavori CI/CD e applicazioni cloud. Le piattaforme supportate possono utilizzarli senza archiviare segreti permanenti direttamente nel codice.
Identità di macchine e dispositivi
Verificano server, laptop, apparecchiature di rete, sistemi industriali e dispositivi IoT tramite certificati, chiavi o record di dispositivi.
Identità degli agenti IA
Questi rappresentano gli agenti che interpretano gli obiettivi, scelgono gli strumenti, accedono alle risorse e intraprendono azioni. Gli agenti IA si adattano a Non-Human Identity, ma il loro comportamento adattivo li rende più difficili da governare rispetto agli account di servizio fissi.
Non-Human Identity rispetto alla macchina Identity rispetto al carico di lavoro Identity
Identità non umana è l'ombrello largo. Machine identity, identità del carico di lavoro, account di servizio e identità dell'agente sono categorie o modelli di implementazione più ristretti.
Non-Human Identity rispetto ai tipi Identity correlati
| Tipo Identity | Cosa rappresenta | Esempi tipici |
|---|---|---|
| Identità umana | Una persona reale | Dipendente, appaltatore, partner, cliente |
| Identità non umana | Un'entità basata su software o macchina che accede alle risorse | Service account, applicazione, bot, carico di lavoro, agente AI |
| Identità della macchina | Una macchina, un dispositivo, un server o un componente tecnico | Certificato del dispositivo, chiave del server, identità IoT |
| Identità del carico di lavoro | Esecuzione di software nel cloud o nell'infrastruttura | Contenitore, macchina virtuale, funzione serverless |
| Conto di servizio | Un account utilizzato da un'applicazione o da un'attività automatizzata | Account di report pianificati, integrazione del database |
| Identità dell'agente | Un'identità che rappresenta un agente AI | Agente di ricerca, agente segnalante, agente desktop |
La terminologia varia a seconda delle piattaforme. La governance dovrebbe concentrarsi su ciò che rappresenta l’identità, dove viene eseguita, a cosa può accedere e chi la possiede. Non tutti gli Non-Human Identity rappresentano una macchina fisica.
Perché gli agenti AI modificano il problema Non-Human Identity
Gli agenti seguono obiettivi, non solo istruzioni fisse
L'automazione tradizionale può copiare un backup a mezzanotte. Un agente a cui viene chiesto di indagare su prestazioni insolite e di preparare un rapporto può scegliere azioni diverse a seconda di ciò che trova.
Gli agenti utilizzano più strumenti
Un agente può spostarsi tra API, file, browser, fogli di calcolo, database, strumenti di comunicazione e agenti secondari. Ogni connessione estende la catena di autorizzazioni.
Le autorizzazioni variano in base all'attività
I flussi di lavoro di ricerca, reporting e assistenza clienti non dovrebbero ricevere lo stesso accesso permanente semplicemente perché utilizzano la stessa piattaforma.
Gli agenti possono delegare
Un agente principale può chiamare uno strumento specializzato o un altro agente. L'accesso dovrebbe essere tracciabile ed ereditato secondo regole chiare o autorizzato separatamente.
Gli agenti agiscono per conto delle persone
I sistemi dovrebbero distinguere le azioni umane, le azioni dell'agente richieste dall'uomo, i passaggi selezionati dall'agente all'interno di un'attività approvata e le azioni delegate. Agent identity deve preservare il collegamento tra richiedente, esecutore, credenziale e risultato.
Perché gli agenti IA non dovrebbero nascondersi dietro account umani
Un agente può utilizzare la sessione del browser, il token API, l'account e-mail o l'accesso all'applicazione di un dipendente. Il flusso di lavoro può funzionare, ma l'attribuzione diventa debole.
I registri mostrano solo l'account del dipendente, mentre l'agente eredita tutto ciò che il dipendente può raggiungere. I team di sicurezza non sono in grado di separare in modo affidabile il comportamento umano dall’automazione e l’accesso potrebbe sopravvivere oltre l’attività prevista.
Un modello di attribuzione migliore è:
- Iniziato da: Alex
- Eseguito da: Agente di segnalazione settimanale
- Ambiente: Desktop aziendale omologato
- Approvato da: Direttore finanziario
Lo sponsor rimane responsabile dello scopo, mentre l'identità dell'agente mostra ciò che ha eseguito il lavoro. Un agente dovrebbe agire per un essere umano senza diventare indistinguibile da quell’essere umano.
I principali rischi delle identità non umane non gestite
Identità orfane
L'accesso rimane attivo dopo che un dipendente lascia, un progetto termina, un'integrazione viene sostituita o un agente viene abbandonato.
Autorizzazioni eccessive
Viene concesso un ampio accesso perché politiche ristrette causano fallimenti e la convenienza temporanea diventa un privilegio permanente.
Credenziali di lunga durata
Le password statiche, le chiavi API, i certificati e i token possono rimanere utilizzabili anche molto tempo dopo che la necessità originaria è passata.
Identità condivise
Diverse applicazioni, agenti o dipendenti utilizzano un unico account, indebolendo l'attribuzione e la proprietà.
Espansione dell’identità
Service accounts, bot, app OAuth, token, script e agenti secondari si accumulano senza un inventario affidabile.
Responsabilità debole
Dopo un incidente, la responsabilità può essere contestata tra il richiedente, il proprietario del flusso di lavoro, il proprietario dell'applicazione, l'approvatore e i fornitori di tecnologia.
Il rischio più grande spesso non è che un’identità esista, ma che nessuno sappia perché esiste, cosa può fare o quando dovrebbe scomparire.
Un Non-Human Identity in otto fasi Lifecycle
Step 1: Scopri
Account del servizio di inventario, identità delle applicazioni, app OAuth, agenti locali e cloud, bot, script, certificati, pianificazioni, integrazioni API e strumenti connessi.
Step 2: Registrati
Registra un nome, tipo, scopo, creatore, sponsor, dipartimento, runtime, strumenti connessi, dati accessibili, tipo di credenziale e scadenza univoci.
Step 3: assegna uno sponsor umano
Una persona nominata dovrebbe approvare lo scopo, esaminare l'accesso, rispondere agli incidenti, trasferire la proprietà e autorizzare il ritiro.
Step 4: definisce il confine dell'identità
Documentare i sistemi, le cartelle, i record, gli strumenti, le azioni consentiti e i divieti espliciti.
Step 5: applica il privilegio minimo
Concedi solo ciò che richiede il flusso di lavoro corrente. Evitare l'accesso amministrativo permanente aggiunto semplicemente per ridurre gli errori.
Step 6: preferisce credenziali di breve durata
Laddove supportato, utilizzare token temporanei, identità gestite, federazione del carico di lavoro, credenziali con ambito attività, scadenza e revoca.
Step 7: monitora il comportamento
Cattura eventi di autenticazione, risorse a cui si accede, strumenti richiamati, file aperti, modifiche, trasferimenti, errori, tentativi e delega.
Step 8: ruota, trasferisci e ritira
Quando il flusso di lavoro cambia o termina, ruota le credenziali, trasferisci la proprietà, rimuovi le pianificazioni, revoca le autorizzazioni, disconnetti gli strumenti, ritira le identità secondarie e conserva i record di controllo.
Elenco di controllo del ciclo di vita dell'identità non umana
| Domanda Lifecycle | Risposta richiesta |
|---|---|
| Qual è l'identità? | Nome univoco e tipo di identità |
| Perché esiste? | Scopo aziendale documentato |
| Chi lo possiede? | Nominato sponsor umano |
| Dove corre? | Applicazione, dispositivo o carico di lavoro noto |
| A cosa può accedere? | Sistemi, file, dati e strumenti definiti |
| Come si autentica? | Credenziali approvate e gestite |
| Quando viene controllato l'accesso? | Data di revisione pianificata |
| Quando scade? | Condizione di scadenza o pensionamento definita |
| Come viene monitorata l'attività? | Registri, avvisi e processo di controllo |
Come fornire agli agenti AI l'accesso con privilegi minimi
Il privilegio minimo dovrebbe seguire il flusso di lavoro, non la capacità massima dell'agente.
Un agente che segnala settimanalmente potrebbe aver bisogno di una cartella di reporting, due dashboard, download di CSV, una directory di output e l'autorizzazione per preparare una bozza. Potrebbe non essere necessario l'intero disco rigido, ogni profilo del browser, l'e-mail personale, i controlli di fatturazione, la gestione delle autorizzazioni, l'eliminazione del file di origine o l'autorità per inviare il rapporto all'esterno.
Definire quattro livelli:
- Ambito delle risorse: Quali sistemi, cartelle, applicazioni e record?
- Ambito dell'azione: Leggere, scrivere, modificare, eliminare, pubblicare o inviare?
- Ambito temporale: Permanente, programmato, temporaneo o basato su attività?
- Ambito di approvazione: Quali azioni necessitano di conferma esplicita?
Il privilegio minimo limita ciò che un agente può vedere, cosa può fare, per quanto tempo può farlo e con l'approvazione di chi.
Perché gli agenti AI desktop necessitano di Clear Identity Boundaries
Gli agenti desktop possono interagire con file locali, applicazioni installate, sessioni del browser, credenziali salvate, download, schermate, contenuto degli appunti, controlli del sistema operativo e app di comunicazione. Il loro confine di identità può quindi estendersi su più di un'API.
Un flusso di lavoro desktop può comportare:
Richiedente umano -> canale di comunicazione -> agente desktop -> dispositivo aziendale -> identità del browser -> applicazione aziendale -> cartella di output
L'organizzazione deve sapere chi ha inviato l'attività, quale agente l'ha ricevuta, quale dispositivo e account sono stati utilizzati, quali azioni si sono verificate, quale output è stato creato e chi lo ha esaminato.
L'esecuzione locale può ridurre la trasmissione dei dati, a seconda della configurazione. Non rimuove il rischio di identità né risponde a chi rappresenta l'agente e quali autorizzazioni utilizza.
EasyClaw illustra perché gli agenti desktop necessitano di confini espliciti tra file, browser, applicazioni e output.
Come EasyClaw si inserisce in una strategia Identity con agente governato
EasyClaw è un agente del flusso di lavoro AI nativo per desktop per il lavoro che coinvolge file locali, applicazioni, interfacce browser, report, revisioni e cartelle di progetto. Non è una piattaforma di gestione delle identità né un sostituto di IAM, accesso privilegiato, rotazione delle credenziali o controlli delle minacce.
Il suo ruolo pratico è quello di illustrare perché un agente desktop dovrebbe operare all'interno di un confine di identità denominato, limitato, visibile e rivedibile.
Identificare il richiedente umano
Definisci chi può emettere attività EasyClaw, quali canali sono approvati, come si autenticano i richiedenti e chi può avviare flussi di lavoro sensibili. Ogni richiesta dovrebbe ricondurre a una persona specifica.
Identificare l'ambiente EasyClaw in esecuzione
Registra la distribuzione EasyClaw, il dispositivo aziendale, l'account del sistema operativo, il profilo del browser, le applicazioni approvate e il proprietario del flusso di lavoro. Il richiedente e l'ambiente di esecuzione sono connessi, ma non sono lo stesso attore.
Limitare l'ambito di file e applicazioni
Un flusso di lavoro di reporting potrebbe richiedere una cartella, una cartella di lavoro Excel, dashboard selezionati, un modello PDF e una directory di output. Non dovrebbe accedere automaticamente a ogni file locale, account browser, unità cloud, impostazione amministrativa o sistema non correlato. L'ambito chiaro riduce inoltre la selezione di file errati e le sovrascritture accidentali.
Mantenere le azioni consequenziali dietro l'approvazione
Richiedere l'approvazione umana per messaggi esterni, pubblicazione pubblica, eliminazione o sovrascrittura di file, invio di informazioni finanziarie, modifica dei record dei clienti, modifica delle autorizzazioni, completamento dei pagamenti e alterazione dei contratti.
EasyClaw può organizzare il lavoro intermedio, preparare pacchetti di revisione e restituire risultati utilizzabili. Le decisioni irreversibili, visibili esternamente, finanziariamente rilevanti o giuridicamente consequenziali dovrebbero rimanere di competenza dell’essere umano responsabile.
Documentare il ciclo di vita del flusso di lavoro
Ogni flusso di lavoro dovrebbe avere un nome, uno scopo, uno sponsor, input approvati, azioni, destinazione dell'output, data di revisione, condizione di interruzione e procedura di ritiro. Nuovi account, canali o destinazioni dovrebbero attivare la revisione.
EasyClaw dovrebbe funzionare come un agente desktop visibile e con ambito all'interno di un flusso di lavoro approvato, non come un software invisibile che prende in prestito accesso illimitato da un account umano.
Example: fornire a un agente segnalante EasyClaw un chiaro confine Identity
Un responsabile delle operazioni richiede: “Prepara il rapporto sulle prestazioni di questa settimana, confrontalo con la settimana scorsa e restituisci la bozza per la revisione.
Il flusso di lavoro EasyClaw approvato apre dashboard selezionati, scarica le esportazioni correnti, legge il tracker settimanale di Excel, confronta il report precedente, prepara una bozza, salva il pacchetto e lo restituisce. EasyClaw gestisce l'esecuzione pesante dei documenti, mentre i controlli di identità e sicurezza definiscono cosa può utilizzare.
Identity Boundaries per un flusso di lavoro di reporting EasyClaw
| Identity o componente | Ruolo | Confine richiesto |
|---|---|---|
| Responsabile delle operazioni | Avvia l'attività | Può avviare il flusso di lavoro di reporting approvato |
| Flusso di lavoro di reporting EasyClaw | Esegue l'attività | Limitato alle azioni di segnalazione |
| Informatica aziendale | Ambiente di esecuzione | Dispositivo approvato e gestito |
| Identità del browser | Legge i sistemi di prestazione | Accesso in sola lettura ai dashboard selezionati |
| Ambito di accesso ai file | Legge e scrive materiali di report | Solo cartelle di reporting settimanali |
| Directory di uscita | Memorizza i materiali generati | Cartella di revisione Dedicated |
| Revisore umano | Verifica il rapporto | Deve approvare le conclusioni finali |
| Canale di comunicazione | Restituisce il risultato | Solo richiedente approvato e percorso di consegna |
La catena di attribuzione dovrebbe rimanere visibile:
- Iniziato da: Responsabile delle operazioni
- Eseguito da: Flusso di lavoro di reporting EasyClaw
- Dati a cui si accede: Dashboard e cartella di reporting approvati
- Recensito da: Responsabile delle operazioni
- Distribuito da: Proprietario umano dopo l'approvazione
Ciò separa richiesta, esecuzione, accesso, approvazione e distribuzione. Se i numeri sembrano errati, il team può verificare le fonti approvate, i file utilizzati, l’output generato e la decisione del revisore. EasyClaw è il livello di esecuzione del flusso di lavoro; i sistemi di identità esistenti rimangono responsabili dell'autenticazione, delle credenziali, delle autorizzazioni e delle policy.
Conclusione: ogni agente ha bisogno di un Identity, un proprietario e una data di scadenza
Non-Human Identity include applicazioni, servizi, macchine, carichi di lavoro, script, bot, processi automatizzati e agenti AI.
Gli agenti IA alzano la posta in gioco perché il loro comportamento può essere adattivo, delegato e diffuso tra gli strumenti. Le organizzazioni devono sapere quale agente agisce, chi lo sponsorizza, quali credenziali e autorizzazioni utilizza, come vengono registrate le azioni, quando è richiesta l'approvazione e quando scade l'accesso.
EasyClaw non è una piattaforma di gestione delle identità. Il suo modello di esecuzione desktop mostra perché i flussi di lavoro degli agenti necessitano di proprietari nominati, accesso limitato a file e applicazioni, esecuzione visibile, output rivedibili e approvazione umana per azioni consequenziali.
Ogni agente AI ha bisogno di un'identità, uno sponsor umano, un limite di autorizzazione e una data di scadenza.
Domande frequenti
D: Una chiave API è Non-Human Identity?
R: Non da solo. Una chiave API è solitamente una credenziale; l'identità è l'applicazione, il servizio, il carico di lavoro, lo script o l'agente che lo utilizza.
D: Un account di servizio è uguale a Non-Human Identity?
R: Un account di servizio è una forma comune di identità non umana. La categoria più ampia comprende anche entità servizio, identità gestite, carichi di lavoro, macchine, dispositivi, bot, applicazioni e agenti.
D: Perché un agente AI non dovrebbe utilizzare un account dipendente?
R: Un'identità condivisa nasconde se una persona o un agente ha agito e può concedere un accesso eccessivo. Un modello governato registra il richiedente, l'esecutore, l'ambiente, l'accesso e il revisore.
D: Ogni agente AI necessita di un'identità separata?
R: Gli agenti di produzione dovrebbero essere sufficientemente distinguibili da supportare l'attribuzione, la policy, la revisione e la revoca. L'implementazione dipende dalle capacità della piattaforma, dal rischio, dalla sensibilità dei dati e dalle azioni consentite.
D: In che modo EasyClaw è correlato alla gestione di Non-Human Identity?
R: EasyClaw non è un servizio sostitutivo IAM o di gestione delle credenziali. I suoi flussi di lavoro desktop dimostrano perché i team dovrebbero definire richiedente, dispositivo, account browser, ambito del file, azioni, approvazioni, proprietà, revisione e ritiro.
D: Cosa dovrebbe registrare un flusso di lavoro EasyClaw?
R: Registra nome, scopo, sponsor, dispositivo, profilo del browser, file e app consentiti, azioni, approvazioni, destinazione, data di revisione e condizione di ritiro.
D: Quali azioni dell'agente dovrebbero richiedere l'approvazione umana?
R: Gli esempi includono comunicazioni esterne, pubblicazioni pubbliche, eliminazione di file, invii finanziari, pagamenti, modifiche ai record dei clienti, modifiche alle autorizzazioni e azioni contrattuali.