Security Copilot non si installa: è capacità che si provisiona, delega che si concede con due ruoli propri, superficie che si estende con plugin e agenti. Quattro livelli, permessi diversi.
Il workspace, e dove si ferma la documentazione
Il workspace compare alla prima esecuzione, quando provisioni la capacità:
https://securitycopilot.microsoft.comLa documentazione lo definisce come un ambiente delimitato e legato al tenant in cui operano utenti, automazioni e agenti, con un nome che segue le regole di denominazione Azure. È il perimetro a cui si applicano l’assegnazione dei ruoli (solo i ruoli owner selezionati ereditano owner su quel workspace), la disponibilità dei plugin personalizzati e degli agenti.
Oltre questo, Microsoft non pubblica una pagina di configurazione del workspace: qui non troverai passaggi né nomi di menu, perché non esistono in una fonte citabile. La superficie documentata è quella della capacità.
La capacità si misura in Security Compute Unit: minimo 1 SCU, massimo 100, con 3 raccomandate per un’esplorazione iniziale. Si rinnova a blocchi di ora piena — 9:00-10:00, non 9:05-10:05 — e le SCU non consumate non si accumulano; se finiscono, le richieste si fermano a meno che non ci sia overage, fatturato a consumo con una cifra decimale. Due dettagli che costano soldi: la fatturazione parte appena crei la capacità, anche se non l’hai agganciata a un ambiente, e i cambi di provisioning vanno fatti a inizio ora. Per crearla servono Contributor o Owner sulla subscription o sul resource group, più Security Administrator o superiore nel tenant. La posizione di valutazione dei prompt si sceglie; i dati restano nel geo del tenant di origine.
Due ruoli che non danno accesso a nessun dato
Security Copilot ha due ruoli propri, Copilot owner e Copilot contributor. Non sono ruoli Entra e da soli non concedono l’accesso a nessun dato di sicurezza. La piattaforma usa l’autenticazione on-behalf-of: un analista con Copilot contributor crea sessioni, ma per vedere gli incidenti di Sentinel gli serve comunque un ruolo Azure come Microsoft Sentinel Reader. Copilot non va mai oltre l’accesso che l’utente ha già.
Alcuni ruoli ereditano owner automaticamente: in Entra, Billing Administrator, Compliance Administrator, Global Administrator, Intune Administrator, Security Administrator; in Purview, Compliance Administrator, Data Governance Administrator, Organization Management. La piattaforma impone sempre almeno due owner.
Per i contributor il default sulle istanze nuove è il gruppo “Recommended Microsoft Security roles”: tutto-o-niente. Il vecchio gruppo “Everyone” sopravvive dove già esiste, con un vincolo irreversibile — una volta rimosso non si può riassegnare. Le assegnazioni funzionano solo con gruppi role-assignable di Entra.
Attenzione alla condivisione: una sessione condivisa è leggibile da chiunque, nello stesso tenant, abbia il ruolo contributor e il link, e l’accesso al plugin che ha prodotto la risposta non viene rivalutato: chi legge vede i risultati anche senza accesso ai dati sottostanti.
Lato owner si governano capacità, condivisione dati con Microsoft, chi può caricare file e il logging in Microsoft Purview.
Plugin: due interruttori in cascata
I plugin si dividono in Microsoft, non Microsoft, siti web e personalizzati, e si accendono dall’icona delle origini. Quelli Microsoft usano on-behalf-of; quelli con l’ingranaggio o il pulsante Set up — Microsoft Sentinel, Azure AI Search — si configurano per utente: restringerli a livello di tenant non elimina quel passaggio.
L’owner cambia la disponibilità dei plugin preinstallati fra “All users” e “Owners only”. Da quel momento anche i nuovi plugin preinstallati nascono riservati agli owner, e l’effetto è immediato sulle esperienze incorporate: restringere il plugin Defender XDR degrada Copilot dentro il portale Defender.
Sui plugin personalizzati gli interruttori sono due e in cascata: il primo decide chi può aggiungerli per sé, il secondo chi può pubblicarli per tutta l’organizzazione — e si sblocca solo se il primo è su “Owners and Contributors”. Un plugin pubblicato da un owner resta modificabile solo dagli owner. Si caricano come file o link .yaml/.json, oppure come plugin OpenAI; validali a livello utente prima di pubblicarli.
Agenti Microsoft e agenti del Security Store
Un agente va configurato prima dell’uso. Si sceglie un’identità — meglio creare un’identità agente che riusare un account utente — e si compilano i parametri, che variano per agente: trigger, permessi, identità, plugin, prodotti richiesti, accesso basato sui ruoli. L’agente gira sul trigger o una tantum, e si mette in pausa. Dettaglio elegante: i plugin richiesti da un agente sono abilitati solo per quell’agente, senza cambiare lo stato dei plugin per l’organizzazione.
Gli agenti costruiti da partner che accedono a dati Microsoft (Intune, Entra, Sentinel, Defender) richiedono il consenso di un Global Administrator prima che la configurazione possa iniziare: il pulsante Set up resta disabilitato e si passa un link all’amministratore. Se l’agente non tocca prodotti Microsoft, quel consenso non serve.
Il Microsoft Security Store è la vetrina, dal menu Home. Gli agenti Microsoft portano direttamente alla pagina degli agenti attivi; quelli non Microsoft passano dallo Store per acquisto o sottoscrizione, e lì servono Contributor o Owner sulla subscription di fatturazione Azure. Due conseguenze che si pagano: rimuovere un agente da Security Copilot non chiude la sottoscrizione, che si gestisce nello Store, e l’uso dell’agente consuma SCU, fatturate separatamente dal canone. Se l’agente dipende da un plugin, quel plugin viene abilitato ma non configurato: la configurazione la fai da Manage sources.