Identità degli agenti: chi agisce, con quale autorità

Separare principal, agente e sistema di enforcement per rendere governabili le azioni autonome

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.

practice

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’autorizzazione 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

trade-offs

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

enterprise-example

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

references

Per approfondire

Riferimenti esterni autorevoli per approfondire identità, delega e autorità limitata negli agenti. • NIST SP 800-63B Digital Identity Guidelines - NIST - https://pages.nist.gov/800-63-3/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

Da ricordare

I guardrail delimitano ciò che un agente può fare; identità e delega rendono verificabile per conto di chi lo fa, quale autorità sta esercitando e come revocarla o attribuirla a posteriori.

Per la prossima riunione

Nel vostro contesto, riuscite a ricostruire senza leggere il transcript la catena delegante → agente → autorità → azione per un’operazione autonoma rilevante?

Una domanda per te