Chi ha creato questi agent?

In un tenant cliente con 3.000 utenti abbiamo trovato 280 agent al primo inventario. 170 di questi non avevano più alcun responsabile ancora in azienda. A crearli non era stato nessun malintenzionato, ma reparti aziendali che volevano risolvere qualcosa in fretta. Esattamente come sono nati dieci anni fa i Service Principals che ancora oggi nessuno ha rimosso. Gli agent ripetono questo schema, solo più velocemente e in numero maggiore.

Cosa non può fare una licenza

E7 unisce E5, Copilot, la Entra Suite e Agent 365. Il contenuto del pacchetto è ormai ampiamente documentato. Ma una licenza non riordina un tenant. Mette a disposizione gli strumenti per vedere, identificare e controllare gli agent. Non decide se un agent debba esistere, chi ne risponde e a cosa può accedere.

A questo si aggiunge la velocità. Gli agent nascono oggi dove un tempo nascevano le macro di Excel: nei reparti, in fretta e senza ticket. Va benissimo così. Significa però che il numero di account non umani nella directory cresce più in fretta di qualsiasi altro gruppo.

Cosa mostra il registro e cosa no

Agent 365 raccoglie in un unico posto gli agent di Microsoft 365, Copilot Studio, Power Platform e Foundry. Defender for Endpoint individua inoltre gli agent AI installati localmente sui client, inclusi i server MCP configurati. Entrambe le fonti confluiscono in Advanced Hunting e possono essere analizzate insieme tramite KQL. Shadow AI nel senso più letterale del termine.

Con questa query verifichiamo quali agent vengono effettivamente richiamati e quali strumenti utilizzano:

CloudAppEvents
| where ActionType in ("InvokeAgent", "InferenceCall", "ExecuteToolBySDK", "ExecuteToolByGateway")
| extend RawEventData_parsed = parse_json(RawEventData)
| extend
    Workload          = coalesce(tostring(RawEventData_parsed["Workload"]), "Unknown"),
    TargetAgentName   = coalesce(tostring(RawEventData_parsed["TargetAgentName"]), "Unknown"),
    AgentName         = coalesce(tostring(RawEventData_parsed["AgentName"]), "Unknown"),
    AgentBlueprintId  = coalesce(tostring(RawEventData_parsed["AgentBlueprintId"]), "Unknown"),
    PlatformAgentType = coalesce(
        tostring(RawEventData_parsed["PlatformAgentType"]),
        tostring(RawEventData_parsed["CopilotEventData"]["PlatformAgentType"]),
        "Unknown"
    )
| project-away RawEventData_parsed
| summarize count() by ActionType, Workload, TargetAgentName, PlatformAgentType, AgentName, AgentBlueprintId

Vale una precisazione: la query mostra solo una parte del quadro, principalmente gli agent Microsoft e quelli costruiti su piattaforme Microsoft. Ciò che opera al di fuori di questo perimetro non è visibile qui.

Per gli agent locali sui client è sufficiente Defender for Endpoint Plan 2:

AgentsInfo
| where Platform == "LocalAgents"
| summarize arg_max(Timestamp, Name, Version, LifecycleStatus, RawAgentInfo) by AgentId
| where LifecycleStatus !in~ ("Deleted", "Uninstalled")
| extend AgentMetadata = RawAgentInfo.localAgentMetadata
| extend Vendor = tostring(AgentMetadata.vendor),
         Device = tostring(AgentMetadata.deviceName)
| summarize DeviceCount = dcount(Device) by Agent = Name, Vendor
| sort by DeviceCount desc

Un agent che agisce per conto di un utente eredita i permessi di quell'utente. Se l'utente ha accesso a una libreria SharePoint condivisa in modo troppo ampio, lo ha anche l'agent, con la differenza che è più veloce e più sistematico di qualsiasi persona.

Un agent autonomo con identità propria opera con permessi propri. Ha bisogno di un responsabile, un profilo di autorizzazione pulito e una data di scadenza, esattamente come qualsiasi altro account che accede ai dati aziendali.

Il registro mostra cosa c'è. Se debba esserci lo deve valutare qualcuno, e questa valutazione non si conclude mai.

Gli agent hanno bisogno di identità, non di eccezioni

Gli agent costruiti con Entra Agent ID ottengono un'identità gestita propria. Tramite Agent Blueprints si può stabilire come è costruito un agent e quali permessi ottiene, ancora prima che esista. Con Entra ID Governance, le verifiche di accesso e il ciclo di vita valgono anche per gli agent: creazione, approvazione, assegnazione dei responsabili, verifica periodica, scadenza.

Il Conditional Access può essere applicato alle identità degli agent e ai Blueprints, ma non in modo diretto come per le persone. Le policy per "tutti gli utenti" non coprono gli account agent, e chi accede tramite API key bypassa Entra del tutto. Queste lacune vanno conosciute prima di fare affidamento sulla policy.

Sembra ovvio. In pratica, purtroppo, non lo è. In molti tenant vediamo già oggi quanto sia difficile gestire le classiche registrazioni di app e i Service Principals. Secret abbandonati, permessi rimasti da qualche fase di test, responsabili che lavorano altrove da tempo. Gli agent non migliorano la situazione, perché vengono creati in numero maggiore e da molte più persone.

Chi oggi non ha il controllo dei propri Service Principals non ce l'avrà neanche sugli agent domani.

La governance è un compito continuativo

Ogni settimana si aggiungono nuovi agent. I responsabili cambiano ruolo o azienda. I permessi crescono, le regole di Conditional Access accumulano eccezioni, i Sensitivity Labels non li aggiorna nessuno. Niente di tutto questo è un progetto con un go-live: è esercizio operativo.

Ed è esattamente così che lo affrontiamo. Con Managed Entra gestiamo Entra ID per i nostri clienti interamente come codice. Sembra un dettaglio tecnico, ma è la ragione concreta per cui l'esercizio funziona in modo affidabile.

Molte aziende hanno un processo di change ordinato secondo ITIL. Nel ticket c'è scritto cosa deve essere modificato, poi si fa clic nel portale. Ma chi verifica che sia stato modificato esattamente quello, e nient'altro?

Da noi non si controlla la descrizione, ma la modifica stessa. Le regole esistono come codice. Prima dell'intervento è scritto nero su bianco cosa cambia. Una seconda persona approva esattamente quello, e solo quello viene distribuito, con nome e data. Se qualcosa va storto comunque, l'ultimo stato funzionante è ripristinato in minuti, non nel corso di un turno notturno.

Anche le eccezioni seguono questo percorso. Se un cliente ha bisogno di uno scostamento dallo standard, si trova nel repository, non in un foglio Excel o nella testa di un admin. È visibile, versionata e verificata come qualsiasi altra modifica. Così la baseline non si erode silenziosamente nel corso dei mesi, e al prossimo audit la documentazione su come è configurato il tenant, chi ha cambiato cosa e quando, è già pronta.

E ci atteniamo noi stessi a ciò che chiediamo per gli agent. Anche la nostra automazione è un'identità non umana. Si autentica al tenant del cliente tramite identità federate, senza alcun secret memorizzato. I permessi sono separati: un'identità può solo leggere e pianificare, un'altra può scrivere. Nessuna password che può trapelare, nessun certificato che scade silenziosamente.

Per gli agent stessi siamo nel mezzo del lavoro. Conditional Access, Access Reviews e Entitlement Management girano già oggi come codice. Quello su cui stiamo lavorando sono template di agent nel repository, con identità, permessi, Conditional Access, responsabili e data di scadenza, oltre a controlli automatici per le identità agent abbandonate, ad esempio tramite Maester checks della community. Con centinaia di agent, questa è la differenza tra avere il controllo e sperare che vada bene.

Come Purview protegge i dati che gli agent leggono e trasmettono, e come il nostro CSOC monitora la loro attività, lo descriviamo in un articolo dedicato alla AI governance.

E gli agent in Azure?

Agent 365 vede anche gli agent in esecuzione su Microsoft Foundry. Ma qualcuno deve costruire e gestire la piattaforma sottostante: modelli, rete, connessione ai dati, valutazione. Per questo abbiamo sviluppato la AI Foundation, interamente come codice, in modo che ogni nuovo progetto AI parta con le stesse linee guida del precedente. Ne parliamo in dettaglio nell'articolo sulle tre foundation: The Holy Trinity.

Il punto più importante è la connessione verso il basso. Ogni agent della AI Foundation ottiene un'identità propria nello stesso Entra del resto dell'ambiente, con esattamente i permessi di cui ha bisogno. Se agisce per conto di un utente, vede solo ciò che quell'utente può vedere, e lascia una traccia verificabile. Nessuna corsia preferenziale con account propri ed eccezioni proprie solo perché l'agent gira in Azure invece che in Microsoft 365.

Tre domande per domani mattina

Chi vuole capire dove si trova può partire da tre domande:

1. Quali agent non hanno più un owner o uno sponsor attivo?
2. Quali Service Principals hanno secret più vecchi di dodici mesi?
3. Quali agent accedono tramite API key invece che tramite Entra?

Chi riesce a rispondere rapidamente a tutte e tre è avanti rispetto alla maggior parte.

Da dove partiamo

Dallo stato attuale, perché gli agent sono già lì. Nel nostro Agent 365 Workshop di due giorni rendiamo visibile quali agent girano nel tuo tenant e da dove provengono. Al termine avrai un inventario, un quadro dei rischi e un piano di governance con responsabilità chiare.

Conclusione

E7 affronta un problema reale. Vedere cosa gira non significa però averlo sotto controllo. Per farlo, qualcuno deve guardare ogni giorno, gestire le identità, ridurre i permessi e accorgersi quando un agent si comporta improvvisamente in modo diverso rispetto al giorno prima.

La licenza è il punto di partenza. L'esercizio operativo decide il resto.

Hai già E7 in uso o ti accorgi che gli agent si moltiplicano nel tuo ambiente e non sai chi li tiene d'occhio? Contattaci. Analizziamo insieme cosa gira da te e cosa può restare. L'avvio è supportato da Microsoft tramite programmi di finanziamento: se fa al caso tuo, lo valutiamo insieme.