Architettura di riferimento IAM dell'agente AI: identità e accesso

Separare i sette confini di controllo¶

Una connessione di rete riuscita dimostra la raggiungibilità. L'autenticazione verifica un'identità. L'autorizzazione risolve ciò a cui può accedere l'identità. La policy di runtime valuta questa azione e contesto. L'approvazione conferisce alla persona ammissibile una decisione limitata. L'esecuzione crea l'effetto collaterale. Le prove registrano l'unità completa per la revisione.

Mantieni ogni confine esplicito nell'architettura e nel modello di eventi. Una credenziale valida può ancora non avere l'autorità per lo scopo, l'importo, i dati, l'ambiente o il tempo richiesti. Una valutazione politica di successo può comunque richiedere un revisore indipendente. Un'approvazione può rilasciare solo la richiesta esatta e il contesto coperto.

Contesto del sistema e classi di identità¶

Tratta l'identità dell'agente come oggetto aziendale durevole e l'identità del carico di lavoro come istanza del software in esecuzione. Un'identità di servizio rappresenta una dipendenza o un gateway non umano. Lo strumento o il server di risorse autentica il chiamante e impone la propria autorizzazione. Un revisore utilizza un'identità umana con autorità decisionale attuale.

Alternativa testuale. Un utente umano delega uno scopo limitato a un agente e a un carico di lavoro. I servizi di identità e token autenticano le parti. Autorizzazione e policy valutano la richiesta. Un revisore decide le azioni sospese. Lo strumento esegue un'azione consentita. Ogni fase invia record all'archivio prove all'interno del confine di trust del tenant e dell'organizzazione.

Scorri orizzontalmente per esaminare il grafico.

Scegli un'identità dedicata, delegata o ibrida¶

Un'identità dedicata conferisce all'agente la propria autorità di proprietà dell'azienda. Un'identità delegata trasferisce l'attuale autorità di un utente nell'attività. Un ibrido registra entrambe le parti: l'agente rimane l'attore e l'umano rimane il soggetto o lo sponsor. Questa separazione supporta policy, revoche e audit accurati.

Gli account di servizio condiviso indeboliscono l'attribuzione e spesso garantiscono un ampio accesso permanente. Mantienili dietro un gateway mediato dal servizio quando un sistema di destinazione non può emettere credenziali dell'agente ristretto. Registra l'agente originante, il soggetto umano, la decisione politica e la ricevuta a valle per ogni chiamata mediata.

Richiesta e sequenza di autorità delegata¶

Vincola il soggetto umano, l'attore agente, il carico di lavoro, la delega, lo scopo, il target e la scadenza prima dell'emissione del token. Utilizzare una credenziale di breve durata legata al pubblico per la risorsa di destinazione. Risolvere nuovamente l'autorità corrente al confine dell'azione perché ruoli, assegnazioni, fatti di rischio e policy possono cambiare durante una sessione.

Alternativa al testo. L'utente assegna uno scopo all'agente. L'agente avvia un carico di lavoro attestato. Il carico di lavoro richiede un token. Il servizio token convalida l'attore e il soggetto delegato, quindi emette una credenziale vincolata al pubblico di breve durata. Il carico di lavoro invia il contesto completo alla policy. Lo strumento riceve solo una richiesta consentita o validamente approvata e restituisce una ricevuta di esecuzione.

Scorri orizzontalmente per esaminare il grafico.

Possiedi ogni dimensione di diritto¶

Il privilegio minimo diventa testabile quando ogni dimensione ha un proprietario, un punto decisionale, un percorso di revisione, un percorso di revoca e un campo di prova. Valuta la tupla completa per ogni richiesta consequenziale. Un ruolo può fornire una linea di base, mentre lo scopo, il valore, i dati, l’ambiente e il tempo mantengono ristretta la sovvenzione effettiva.

Combina deliberatamente i modelli di autorizzazione¶

Il controllo degli accessi basato sui ruoli fornisce un lavoro stabile o una base di servizio. Il controllo degli accessi basato sugli attributi valuta i fatti relativi a soggetto, risorsa, azione e ambiente. Il controllo degli accessi basato sulle relazioni risolve le relazioni grafiche come l'assegnazione, la proprietà o l'appartenenza al caso. L'accesso basato sulle capacità comporta un oggetto di autorità trasferibile ristretto che dovrebbe rimanere vincolato al target, limitato nel tempo e revocabile.

Utilizza la combinazione più piccola che esprime la decisione reale. Registrare gli input risolti e la sovvenzione effettiva finale in modo che i revisori possano riprodurre il risultato dopo le modifiche di gruppi, attributi, relazioni o stato delle capacità.

Flusso decisionale sui diritti e sull'approvazione¶

Valutare identità, tenant, delega, pubblico e scadenza prima di risolvere i diritti. L'autorità non valida o mancante interrompe la richiesta. La policy di runtime seleziona quindi consenti, avvisa, require_approval o blocca. Un'approvazione richiesta conserva la richiesta esatta e la rilascia solo dopo che un revisore indipendente idoneo decide prima della scadenza.

Alternativa al testo. Il flusso verifica l'identità e il contesto del token, quindi tutte e nove le dimensioni dei diritti. Blocchi di contesto non validi. La politica seleziona uno dei quattro risultati. Il blocco si ferma. Richiedi approvazione invia la richiesta associata a un revisore indipendente. Il rifiuto o la scadenza si fermano. Consenti, avvisa o approvazione valida viene eseguito una volta e registra la ricevuta e la prova.

Scorri orizzontalmente per esaminare il grafico.

Emettere credenziali di breve durata e controllare la rappresentazione¶

Emettere le credenziali dopo l'autenticazione del carico di lavoro e la risoluzione dell'autorità corrente. Associa ciascuna credenziale a un pubblico, un dominio di fiducia, un ambiente, una relazione tra soggetto o attore, scopo, ambito e durata breve. Mantieni i privilegi di aggiornamento e scambio più ristretti rispetto all'autorità originale.

OAuth 2.0 Token Exchange definisce token soggetto e attore separati per la delega. L'affermazione act può esprimere l'attore attuale. Gli indicatori di risorsa associano una richiesta di token alla risorsa di destinazione. Le richieste di autorizzazione ricche possono contenere azioni strutturate e dettagli sulle risorse. Ogni protocollo si basa ancora sul server di autorizzazione e sul server di risorse per applicare la politica locale e la revoca.

• Just in time: concedi l'accesso all'avvio dell'attività, dopo l'approvazione o l'assegnazione, e lo scade con l'attività.
• Rotazione: automatizza la sostituzione di chiavi e credenziali, conserva prove di generazione e sovrapposizione e testa le vecchie credenziali dopo il passaggio.
• Confine di rappresentazione: riserva la rappresentazione per casi espliciti in cui l'attore diventa indistinguibile dalla destinazione; preservare l'attore originale in un record protetto separato.
• Confini della delega: mantiene visibili sia il soggetto che l'attore e riduce l'autorità delegata per l'attività.
• Gestione dei token: esclude i segreti non elaborati dai log; conservare l'emittente, l'identificatore o il digest del token, il pubblico, gli ambiti, il tempo di validità, la scadenza e il risultato della revoca.

Politica di privilegio minimo riutilizzabile¶

La policy seguente è un esempio di progettazione indipendente dal fornitore per un lettore di documenti di revisione del credito. Copre tutte e nove le dimensioni dei diritti e collega il contesto mancante o scaduto a un blocco. Scarica il file JSON per workshop e test. Sostituisci ogni identificatore sintetico e soglia con un contratto locale approvato.

{
  "schema_version": "1.0",
  "policy_id": "credit-review-document-reader",
  "status": "example",
  "subject": {
    "agent_id": "credit-review-agent",
    "workload_id": "spiffe://bank.example/prod/credit-review",
    "delegated_user_required": true
  },
  "entitlements": {
    "tools": [
      "credit_application.read",
      "credit_memo.draft",
      "credit_decision.propose"
    ],
    "resources": [
      "credit-application:{case_id}"
    ],
    "data": {
      "fields": [
        "declared_income",
        "verified_income",
        "existing_exposure",
        "requested_amount"
      ],
      "denied_fields": [
        "special_category_data",
        "unrelated_household_records"
      ]
    },
    "actions": [
      "read",
      "draft",
      "propose_credit_decision"
    ],
    "purposes": [
      "credit_application_review"
    ],
    "amount": {
      "currency": "EUR",
      "approval_threshold": 25000,
      "authorization_ceiling": 100000
    },
    "environments": [
      "production"
    ],
    "time": {
      "maximum_token_lifetime_seconds": 900,
      "access_window": "case_assignment"
    }
  },
  "decision": {
    "allow_when": [
      "case_id matches the assigned case",
      "delegated user remains assigned and active",
      "all requested fields are allowed",
      "purpose equals credit_application_review",
      "requested amount is at or below EUR 25000",
      "token audience matches the target resource"
    ],
    "require_approval_when": [
      "the agent proposes a credit decision",
      "the requested amount exceeds EUR 25000 and is at or below EUR 100000"
    ],
    "block_when": [
      "identity, delegation, tenant, purpose, or audience is missing",
      "the credential, assignment, entitlement, or policy is expired",
      "the request targets an unassigned case or forbidden field",
      "the requested amount exceeds EUR 100000",
      "the destination or purpose differs from the authorized values",
      "the policy decision service cannot produce the required verdict"
    ]
  },
  "evidence": [
    "principal_id",
    "agent_identity_id",
    "workload_identity_id",
    "delegation_id",
    "tenant_id",
    "tool_id",
    "resource_id",
    "data_boundary_ref",
    "action",
    "purpose",
    "amount",
    "environment",
    "requested_at",
    "expires_at",
    "policy_id",
    "policy_version",
    "authentication_event_id",
    "authorization_decision_id",
    "policy_decision_id",
    "approval_decision_id",
    "reason_codes",
    "approval_id",
    "reviewer_id",
    "execution_receipt"
  ]
}

Esegui la verifica dei diritti come controllo¶

Una revisione inizia con un'identità e un accesso riconciliati alla popolazione, quindi verifica l'autorità effettiva e l'uso osservato. Scarica la cartella di lavoro sull'architettura IAM per l'elenco di controllo completo, le tabelle decisionali e il record di revisione.

• Riconcilia la popolazione. Confronta gli agenti registrati e gli account di servizio con emittenti di token, entità cloud, archivi segreti, gateway, rilevamento MCP, identità CI/CD, spesa dei pacchetti e chiamate agli strumenti osservate.
• Risolvi l'accesso effettivo. Includi sovvenzioni dirette, ruoli, attributi, relazioni, capacità, gruppi, deleghe, accesso temporaneo, regole di policy e autorizzazioni downstream.
• Trova eccezioni di controllo. Registra l'autorità orfana, condivisa, dormiente, duplicata, scaduta, non osservata, tra tenant, autoapprovabile ed eccessiva.
• Applicazione del test. Esercizio consentito, richieste di approvazione, bloccate, scadute, con contesto mancante, revocate e con relazione obsoleta.
• Riconcilia i risultati. Unisci ciascun campione al risultato della politica, alla decisione del revisore, alla ricevuta dello strumento, alla situazione aziendale e al record delle prove.
• Certifica il risultato con ambito. Registra criteri, popolazione, periodo, revisore, eccezioni, decisione, scadenza, revisione successiva e riferimenti alle prove.

Scopri e controlla gli account di servizio¶

Costruisci la popolazione di identità non umane da diverse fonti indipendenti. Solo alle directory delle identità mancano le credenziali create in progetti cloud, sistemi CI/CD, archivi segreti, client MCP locali, pianificatori, automazione del browser e applicazioni downstream. Le osservazioni di gateway e di rete rivelano identità che aggirano il catalogo previsto.

Per ogni account di servizio, registra il processo proprietario, la persona responsabile, gli agenti e i carichi di lavoro che possono utilizzarlo, la posizione delle credenziali, gli obiettivi consentiti, le sovvenzioni effettive, l'ultimo utilizzo, la scadenza, la rotazione, il metodo di revoca e l'origine delle prove. Metti in quarantena o revoca gli account senza proprietario attuale o senza utilizzo approvato dopo la revisione della sicurezza definita.

Revoca, interrompi, ripristina e ripristina¶

La revoca chiude l'autorità per un uso futuro. L'arresto di emergenza contiene lavoro attivo e in coda. Il rollback ripristina una versione o una configurazione sicuramente funzionante. Il ripristino degli incidenti riconcilia gli effetti a valle, emette nuove credenziali, verifica lo stato sicuro e utilizza una decisione di riavvio separata.

Alternativa al testo. Il proprietario dell'incidente registra l'ambito interessato e attiva uno stato di rifiuto. I controlli del flusso di lavoro annullano il lavoro attivo e in coda. I controlli dell'identità disabilitano l'agente e il carico di lavoro, revocano i token e ruotano le credenziali. I gateway rifiutano le nuove richieste. I proprietari degli strumenti riconciliano gli effetti accettati e quelli impegnati. Le prove registrano i riconoscimenti e gli accessi residui. Il ripristino utilizza una versione sicuramente valida, nuove credenziali, una lista consentita ristretta e l'approvazione del riavvio.

Scorri orizzontalmente per esaminare il grafico.

Applicare i confini del tenant e dell'organizzazione¶

Tratta tenant, organizzazione, dominio attendibile, ambiente e regione come fatti di autorizzazione con emittenti autorevoli. Convalidali a ogni confine esterno e usali nelle query del datastore, nel pubblico dei token, nel contesto delle politiche, nella ricerca di approvazioni, nell'instradamento degli strumenti e nella selezione delle prove.

Mantieni le identità di produzione e non di produzione in domini attendibili separati o spazi dei nomi equivalenti. Qualificare attributi e ruoli stranieri dall'autorità emittente. La federazione stabilisce quali credenziali possono essere autenticate tra domini; l'autorizzazione locale decide comunque quale azione e risorsa può utilizzare ciascuna identità straniera.

• Rifiutare un tenant o un selettore di organizzazione in conflitto con il token autenticato.
• Associa identificatori di risorse, limiti di relazione, funzionalità e approvazioni a un tenant.
• Utilizza token audience specifici per target ed evita token al portatore accettati da diverse risorse non correlate.
• Testa letture, scritture, approvazioni, delegazioni, chiavi di cache, code ed esportazioni di prove tra tenant.
• Registra il tenant autorevole e il dominio attendibile in ogni evento di identità, policy, esecuzione e prova.

Assegnare la responsabilità lungo tutto il ciclo di vita¶

Nominare un ruolo responsabile per ogni identità, diritto, decisione, effetto e confine di prova. I gruppi consultivi possono rivedere il progetto. L'autorità operativa rimane assegnata a una persona o a un ruolo con un delegato, un periodo di efficacia e un percorso di escalation definiti.

Seleziona un modello di distribuzione¶

Scegli il modello in base al proprietario dell'autorità, alla capacità del sistema target, alla conseguenza dell'azione, al volume dell'identità e all'attribuzione richiesta. Una singola organizzazione può utilizzare diversi modelli tra i processi preservando un modello di prova.

Esempio pratico: revisione del credito regolamentata¶

Una banca assegna un agente di controllo del credito al caso CR-1842. L'agente ha un'identità dedicata e viene eseguito con un carico di lavoro di produzione attestato. Il soggetto delegato per la presente fattispecie è un sottoscrittore nominato. Il servizio token emette una credenziale 15-minute il cui destinatario è il servizio documenti.

L'autorizzazione consente quattro campi approvati, tre azioni e importi fino a EUR 100,000 per lo scopo credit_application_review mentre l'assegnazione rimane attiva. La policy consente di leggere questi campi e di redigere un promemoria. Una proposta di decisione di credito o una richiesta superiore a EUR 25,000 crea una richiesta di decisione. Un nuovo scopo, un campo vietato, un importo superiore al limite di autorizzazione oppure blocchi di identità, delega, tenant, pubblico o policy correnti mancanti. L'approvazione opera all'interno del tetto autorizzativo.

Il sottoscrittore richiedente non può decidere sulla richiesta trattenuta. Un secondo revisore qualificato vede l'azione esatta, la fonte delle prove, le ragioni politiche, i requisiti dell'autorità, la scadenza e l'effetto previsto. L'approvazione rilascia la stessa richiesta associata una volta. La ricevuta downstream e lo stato del caso si uniscono ai record di identità, delega, autorizzazione, politica, revisore ed esecuzione.

Come l'architettura si associa agli attuali contratti KLA¶

Il Piano di controllo dell'KLA governa le azioni degli agenti strumentati. L'attuale implementazione fornisce una politica di runtime, un livello di approvazione, esecuzione, derivazione e prova. I provider di identità aziendali, i server di risorse e i sistemi di credenziali rimangono l'autorità per le loro identità e concessioni.

La mappatura seguente riflette il codice presente nell'origine del repository al commit a4e8087f. Il comportamento di distribuzione e produzione rimane non verificato. I collegamenti di origine sono aggiunti a quel commit. Lo stato distingue un contratto in corso da una mappatura parziale o da un'astrazione concettuale.

Attuali lacune dell'KLA e astrazioni concettuali¶

KLA valuta e registra l'autorità al confine dell'azione governata. In questo riferimento sono escluse diverse responsabilità IAM aziendali. Tratta i campi e i flussi sottostanti come requisiti di integrazione fino a quando il divario indicato non avrà un contratto attualmente implementato.

• Oggetto delegato. La creazione dell'esecuzione attualmente imposta onBehalfOfSubject sull'oggetto che ha avviato e registra il client chiamante. L'intero contratto di esecuzione pubblica attualmente è privo di un soggetto utente finale attestato separatamente e di una catena di delega.
• Ciclo di vita dell'identità. I provider di identità aziendali, le autorità di attestazione del carico di lavoro, le directory delle risorse umane e i sistemi di rilevamento degli account di servizio universale rimangono dipendenze esterne.
• Ciclo di vita delle credenziali. I connettori e i sistemi di destinazione possiedono l'emissione, la rotazione, la revoca, l'intermediazione e l'attivazione degli incidenti delle credenziali dello strumento downstream.
• Normalizzazione dei diritti. I contratti attuali supportano entità, risorse, azioni, attributi, argomenti degli strumenti, ambiente e contesto flessibile. Ogni percorso può rappresentare scopo, importo, dati e fatti relazionali attraverso campi flessibili; il contratto lascia la loro normalizzazione al produttore.
• Modelli di autorizzazione. RBAC, ABAC, modelli di relazione e di capacità in questo riferimento sono scelte di architettura. L’attuale contratto politico dell’KLA è indipendente dal modello.
• Certificazione. Il prodotto attuale registra controlli e prove. La certificazione universale dell'identità di un agente o della popolazione con diritti resta esclusa dal contratto attuale.
• Fan-out di revoca. È implementata la cancellazione del runtime. La disabilitazione dell'identità end-to-end, la revoca dei token, l'isolamento della rete, la cancellazione downstream e la compensazione rimangono azioni esterne coordinate.
• Record portatile. Lo schema del registro di controllo dell'agente AI normalizza diversi produttori KLA in un unico evento indipendente dal fornitore. I produttori attuali emettono i loro autorevoli documenti nativi, che il riferimento mappa nella busta pubblica.

Fonti primarie e freschezza¶

Questa architettura è stata verificata il 28 luglio 2026. Gli standard di identità, le specifiche del protocollo, la bozza di linee guida e i profili di implementazione possono cambiare. Ricontrolla l'origine live e la distribuzione locale prima di utilizzare uno stato in una decisione di controllo, approvvigionamento o sicurezza.

• Documento concettuale sull'identità e l'autorizzazione del software NIST NCCoE e dell'agente AI (bozza, pubblicata 5 febbraio 2026)
• Guida NIST SP 800-162, al controllo dell'accesso basato sugli attributi
• Progetto NIST di controllo degli accessi basato sui ruoli e riferimento allo standard attuale
• Architettura Zero Trust del NIST SP 800-207,
• Scambio token RFC 8693, OAuth 2.0
• RFC 8707, Indicatori di risorse per OAuth 2.0
• RFC 9396, OAuth 2.0 Richieste di autorizzazione avanzate
• Standard SPIFFE 1.15.2 e specifiche dell'identità del carico di lavoro
• Specifica dell'autorizzazione del protocollo Model Context, 25 novembre 2025
• Best practice per la sicurezza del Model Context Protocol