Issue 10068
Identità degli agenti: chi agisce, con quale autorità
Separare principal, agente e sistema di enforcement per rendere governabili le azioni autonome
· 5 min
Obiettivo
Progettare identità e autorizzazioni degli agenti separando chi agisce, per conto di chi agisce, quali operazioni può eseguire e per quanto tempo l'autorità delegata resta valida.
Identità e delega non sono la stessa cosa dei guardrail
I guardrail rispondono alla domanda: quali azioni sono tecnicamente consentite a un agente? Identità e autorità delegata rispondono a domande diverse: chi sta agendo, per conto di chi, con quale autorità e chi può dimostrarlo dopo l’esecuzione. I due livelli sono complementari. Puoi avere ottimi guardrail e restare comunque incapace di attribuire correttamente un’azione se agente, utente e orchestratore condividono la stessa identità o la stessa credenziale. Quando un agente compie un’azione, l’architettura deve quindi rendere esplicita una catena: il principal esprime l’intento; un’identità operativa dell’agente esercita una capability o un’autorizzazioneGlossarioAutorizzazioneLa decisione che stabilisce se un soggetto può eseguire una determinata azione su una specifica risorsa, considerando il contesto applicabile.Apri la voce completa delegata; un enforcement point applica la policy; il sistema registra quale autorità è stata effettivamente usata. Questo è ciò che rende possibili attribuzione, revoca e audit indipendentemente dal comportamento narrato dall’agente. La regola pratica è evitare l’impersonazione implicita. Non far ereditare all’agente tutti i privilegi dell’utente o dell’orchestratore solo perché sta lavorando “per conto” di qualcuno. Concedi invece un’autorità delimitata da operazioni consentite, risorse raggiungibili, contesto dell’intento e durata. Se il perimetro deve cambiare, cambia la delega: non allargare silenziosamente l’identità dell’agente. Il testGlossarioTestUna verifica deliberata che produce evidenze su una specifica aspettativa o rischio.Apri la voce completa architetturale più utile è semplice: a posteriori, senza leggere il transcript, puoi ricostruire chi ha delegato, quale agente ha esercitato l’autorità, quale policy l’ha consentito e quale azione è stata eseguita? Se la risposta è no, hai un problema di identità e delega, non solo di logging. • Distinguere principal, identità operativa dell’agente ed enforcement point • Rendere esplicita la catena delegante → agente → autorità → azione • Evitare l’impersonazione implicita tramite credenziali condivise o privilegi ereditati • Limitare scope, contesto e durata della delega • Produrre audit verificabile senza dipendere dal transcript dell’agente
Cosa guadagni e cosa paghi con una delega esplicita
Separare identità e autorità aumenta accountability e contenimento del rischio, ma introduce più design work. Devi decidere come propagare il principal, come rappresentare la delega, dove applicare la policy e come correlare gli eventi di audit. In sistemi distribuiti questo può richiedere token exchange, capability ristrette o altri meccanismi che evitino di trasformare ogni hop in impersonazione permanente. Il guadagno è sostanziale: puoi revocare l’autorità dell’agente senza revocare l’utente, restringere una delega senza ridisegnare tutto il workflow e distinguere un errore dell’agente da un abuso del principal o da una policy troppo permissiva. Inoltre, security e platformGlossarioPlatformUn insieme gestito di capability riusabili che permette ai team di consegnare e operare soluzioni tramite interfacce definite.Apri la voce completa team possono ragionare sulla provenienza dell’autorità invece di affidarsi a una generica identità di servizio. Il costo principale è la complessità di lifecycle: emissione, scadenza, revoca, propagazione e audit. Un modello troppo frammentato rallenta i team; uno troppo generico rende invece indistinguibili azioni che hanno origini e responsabilità diverse. Il compromesso corretto non è tra sicurezza e velocità in astratto, ma tra quanto contesto di delega devi preservare e quanto rischio accetti di perdere nell’attribuzione. • Più accountability in cambio di maggiore complessità di identity propagation • Delega esplicita riduce l’impersonazione ma richiede lifecycle e revoca • Token o capability troppo generici semplificano il flusso ma impoveriscono l’attribuzione • Audit utile significa conservare la provenienza dell’autorità, non solo l’identità tecnica che ha effettuato la chiamata
Un agente che prepara cambi operativi in un’azienda regolata
Immagina una banca che usa un agente per preparare modifiche a configurazioni di accesso o a parametri operativi sensibili. Il responsabile di servizio esprime l’intento, ma l’agente non opera con le sue credenziali e non impersona l’orchestratore. Riceve invece una capability temporanea emessa per quello specifico intento, limitata a determinate risorse e operazioni. Nel percorso di esecuzione restano visibili quattro elementi distinti: chi ha delegato, quale identità agente ha usato la capability, quale policy ha autorizzato l’operazione e quale sistema ha applicato la decisione. Se il cambiamento supera una soglia di rischio, il workflow può richiedere un gate separato, ma il punto centrale non è il gate in sé: è che anche dopo l’approvazione l’autorità esercitata resta attribuibile e limitata al contesto autorizzato. Nel log non si salva quindi solo il transcript. Si conserva una catena verificabile di delega e utilizzo dell’autorità. Se emerge un comportamento inatteso, security può revocare quella capability o correggere la policy senza disabilitare il principal né bloccare l’intera piattaforma agentica. L’autonomia tecnica resta così distinta dall’autorità organizzativa. • Principal e agente mantengono identità distinte • La delega è emessa per un intento e uno scope espliciti • Policy ed enforcement restano verificabili lungo il percorso • L’audit ricostruisce delega e autorità anche senza transcript • Revoca e remediation possono colpire la capability senza bloccare tutto il sistema
Per approfondire
Riferimenti esterni autorevoli per approfondire identità, delega e autorità limitata negli agenti. • NIST SP 800-63B-4: Authentication and Authenticator Management — NIST — https://pages.nist.gov/800-63-4/sp800-63b.html • OAuth 2.0 Authorization Framework - IETF RFC 6749 - https://www.rfc-editor.org/rfc/rfc6749 • Zero Trust Architecture - NIST SP 800-207 - https://csrc.nist.gov/publications/detail/sp/800-207/final