CrowdStrike Blueprint Alliance contrappone l'unità dei fornitori al divario di identità degli agenti AI
CrowdStrike si è unita ad altri 11 fornitori fondatori in una nuova alleanza costruita attorno a un conflitto che le imprese non possono più evitare. Gli agenti AI hanno bisogno di un ampio accesso per essere utili, ma quello stesso accesso rende difficile governarli. CrowdStrike Blueprint Alliance punta a colmare questo divario con un'architettura di sicurezza condivisa.
La coalizione, denominata formalmente Blueprint Alliance, è stata lanciata il 22 settembre 2026. I suoi membri coprono identità, infrastruttura cloud, cybersecurity, piattaforme dati, sviluppo applicativo e software aziendale. Questa ampiezza conta perché un agente può attraversare diversi di questi domini per completare un unico compito.
L'annuncio è più di un'altra partnership CrowdStrike per la sicurezza degli agenti AI. Chiede a fornitori che competono per i budget aziendali di sostenere un modello operativo comune. Tale modello considera gli agenti come soggetti identificabili con autorità limitata, delega tracciabile, monitoraggio continuo e contenimento reversibile.
La domanda più difficile è se i principi condivisi diventeranno controlli interoperabili. Le imprese hanno bisogno di più di un accordo tra fornitori sulla terminologia. Hanno bisogno di comportamenti coerenti per individuazione, autorizzazione, registrazione e arresto tra prodotti non progettati come un unico sistema.
CrowdStrike Blueprint Alliance collega 12 componenti dello stack degli agenti
L'alleanza trasforma la sicurezza degli agenti AI da funzionalità a livello di prodotto in un problema di architettura tra fornitori.
I 12 membri fondatori sono AWS, CrowdStrike, Databricks, Docker, Google Cloud, Lovable, Okta, Proofpoint, Salesforce, ServiceNow, Wiz e Zscaler. GE Appliances e World Central Kitchen fungono da consulenti strategici.
Secondo l'annuncio ufficiale dell'alleanza, i membri svilupperanno un'architettura di riferimento aperta e multi-fornitore. Il lavoro amplia un blueprint di sicurezza introdotto per la prima volta da Okta nel marzo 2026.
L'architettura parte da quattro domande operative:
Dove si trovano gli agenti dell'organizzazione?
Cosa può fare ciascun agente?
Cosa sta facendo ciascun agente?
Come dovrebbero rispondere i difensori?
Queste domande sembrano basilari. La maggior parte delle aziende non riesce a rispondervi con coerenza tra account cloud, piattaforme software, ambienti di sviluppo, sistemi dati e strumenti installati dai dipendenti.
Un agente AI è un software in grado di interpretare un obiettivo, raccogliere contesto, selezionare strumenti e compiere azioni con supervisione limitata. Un agente per il servizio clienti potrebbe leggere un ticket di assistenza, esaminare la cronologia dell'account, approvare un rimborso e aggiornare un record CRM.
Ogni passaggio introduce un diverso punto di controllo. L'agente necessita di un'identità prima di autenticarsi. Necessita di autorizzazione prima di accedere a un record cliente. Le sue azioni richiedono monitoraggio durante l'esecuzione del compito. Il suo accesso deve essere revocato alla conclusione del compito.
I principi fondatori riflettono questa sequenza. I membri affermano che ogni agente dovrebbe ricevere un'identità di prima classe anziché utilizzare una credenziale umana. L'accesso dovrebbe essere limitato a un'attività, anziché concesso in modo permanente. La delega dovrebbe restare tracciabile quando un agente ne chiama un altro.
L'alleanza chiede inoltre un monitoraggio runtime continuo. Il monitoraggio runtime osserva ciò che un agente fa mentre opera, anziché basarsi esclusivamente sull'approvazione prima dell'esecuzione. Se il comportamento diventa pericoloso, il contenimento dovrebbe essere immediato e reversibile.
CrowdStrike entra in questo accordo dal lato del rilevamento e della risposta nella sicurezza aziendale. Okta offre controlli di identità, mentre AWS e Google Cloud rappresentano l'infrastruttura. Salesforce e ServiceNow gestiscono ambienti applicativi nei quali gli agenti possono avviare azioni aziendali.
Databricks copre l'infrastruttura dati, mentre Docker e Lovable riguardano flussi di sviluppo e distribuzione. Proofpoint, Wiz e Zscaler aggiungono controlli su comunicazioni, esposizione cloud e accesso alla rete.
Questa divisione dei ruoli spiega perché nessun singolo membro possa offrire l'intera architettura. Una piattaforma di identità può autenticare un agente, ma non può vedere automaticamente ogni azione a valle. Un prodotto di sicurezza endpoint o cloud può rilevare comportamenti sospetti senza controllare ogni autorizzazione a monte.
L'alleanza parte quindi da una diagnosi credibile. La sicurezza degli agenti attraversa sistemi posseduti da team diversi e forniti da fornitori diversi. La questione irrisolta è se tali fornitori collegheranno i loro controlli abbastanza in profondità da rendere continua la governance.
Perché gli agenti AI trasformano problemi di accesso noti in fallimenti più rapidi
Gli agenti amplificano le vecchie debolezze dell'identità perché possono riutilizzare autorizzazioni, concatenare azioni e operare più a lungo di una sessione umana.
L'automazione aziendale tradizionale utilizza già account di servizio, chiavi API e identità dei workload. I team di sicurezza sanno quanto tali credenziali possano diventare difficili da gestire quando la proprietà non è chiara o le autorizzazioni restano attive indefinitamente.
Gli agenti AI aggiungono percorsi decisionali incerti a questo problema esistente. La loro azione successiva può dipendere dall'output del modello, dai contenuti recuperati, dalle risposte degli strumenti o dalle istruzioni fornite da un altro agente. Il software può modificare il proprio percorso senza cambiare l'obiettivo dichiarato.
Questa flessibilità è la fonte dell'utilità di un agente. È anche il motivo per cui un accesso ampio e permanente presenta un rischio particolarmente serio. Un agente compromesso o manipolato può utilizzare autorizzazioni valide comportandosi però al di fuori dell'intento dell'operatore.
NIST ha identificato questo problema di identità come una priorità. La sua iniziativa sugli standard per gli agenti comprende sicurezza, identità, interoperabilità e standard guidati dal settore per agenti autonomi.
L'agenzia descrive gli agenti come sistemi capaci di azioni autonome su email, calendari, sviluppo software, acquisti e altri flussi di lavoro. La loro utilità dipende dalle connessioni con sistemi esterni e dati interni.
Tali connessioni sollevano diverse domande sovrapposte. L'organizzazione può distinguere un agente dal dipendente che lo ha avviato? Può identificare il proprietario dell'agente e l'origine del software? Può dimostrare quale autorità ha sostenuto una determinata azione?
La condivisione delle credenziali rende più difficili queste risposte. Un dipendente potrebbe collegare un assistente usando un token aziendale personale. Le applicazioni a valle vedono quindi l'identità del dipendente, anche quando è stato un agente a selezionare ed eseguire l'azione.
Questa configurazione indebolisce la responsabilità. L'applicazione può registrare una richiesta utente valida senza rivelare se una persona abbia approvato la specifica transazione. Gli investigatori della sicurezza ricevono un log tecnicamente accurato che manca del contesto più importante.
Il rischio cresce quando gli agenti delegano il lavoro. Un agente primario potrebbe chiamare un agente specializzato, che a sua volta invoca uno strumento tramite un servizio separato. Ogni trasferimento può oscurare l'utente originale, l'attività approvata e l'ambito residuo.
L'accesso a livello di attività offre un modello migliore. Un agente riceve soltanto le risorse e le azioni necessarie per un singolo incarico. L'autorità scade quando l'attività è completata, cambia sostanzialmente o viola una condizione definita.
Tuttavia, il privilegio minimo diventa più difficile quando il percorso necessario non è del tutto prevedibile. Un agente di ricerca può scoprire di aver bisogno di una fonte dati dopo aver iniziato il proprio lavoro. Concedere ogni possibile autorizzazione annulla lo scopo della limitazione per attività.
Le imprese necessitano quindi di autorizzazione dinamica. Un sistema di policy deve valutare identità, attività, risorsa, contesto e azione richiesta mentre il flusso di lavoro cambia. I passaggi ad alto rischio possono richiedere una nuova approvazione senza fermare ogni azione ordinaria.
Questa è la pressione alla base della Blueprint Alliance, spiegata in termini pratici. Le aziende desiderano agenti capaci di agire tra ambienti software frammentati. I team di sicurezza hanno bisogno che tali azioni restino attribuibili e delimitate a ogni passaggio di consegne.
Il principale compromesso è tra accesso utile e autorità controllabile
L'alleanza avrà successo solo se limiterà l'autorità degli agenti senza ridurre ogni flusso di lavoro a ripetute approvazioni umane.
Un agente privo di accesso ai sistemi è poco più di un'interfaccia conversazionale. Un agente con accesso illimitato può diventare un amministratore non monitorato. Le implementazioni aziendali devono operare tra questi due estremi.
Si consideri un agente che prepara un aggiornamento settimanale sulle vendite. Potrebbe leggere record CRM, recuperare dati di prodotto, analizzare riunioni recenti, redigere raccomandazioni e pubblicare un riepilogo. Questo flusso attraversa informazioni possedute da diversi sistemi e team aziendali.
L'agente non necessita dell'autorità per eliminare record clienti o modificare territori di vendita. Potrebbe avere bisogno di accesso in lettura ai dettagli degli account, ma soltanto dell'autorizzazione temporanea per pubblicare un documento. Il suo ambito dovrebbe seguire l'attività.
L'identità fornisce l'ancoraggio per queste decisioni. L'organizzazione necessita di un record univoco per l'agente, il suo proprietario, il suo sviluppatore e le sue capacità approvate. Tale identità dovrebbe restare visibile quando l'agente delega una parte del lavoro.
Le linee guida sull'identità di NIST affermano che gli agenti dovrebbero disporre di identificatori, credenziali e diritti univoci. Tali proprietà dovrebbero restare connesse alla persona o al sistema che gestisce l'agente.
Le tecnologie esistenti offrono una parte delle fondamenta. OAuth può delegare un accesso limitato senza condividere una password. I sistemi di identità dei workload possono autenticare processi software. I motori di policy possono valutare l'accesso alle risorse rispetto a condizioni definite.
Tuttavia, questi strumenti non catturano automaticamente l'intento di un agente. Un token valido può dimostrare che un software aveva l'autorizzazione di chiamare un'API. Non dimostra che l'azione risultante corrispondesse all'attività approvata da un utente.
Questa distinzione separa l'autenticazione dalla governance. L'autenticazione risponde a chi o cosa ha presentato una credenziale. L'autorizzazione determina cosa può fare tale identità. La governance collega tali autorizzazioni a proprietà, finalità, supervisione e revisione.
Il comportamento runtime aggiunge un ulteriore livello. Un agente potrebbe iniziare nel rispetto delle policy e poi recuperare istruzioni dannose da un documento. L'iniezione indiretta di prompt si verifica quando contenuti non affidabili manipolano un modello attraverso dati che l'agente è stato incaricato di elaborare.
Un'architettura sicura deve presumere che l'approvazione prima dell'esecuzione non sia sufficiente. Il monitoraggio dovrebbe confrontare le azioni dell'agente con l'attività dichiarata e i limiti consentiti. I difensori necessitano inoltre della capacità di sospendere o terminare l'esecuzione.
La reversibilità è particolarmente importante. Fermare un agente impedisce ulteriori azioni, ma non annulla un messaggio, una modifica al database o una transazione esterna. I sistemi necessitano di meccanismi di rollback ovunque l'applicazione sottostante li supporti.
Alcune azioni non possono essere annullate. Un segreto divulgato non può tornare privato. Un pagamento inviato fuori dall'organizzazione potrebbe non rientrare immediatamente. Un comando distruttivo può eliminare dati prima che il monitoraggio produca un avviso.
Blueprint Alliance non può risolvere questi vincoli specifici delle applicazioni con un unico controllo. Può definire come i prodotti si scambiano segnali di identità, autorizzazione, telemetria e risposta. Ogni piattaforma deve comunque applicare l'azione pertinente.
Ecco perché la tensione principale è un compromesso, non una semplice lacuna tecnica. Un accesso più ampio aumenta ciò che gli agenti possono realizzare. Restrizioni più forti riducono l'esposizione, ma possono anche interrompere i flussi di lavoro e aumentare gli oneri di approvazione.
Il risultato migliore non è un’autonomia illimitata né una conferma umana costante. È un’autonomia condizionata, in cui le azioni a basso rischio procedono e i passaggi sensibili attivano controlli più rigorosi. Raggiungere questo equilibrio tra 12 fornitori richiede più di un accordo sui principi.
La sicurezza degli agenti AI di CrowdStrike ora abbraccia diverse alleanze
CrowdStrike sta costruendo un’ampia presenza nella sicurezza degli agenti, ma coalizioni sovrapposte possono anche generare confusione sui risultati concreti.
La Blueprint Alliance è distinta dalla Open Secure AI Alliance, a cui CrowdStrike ha aderito all’inizio del 2026. I nomi suonano simili ed entrambe affrontano la sicurezza dell’AI, ma i loro approcci dichiarati differiscono.
Il 27 luglio CrowdStrike si è descritta come partner inaugurale della coalizione per la sicurezza aperta. L’iniziativa sostenuta da Nvidia pone l’accento su modelli aperti, ricerca condivisa, strumenti di sicurezza, valutazione e difesa collettiva.
La Blueprint Alliance si concentra più specificamente su un’architettura multi-vendor per gli agenti aziendali. I suoi temi centrali sono scoperta, identità, accesso con ambito limitato, delega tracciabile, monitoraggio in fase di esecuzione e contenimento.
CrowdStrike offre anche propri prodotti per la creazione e la sicurezza degli agenti. Charlotte AI AgentWorks consente alle organizzazioni di creare agenti di sicurezza personalizzati all’interno della piattaforma Falcon. CrowdStrike afferma che l’ambiente include governance e guardrail.
L’ecosistema AgentWorks dell’azienda supporta modelli e infrastrutture di diversi fornitori. Questo attribuisce a CrowdStrike un interesse commerciale diretto nelle regole che governano gli agenti aziendali.
La partecipazione a prodotti, partnership bilaterali e coalizioni può rafforzare l’influenza di CrowdStrike. Offre all’azienda accesso a diversi livelli di confronto tecnico, dalla ricerca aperta sulla sicurezza all’applicazione delle policy in ambito enterprise.
Può però anche frammentare l’attenzione. Le aziende si trovano ora di fronte a molteplici alleanze, framework, architetture di prodotto e standard proposti. Un vocabolario simile non garantisce un’implementazione compatibile.
Un’architettura di riferimento documenta componenti e relazioni. Non fornisce necessariamente un protocollo, una certificazione, una suite di test o un’integrazione pronta per la produzione. Gli acquirenti dovrebbero distinguere tra accordo architetturale e interoperabilità dimostrata.
L’ampiezza della Blueprint Alliance è un vantaggio se i membri contribuiscono con connessioni funzionanti tra i loro sistemi. Diventa una debolezza se ciascun fornitore applica i principi ai prodotti esistenti senza un comportamento tecnico comune.
Per esempio, ogni membro può sostenere l’idea della scoperta degli agenti usando però identificatori e formati di inventario diversi. Ogni membro può appoggiare il contenimento esponendo al contempo controlli di arresto incompatibili.
Il gruppo avrà bisogno di definizioni concrete. Cosa conta come agente? Come viene registrato un sottoagente effimero? Quale sistema possiede l’identità autorevole? Come si trasferisce l’autorità delegata tra confini cloud e applicativi?
Serve inoltre un modello di eventi comune. Il monitoraggio in fase di esecuzione è meno utile se un prodotto non può interpretare la telemetria di un altro. La risposta agli incidenti rallenta quando i team devono ricostruire le catene di identità e autorizzazione da log non correlati.
Sarà importante anche una validazione indipendente. I fornitori fondatori hanno incentivi a modellare un mercato emergente attorno alle proprie piattaforme. La loro partecipazione è preziosa, ma non sostituisce i test condotti da clienti, ricercatori o organismi di standardizzazione.
I consulenti strategici GE Appliances e World Central Kitchen possono contribuire a mantenere il lavoro ancorato alle operazioni reali. Ambienti produttivi, logistica umanitaria e software aziendale presentano diversi livelli di tolleranza per ritardi, autonomia e fallimenti.
Tuttavia, due consulenti non possono rappresentare ogni modello di distribuzione. Transazioni finanziarie, workflow sanitari, sviluppo software e agenti per consumatori introducono requisiti di responsabilità distinti. L’architettura deve rimanere adattabile senza diventare vaga.
Per gli acquirenti aziendali, la risposta prudente è interesse senza presunzioni. L’elenco dei membri segnala che i principali fornitori riconoscono un problema condiviso. Non dimostra ancora che i loro prodotti funzionino come un unico sistema governato.
Un’architettura di riferimento non è ancora uno standard applicabile
La maggiore incertezza è se l’alleanza pubblicherà interfacce testabili anziché un documento di progettazione allineato ai fornitori.
L’annuncio di lancio stabilisce principi e una struttura di coalizione. Non stabilisce uno standard obbligatorio. Non descrive nemmeno un’autorità di certificazione o un processo vincolante di conformità.
Questa distinzione è importante perché le architetture volontarie possono migliorare la pianificazione senza modificare il comportamento dei prodotti. Un’azienda può dichiarare l’allineamento a concetti generali quali il privilegio minimo e il monitoraggio continuo, implementandoli però in modo diverso.
Anche la scala prevista dall’alleanza merita un’attribuzione prudente. Il suo annuncio cita una previsione di Gartner secondo cui un’azienda globale media della Fortune 500 utilizzerà più di 150.000 agenti entro il 2028. Afferma inoltre che solo il 13 percento delle organizzazioni ritiene di disporre di una governance adeguata.
Queste cifre sono state presentate attraverso l’annuncio della coalizione. Anche se il numero di agenti dovesse crescere rapidamente, la definizione di agente influenzerà fortemente qualsiasi totale. Assistenti persistenti, sottoagenti di breve durata, automazioni e invocazioni di strumenti non dovrebbero essere conteggiati in modo intercambiabile.
La scoperta diventa difficile prima ancora che un’organizzazione raggiunga una scala lontanamente simile. I dipendenti possono autorizzare assistenti esterni senza una distribuzione centralizzata. Gli sviluppatori possono creare agenti temporanei durante i test. I prodotti SaaS possono aggiungere agenti incorporati attraverso aggiornamenti di routine.
Un inventario deve quindi combinare più segnali. I sistemi di identità possono mostrare credenziali e autorizzazioni delle applicazioni. Le piattaforme cloud possono mostrare i carichi di lavoro. Gli strumenti di sicurezza possono osservare processi, attività di rete e comportamento delle API.
Nessun singolo segnale cattura in modo affidabile ogni agente. Un agente può esistere brevemente, usare una credenziale condivisa o operare all’interno di un’altra applicazione. Per questo la struttura multi-vendor dell’alleanza ha senso.
Tuttavia, l’interoperabilità introduce proprie questioni di fiducia. I fornitori devono decidere quali dati di identità, contesti di autorizzazione e telemetria comportamentale scambieranno. I clienti avranno bisogno di controlli sulla quantità di informazioni sensibili che si sposta tra le piattaforme.
I falsi positivi rappresentano un altro rischio. Il contenimento automatico può interrompere attività legittime se il monitoraggio interpreta erroneamente un’azione insolita. Un contenimento debole lascia attivo un agente pericoloso. L’architettura necessita di modi per calibrare la risposta in base all’impatto e al livello di fiducia.
Anche i controlli umani richiedono una progettazione attenta. Richiedere l’approvazione per ogni decisione elimina gran parte del beneficio in termini di produttività. Consentire agli operatori di approvare categorie ampie può ricreare accessi permanenti sotto un nome diverso.
La coalizione dovrebbe definire proprietà misurabili. Un prodotto partecipante potrebbe dimostrare di preservare la cronologia delle deleghe lungo un passaggio di consegne. Un altro test potrebbe verificare che un’autorità revocata interrompa l’accesso ai servizi connessi entro un intervallo dichiarato.
Le suite di test consentirebbero ai clienti di confrontare le implementazioni. Schemi condivisi aiuterebbero le piattaforme a scambiare dati di inventario e attività. La certificazione potrebbe mostrare che un prodotto soddisfa requisiti di base senza implicare una sicurezza completa.
L’alleanza dovrebbe inoltre documentare il comportamento in caso di guasto. L’architettura di sicurezza descrive spesso il percorso previsto, dedicando meno attenzione a servizi di policy non disponibili, telemetria ritardata o revoca parziale.
Un agente non dovrebbe ottenere un’autorità più ampia perché un controllo diventa irraggiungibile. Tuttavia, una risposta di negazione predefinita può bloccare processi aziendali essenziali. La modalità di guasto appropriata dipende dall’attività e dalle sue conseguenze.
Finché questi meccanismi non appariranno, la Blueprint Alliance rimarrà una proposta seria anziché un livello di sicurezza verificato. Il suo valore risiede nell’allineare le giuste categorie di fornitori attorno alle giuste domande. L’esecuzione determinerà se questo allineamento cambierà il rischio.
Tre segnali mostreranno se l’alleanza può mantenere le promesse
Il prossimo test non è un altro annuncio di adesione, ma la prova che l’architettura funziona tra prodotti gestiti in modo indipendente.
Il primo segnale è una specifica tecnica pubblicata. L’alleanza dovrebbe definire campi di identità degli agenti, registri delle deleghe, contesto di autorizzazione, formati di telemetria e interfacce di risposta.
Una specifica dettagliata rafforzerebbe l’ipotesi che i membri intendano costruire controlli condivisi. Un framework di alto livello con mappature specifiche per prodotto la indebolirebbe, perché i clienti avrebbero comunque bisogno di integrazioni personalizzate.
Il secondo segnale è una dimostrazione multi-vendor funzionante. Un esempio credibile dovrebbe seguire un agente attraverso sistemi di identità, cloud, dati, applicazioni e sicurezza.
La dimostrazione dovrebbe mostrare autorizzazioni limitate al compito, lavoro delegato, monitoraggio in fase di esecuzione e revoca. Dovrebbe inoltre mostrare come gli investigatori ricostruiscono la catena dopo un’azione non sicura.
Questa evidenza rivelerebbe se la sicurezza degli agenti AI di CrowdStrike può acquisire contesto di identità e attività dagli altri membri dell’alleanza. Mostrerebbe inoltre se tali sistemi possono agire sulle rilevazioni di CrowdStrike.
Il terzo segnale è il test indipendente. NIST, partner aziendali di progettazione, ricercatori di sicurezza o un altro gruppo neutrale dovrebbero valutare come l’architettura gestisce la condivisione delle credenziali, l’iniezione indiretta di prompt, autorizzazioni eccessive e agenti compromessi.
Risultati indipendenti rafforzerebbero le affermazioni di sicurezza dell’alleanza. Test ritardati, dimostrazioni chiuse o la sola autocertificazione lascerebbero irrisolta la questione centrale.
Gli acquirenti non devono aspettare prima di migliorare i propri controlli. Possono creare un inventario degli agenti attuali, eliminare le credenziali condivise, assegnare proprietari chiari e restringere le autorizzazioni persistenti.
I team dovrebbero inoltre documentare quali azioni richiedono l’approvazione umana e quali possono procedere automaticamente. Ogni workflow sensibile necessita di registri che colleghino agente, utente, attività, autorizzazione, strumento e risultato.
Le organizzazioni che sviluppano agenti interni possono conservare materiali di origine, approvazioni e decisioni operative in una base di conoscenza AI ricercabile. Tale registro non sostituisce la telemetria di sicurezza, ma può preservare il contesto aziendale alla base delle distribuzioni degli agenti.
La CrowdStrike Blueprint Alliance è importante perché identifica il piano di controllo che manca alle aziende. Gli agenti devono essere individuabili, identificabili singolarmente, autorizzati in modo ristretto, osservati continuamente e rapidamente contenibili.
I suoi membri devono ora tradurre questo consenso in un comportamento interoperabile. I team aziendali dovrebbero chiedere ai fornitori schemi, test, garanzie di revoca e dimostrazioni multipiattaforma. Queste risposte mostreranno se l’alleanza sta costruendo un’infrastruttura condivisa o semplicemente un vocabolario condiviso.
