Blueprint Alliance: architettura condivisa per agenti IA

Dal blueprint di Okta a un’architettura condivisa

#

A marzo ho scritto del Blueprint di Okta per la Secure Agentic Enterprise. Le domande erano volutamente pratiche: Dove sono i miei agenti? A cosa possono connettersi? Cosa possono fare? Il punto di partenza era dare a ogni agente un’identità, un responsabile e connessioni governate. Lo è ancora. Ma raramente un agente vive nell’ambiente di un solo vendor. Può essere sviluppato su una piattaforma cloud, chiamare strumenti tramite MCP, recuperare dati da un altro provider, usare un’applicazione SaaS e affidare parte del lavoro a un secondo agente. Un unico control plane non vede da solo ogni passaggio.

Il 22 settembre 2026, Okta e altri undici membri fondatori hanno annunciato la Blueprint Alliance. AWS, CrowdStrike, Databricks, Docker, Google Cloud, Lovable, Proofpoint, Salesforce, ServiceNow, Wiz e Zscaler si sono uniti a Okta, rappresentando identità, IA, dati, applicazioni, infrastruttura e cybersecurity. GE Appliances e World Central Kitchen partecipano come consulenti strategici. L’Alliance ha pubblicato un blueprint multi-vendor ampliato e il white paper Governing Agentic Execution.¹²

Per me la novità più interessante è il cambio di prospettiva architetturale. Il blueprint originale di Okta descriveva come governare gli agenti mettendo l’identità al centro. L’Alliance si chiede come sistemi diversi possano collaborare quando un agente attraversa i loro confini.

Le domande ora sono quattro: Dove sono i miei agenti? Cosa possono fare? Cosa stanno facendo? Come posso intervenire?

Alla scoperta e al controllo degli accessi si aggiungono osservazione continua e risposta coordinata. È un’architettura di riferimento e un impegno dell’industria a verificare l’interoperabilità, non un’affermazione che ogni integrazione sia già disponibile.¹

Grafica della Blueprint Alliance tratta dall’annuncio di Okta.

Perché contano i confini tra vendor

#

Immaginiamo un agente di supporto che riceve una richiesta da un cliente. Consulta una knowledge base, legge un record in una piattaforma dati, apre un ticket in ServiceNow e chiede a un agente specializzato di verificare un’eccezione. Il suo lavoro attraversa identità, policy, reti e log diversi. Se governiamo solo la prima connessione, il passaggio successivo può perdere il contesto dell’utente originale. Se monitoriamo soltanto l’ultimo strumento, chi indaga può sapere cosa è successo senza sapere chi l’ha autorizzato.

I sei principi del white paper affrontano questa catena: trattare gli agenti come identità di primo livello; limitare l’accesso al compito; conservare la tracciabilità della delega; monitorare il comportamento a runtime; rendere il contenimento rapido e reversibile; adattare la governance mentre gli agenti cambiano.²

Il documento indica anche limiti importanti. I permessi completamente circoscritti al singolo compito e la delega tracciata end-to-end su più passaggi sono obiettivi che gli strumenti attuali non sempre realizzano. Un’implementazione pratica può combinare autorizzazioni brevi per il compito e permessi di base limitati. I runtime locali e i sub-agenti effimeri che ereditano lo scope del padre possono essere governati tramite contenimento sull’endpoint e controlli di delega, senza una voce di directory per ciascuno. Un gateway, da solo, non rende affidabile l’output del modello.

I membri stanno costruendo e testando l’interoperabilità con MCP, OCSF, SSF, CAEP e, come aggiunge il white paper, HTTP Message Signatures. Sono previste integrazioni di riferimento e la pubblicazione dei risultati dei test.¹²

Quattro domande, un unico ciclo di vita

#

1. Dove sono i miei agenti?

#

Non puoi riesaminare gli accessi di un agente di cui ignori l’esistenza. L’inventario deve comprendere gli agenti sviluppati internamente, quelli incorporati nel software acquistato e quelli creati dai dipendenti. La registrazione dovrebbe riportare un’identità distinta, la persona o il team responsabile, lo scopo, l’ambiente, lo stato nel ciclo di vita e le connessioni. Un service account o una chiave API possono ancora essere presenti, ma non sostituiscono l’identità dell’agente.

Il white paper collega discovery e postura di sicurezza: prima di considerare affidabile un agente importato, bisogna esaminare provenienza del software, vulnerabilità, configurazione e perfino le definizioni di tool o skill MCP.² Ricorda inoltre che la discovery nel browser e sugli endpoint deve rispettare i requisiti applicabili di privacy, lavoro e protezione dei dati. Ho approfondito il rapporto tra governance degli agenti e requisiti normativi nel mio articolo sull’EU AI Act. L’annuncio di Oktane 2026 descrive registrazione, importazione da AWS Bedrock e Salesforce Agentforce e discovery nel browser. Quella sugli endpoint ha una data di disponibilità pianificata distinta.³

La discovery è solo il primo passo. L’inventario invecchia quando un team clona un agente, cambia modello, aggiunge un tool o lo sposta tra ambienti. La verifica pratica è capire se ogni nuova connessione può essere ricondotta a un’identità registrata con un responsabile e se gli agenti orfani vengono trovati quando il loro referente cambia ruolo o lascia l’azienda.

2. Cosa possono fare?

#

La risposta è più precisa di un elenco di applicazioni raggiungibili. Un agente può avere il permesso di leggere un caso, ma non di modificare un metodo di pagamento; di chiamare uno specialista, ma non di delegare ulteriormente; di agire per un utente, ma solo entro i diritti di quell’utente. Il limite dei permessi deve accompagnare il compito anche nelle chiamate successive.

Qui Cross App Access (XAA) e la delega basata su token diventano concreti. Nella mia panoramica degli access pattern e nell’approfondimento tecnico confronto XAA con Secure Token Service, chiavi precondivise e service account. La domanda decisiva è se la risorsa possa verificare l’agente autorizzato e conservare il contesto della persona per conto della quale agisce. Un token OAuth dovrebbe avere audience, scope e durata limitati; la risorsa deve comunque applicare le proprie regole di autorizzazione. Un token valido non autorizza automaticamente ogni operazione di un tool.

Il white paper prevede anche separazione dei compiti, revisioni degli accessi e gestione del ciclo di vita.² Per un sub-agente, il permesso effettivo dovrebbe essere l’intersezione tra il suo scope e quello dell’utente o dell’agente che delega. Servono inoltre limiti alla profondità e all’ampiezza della delega. Le policy basate sull’intento sono un livello avanzato: il documento mette in guardia dall’usare il testo letterale del prompt come unico segnale dell’intento.² A Oktane 2026 Okta ha annunciato la disponibilità delle connessioni agent-to-agent e delle Resource Access Certifications. È in arrivo anche Configuration Designer, che permetterà di visualizzare le connessioni tra agenti e risorse, così da governare, circoscrivere e verificare ogni passaggio.³

Tra i recenti annunci di Okta, Agent SSO porta Cross App Access nei piani base di Okta SSO per gli agenti compatibili. È disponibile da agosto 2026.⁴ È un esempio di come integrare l’identità degli agenti in un modello di accesso esistente; approfondirò il prodotto e il suo flusso tecnico in un articolo dedicato.

3. Cosa stanno facendo?

#

Una revisione degli accessi dice cosa un agente potrebbe fare. La telemetria a runtime dice cosa ha fatto. Per un’indagine servono identità dell’agente, identità umana quando presente, risorsa raggiunta, tool e operazione, decisione della policy, timestamp, catena di delega e identificatore di correlazione. Serve anche abbastanza contesto per distinguere un flusso normale da una sequenza inattesa, senza registrare inutilmente prompt o dati sensibili.

Il white paper distingue gateway AI/LLM, MCP, di sicurezza, per agenti e API: ognuno osserva un confine diverso e l’API di destinazione deve comunque autorizzare le proprie richieste.² Prevede inoltre isolamento del runtime, rilevamento della prompt injection, prevenzione della perdita di dati, uso dei dati coerente con lo scopo e tracing. I log dovrebbero essere raccolti al confine di esecuzione, oscurando segreti e dati personali. I segnali di rischio correlati sono il collegamento tra i controlli; non esiste un solo gateway capace di vedere tutto.

Un altro annuncio recente è Agent Gateway, che colloca controlli di identità e policy nel percorso delle chiamate ai tool.⁵ È un esempio del contributo di un vendor al pilastro runtime dell’Alliance.

4. Come posso intervenire?

#

Quando un agente avvia una sequenza sospetta, un alert non basta. Serve un intervento proporzionato: limitare le chiamate, revocare token o sessioni, isolare il runtime interessato, preservare le prove e ripristinare il servizio dopo una nuova attestazione. Il white paper preferisce la risposta efficace meno dirompente: terminare un processo può distruggere informazioni utili presenti in memoria. Avverte anche che un kill switch è credibile solo se il runtime ospitante può davvero mettere in pausa o isolare l’agente bersaglio.²

Un segnale di rischio emesso da un sistema di monitoraggio dovrebbe identificare agente e sessione con precisione sufficiente perché un altro control plane agisca e invii una conferma. SSF e CAEP sono elementi utili, ma l’annuncio non dimostra che tutti e dodici i vendor condividano già workflow di contenimento operativi.¹²

Okta oggi descrive la disattivazione di un agente dalla console amministrativa come un blocco delle nuove sessioni. A Oktane ha inoltre annunciato l’estensione pianificata del Kill Switch ad Agent Gateway per revocare token attivi e interrompere sessioni in corso degli agenti connessi tramite il gateway.³ La distinzione conta in un piano di risposta agli incidenti: impedire il prossimo accesso e terminare quello già in corso sono controlli diversi.

L’architettura a quattro pilastri dal sito della Blueprint Alliance. Il PDF dell’architettura permette di vederla più da vicino.

Cosa dovrebbe verificare prima un’azienda

#

Il white paper suggerisce una sequenza utile: stabilire per prima cosa una telemetria normalizzata; scoprire e registrare gli agenti; aggiungere i livelli di autorizzazione; monitorare il runtime prima di automatizzare la risposta; poi testare il contenimento.² La applicherei a un agente che attraversa due sistemi, con un compito dai permessi limitati. A quel punto percorrerei le quattro domande end-to-end:

1. Inventario e responsabilità: puoi identificare l’agente, il suo ambiente, il modello o la versione, il responsabile e tutte le connessioni previste? Cosa succede all’identità se il responsabile lascia l’azienda?
2. Autorizzazione e delega: l’agente può dimostrare la propria identità? Se agisce per un utente, ogni risorsa di destinazione conserva quel contesto e applica uno scope più ristretto dei diritti complessivi dell’utente?
3. Evidenza a runtime: i log collegano richiesta dell’utente, identità dell’agente, chiamata al tool, decisione della policy e risorsa? Il team di sicurezza riconosce una sequenza di tool estranea al compito approvato?
4. Risposta e ripristino: puoi bloccare una nuova connessione, revocarne una attiva, preservare le prove e riabilitare l’agente attraverso una revisione documentata?

Farei anche un test destinato a fallire: chiedere all’agente di chiamare un tool fuori dal suo scope. Mi aspetterei un’operazione negata e un evento di audit comprensibile. In un secondo test cambierei il responsabile dell’agente o disattiverei la sua identità. Queste prove rivelano i punti di discontinuità tra identità, gateway, applicazioni e incident response meglio di una slide piena di spunte verdi.

Le lezioni apprese da Okta nell’uso interno degli agenti aggiungono una dimensione operativa. Jenna Cline racconta la registrazione in Universal Directory degli agenti, compreso Dex, il collaboratore digitale interno, e la limitazione dei loro accessi in relazione alla persona servita. Descrive anche la scelta di pochi agenti più capaci rispetto a una proliferazione incontrollata e la riduzione dei tool visibili a ciascun agente.⁶ Quest’ultima scelta può ridurre sia l’esposizione sia il contesto dei tool inviato al modello, ma va misurata in ogni workflow.

I cinque scenari “Blueprint in Action” del white paper sono esplicitamente esempi compositi.² L’architettura di runtime integra inoltre la sicurezza dei modelli e della supply chain.

Cosa seguirò nei prossimi mesi

#

Il sito della Blueprint Alliance e il suo white paper sono un buon punto di partenza. Il prossimo traguardo che vorrei vedere è un’interoperabilità pubblicata e riproducibile: un agente registrato in un sistema, una chiamata delegata verso un secondo, un segnale di rischio da un terzo e una risposta mirata con una traccia di audit completa. L’Alliance prevede di pubblicare integrazioni di riferimento e risultati dei test.¹

La lezione pratica è già chiara. La sicurezza degli agenti IA riguarda tutto il ciclo di vita. L’identità stabilisce chi è l’agente; l’autorizzazione limita ciò che può fare; i segnali a runtime mostrano cosa sta facendo; la risposta decide cosa accade quando devia. L’Alliance offre ai vendor domande comuni a cui rispondere insieme. La suite Okta for AI Agents (O4AA) contribuisce a tutte e quattro le risposte: scoperta e registrazione degli agenti, governo delle connessioni e degli accessi, visibilità sulle attività e controlli di risposta come disattivazione e contenimento. Agent SSO e Agent Gateway sono due annunci recenti che si inseriscono in questo percorso più ampio.³

Se stai costruendo un agente oggi, a quale delle quattro domande è più difficile rispondere nel tuo ambiente? Mi interessa capire dove i tuoi strumenti di identità e sicurezza perdono ancora il filo. Raccontamelo nei commenti o su LinkedIn.

Fonti e approfondimenti

#

• Annuncio della Blueprint Alliance, sito dell’Alliance e white paper
• Annuncio di Agent SSO, panoramica tecnica di Agent Gateway e disponibilità annunciate a Oktane 2026
• Lezioni dall’uso interno degli agenti in Okta
• Documentazione Okta su Cross App Access e panoramica OAuth di Cross-App Access
• I miei articoli precedenti: blueprint originale, access pattern degli agenti IA, approfondimento tecnico e considerazioni sulla conformità