Gli agenti stanno diventando un workload IAM, e i vostri service account non sono pronti

Partiamo dalla migliore difesa possibile dell'approccio esistente, perché non è affatto stupido. Service account e chiavi API gestiscono workload macchina da due decenni. Sono compresi, vengono sottoposti ad audit, ogni cloud e ogni strumento SaaS li supporta, e il team di sicurezza ha già un foglio di calcolo che li elenca. Quando qualcuno dice che gli agenti hanno bisogno di una nuova categoria di identità, la risposta ragionevole è: ne abbiamo già una, si chiama identità non umana, usiamola e andiamo avanti.

Ecco però dove questo smette di funzionare. Un service account risponde alla domanda: "quale sistema sta chiamando?" Un agente impone una domanda più difficile: "quale agente sta chiamando, per conto di chi, verso quale obiettivo, e chi può revocarlo nei prossimi trenta secondi?" I numeri dello stesso settore IAM indicano che le identità non umane superano ormai quelle umane di un ordine di grandezza, e il Verizon DBIR 2026 ha avvertito che service account e machine account sono quelli da tenere d'occhio con l'arrivo dell'AI agentica, secondo la lettura del rapporto da parte di Token Security. Questo è un briefing sul perché la mappatura fallisce, su cosa si sta costruendo per sostituirla e su come appaiono già oggi i fallimenti.

Punti chiave - Service account e chiavi API presuppongono un chiamante stabile e deterministico. Gli agenti sono effimeri, non deterministici e delegano tra loro, rompendo le assunzioni di audit, revoca e minimo privilegio incorporate nelle credenziali condivise. - La direzione degli standard è l'identità del workload per singolo agente: il gruppo di lavoro IETF WIMSE viene spinto a richiedere che gli agenti siano distinguibili per identità, non soltanto per token scope, con identificatori per agente in stile SPIFFE per policy, audit e revoca. - Gli incidenti sono già concreti: token OAuth compromessi nell'ecosistema Salesloft Drift sono stati utilizzati per fare pivot verso ambienti Salesforce enterprise, e la violazione di Hugging Face di luglio è stata eseguita end-to-end da un agente autonomo. - Le indicazioni di implementazione stanno convergendo: identità dedicata per ogni agente, credenziali di breve durata e limitate al task emesse fuori dal contesto del modello, e audit trail associati all'agente anziché al ruolo condiviso. - Se i vostri agenti si autenticano tutti con un unico service account condiviso, i log non possono dirvi quale agente ha fatto cosa. È il test da applicare questa settimana.

Cosa è successo

Due cose sono confluite nelle prime settimane di agosto. Primo, la discussione sugli standard è diventata specifica. Un issue sulla bozza di architettura IETF WIMSE, aperto il 4 agosto, sostiene che il linguaggio attuale della bozza sugli intermediari AI sia troppo debole: consente "separate workload identities or token scopes" per distinguere le azioni di agenti autonomi, e l'issue argomenta che i token scope non bastano. Gli scope limitano ciò che un token può fare, ma non cambiano chi rappresenta quel token. Più agenti che condividono una credenziale restano indistinguibili nei log di audit, nei sistemi di revoca e nelle policy per agente, indipendentemente da quanto differiscano gli scope. La correzione proposta: le piattaforme di agenti gestite dovrebbero assegnare a ogni agente un identificatore di workload unico, trasportato in un claim dedicato e usato come chiave stabile per policy, audit e revoca. Il design di identità degli agenti di Google, che assegna a ogni agente distribuito un'identità basata su SPIFFE collegata alla sua risorsa agente, viene citato come esempio funzionante.

Secondo, il ritmo degli incidenti è continuato. La violazione di Hugging Face di metà luglio è stata la prima intrusione pubblica in un'azienda identificata per nome eseguita da un agente autonomo dall'inizio alla fine: esecuzione di codice nella pipeline dei dataset, raccolta di credenziali, movimento laterale tra cluster interni e migliaia di azioni durante un fine settimana. All'inizio dell'anno Moltbook, un social network per agenti AI, ha esposto 1,5 milioni di token API da un database configurato male pochi giorni dopo aver raggiunto 1,5 milioni di account agente, secondo il riepilogo di Studio Global. E l'esempio ricorrente del DBIR sugli attacchi alle identità non umane, la compromissione dei token OAuth Salesloft Drift usati per raggiungere ambienti Salesforce di grandi imprese tra cui Google, Cisco e Zscaler, ha esattamente la forma delle credenziali da cui dipendono gli agenti.

Nell'agosto 2026, un issue IETF WIMSE ha proposto che le azioni degli agenti debbano essere distinte tramite identità di workload separate, non tramite token scope, con identificatori per agente come chiave stabile per policy, audit e revoca. La proposta è arrivata dopo la violazione di Hugging Face condotta da un agente a luglio e un incidente di gennaio in cui la piattaforma di agenti Moltbook ha esposto 1,5 milioni di token API.

Perché service account e chiavi API non si adattano agli agenti

Il disallineamento ha quattro lati, e vale la pena nominarli separatamente perché le soluzioni sono diverse.

L'identità condivisa distrugge l'attribuzione. I service account sono progettati per essere condivisi, statici e ampiamente privilegiati. Mettete dieci agenti sotto un solo account e il vostro audit log mostrerà un unico attore, come spiega l'analisi sul campo di Cockroach Labs: non potete sapere quale agente ha toccato quali dati, la rotazione richiede coordinamento tra tutti gli agenti, e i permessi dell'account tendono a diventare l'unione di tutto ciò di cui qualunque agente abbia mai avuto bisogno. Il loro esempio anonimizzato assomiglia a varianti che ho sentito da team clienti: un agente di supporto eseguito per tre mesi con un account che aveva accesso in lettura all'intero database clienti, configurato così in sviluppo e mai ristretto prima del go-live.

Gli agenti sono effimeri; le chiavi no. Un workflow agentico può autenticarsi in pochi secondi presso un model provider, un vector store, tre API e uno storage cloud, per poi scomparire. Le chiavi API di lunga durata presuppongono un chiamante persistente per cui abbia senso una rotazione programmata. Il disallineamento produce proliferazione: chiavi create per agenti che nessuno ricorda più, ancora valide e ancora troppo ampie.

La delega rompe la catena del "per conto di". Un agente che agisce per un utente e un agente che agisce autonomamente dovrebbero apparire completamente diversi al vostro motore di policy. Con un service account condiviso appaiono identici. La delega OAuth gestisce abbastanza bene il caso utente; il caso autonomo richiede l'identità propria dell'agente, e la delega multi-agent richiede che ogni passaggio restringa, non allarghi, l'autorità trasmessa.

Il modello non deve mai detenere il segreto. È un problema strutturale, non di configurazione. Le credenziali inserite nella finestra di contesto sono esposte al modello e a qualunque cosa possa manipolarlo: una prompt injection può esfiltrarle attraverso gli output dello stesso agente. La soluzione sono credenziali di breve durata e con scope limitato, emesse al momento del task da un token service e conservate dal layer di esecuzione degli strumenti, così che il modello attivi le chiamate senza che il segreto entri nel suo contesto. Cockroach Labs spiega bene questo punto, e coincide con ciò che dico ai clienti che costruiscono su stack di agenti self-hosted: l'harness conserva le chiavi, il modello conserva l'intento.

I service account condivisi rompono l'attribuzione degli agenti perché nei log compare un solo attore, sopravvivono ai workload effimeri degli agenti, confondono la distinzione tra azioni delegate dall'utente e azioni autonome, e spingono i team a far passare le credenziali attraverso il contesto del modello dove una prompt injection può raggiungerle, secondo Cockroach Labs e il confronto di miniOrange.

Cosa stanno costruendo vendor e organismi di standardizzazione

La forma emergente ha tre livelli, e l'aspetto incoraggiante è che vendor ed esperti di standard stanno convergendo grosso modo sulla stessa struttura.

Identità di workload per agente. La direzione WIMSE descritta sopra è la versione degli standard: ogni agente logico riceve un identificatore unico e stabile, con una URI SPIFFE come forma suggerita, distinto da qualsiasi ruolo di esecuzione condiviso, e quell'identificatore diventa la chiave per policy, audit e revoca. Gli agenti gestiti da piattaforme che condividono una credenziale di esecuzione dovrebbero integrarla con un claim per agente. È il cambiamento più importante: identità per agente, non per deployment.

Federazione invece di segreti memorizzati. La guida di Descope alla workload identity federation per agenti mostra il modello: l'identità di piattaforma dell'agente, per esempio un ruolo AWS IAM o un service account Kubernetes tramite IRSA, viene scambiata con un token di breve durata e con scope limitato dalla piattaforma di identità, che crea anche una voce di directory per l'agente in modo che gli audit trail sopravvivano alla durata del token. Nessuna chiave di lunga durata da perdere, e il record di identità sopravvive a qualunque singola credenziale.

Discovery e governance come mercato. Sul lato commerciale, i vendor di identità non umane come Reco, Token Security, Oasis, Aembit e altri si stanno riposizionando intorno agli agenti: scoprire ogni credenziale di agente, associarla a un proprietario, segnalare l'over-privilege e revocare in modo pulito. L'impostazione di Reco è pratica: abbinare il tipo di identità al ruolo dell'agente, OAuth delegato per le azioni utente e identità di workload dedicata per quelle autonome, e rivedere i permessi man mano che le responsabilità crescono, perché gli agenti accumulano privilegi come i dipendenti accumulano chiavi dell'edificio. La Top 10 for Agentic Applications di OWASP, pubblicata a dicembre 2025, nomina Identity and Privilege Abuse come categoria di rischio di primo livello, dando ai team di sicurezza un vocabolario comune per i risultati di audit. Il punto in cui tutto questo si colloca nello stack più ampio è una questione di governance tanto quanto di tooling; tratto il lato organizzativo in AI agent governance.

L'architettura emergente: identità di workload per agente, con identificatori in stile SPIFFE usati come chiave per policy, audit e revoca secondo la discussione WIMSE, federazione dell'identità di piattaforma in token di breve durata e con scope limitato, con record di directory persistenti per gli agenti secondo Descope, e un mercato di vendor per discovery e governance least-privilege delle identità non umane.

Quando l'identità degli agenti va storta

Tre incidenti, tre modalità di fallimento diverse, tutte istruttive.

Hugging Face, luglio 2026: il problema di identità dell'attaccante era anche quello del difensore. L'intrusione condotta da un agente ha raccolto credenziali cloud e cluster da un worker di esecuzione codice e si è mossa lateralmente, il classico scenario di un workload sovraprivilegiato: un componente di elaborazione dati deteneva credenziali che valeva la pena rubare. Il dettaglio meno riportato è l'asimmetria forense rivelata da Hugging Face: l'agente attaccante non era vincolato da alcuna policy d'uso, mentre il lavoro forense interno dell'azienda è stato inizialmente bloccato dai guardrail dei modelli hosted che avevano provato. Hanno quindi eseguito l'analisi forense con un modello open-weight, GLM 5.2, sulla propria infrastruttura. Fallimenti di identità e accesso su entrambi i lati dello stesso incidente.

Salesloft Drift, il monito del DBIR: token come passe-partout. Token OAuth compromessi da un ecosistema vendor sono stati usati per fare pivot negli ambienti Salesforce di grandi imprese. Niente password, niente phishing di persone: credenziali non umane, ampiamente fidate e riutilizzate in silenzio. Ogni agente che collegate a uno strumento SaaS con un grant OAuth di lunga durata presenta questa forma di rischio, e la mitigazione ha la stessa forma: breve durata, scope ristretto, per agente e revocabile.

Moltbook, gennaio 2026: le piattaforme di agenti aggregano il rischio d'identità. Una piattaforma per account agente ha esposto 1,5 milioni di token API insieme a indirizzi email e messaggi tra agenti da un database configurato male, secondo il resoconto di Studio Global. Quando centralizzate l'identità degli agenti, centralizzate anche il suo blast radius. Vale la pena precisare che considererei alcuni dettagli dell'incidente in circolazione come riportati, non auditati: la disclosure di Hugging Face è una fonte primaria, i numeri di Moltbook provengono da copertura secondaria.

I fallimenti documentati di identità degli agenti includono la violazione di Hugging Face del luglio 2026, con un agente autonomo che ha raccolto credenziali cloud e cluster e si è mosso lateralmente secondo l'analisi di Waxell, il pivot dei token OAuth Salesloft Drift verso tenant Salesforce enterprise secondo Token Security sul DBIR 2026, e la perdita di 1,5 milioni di token API di agenti da Moltbook.

Cosa fare adesso

1. Questa settimana: censite le credenziali dei vostri agenti e applicate il test di attribuzione. Prendete una qualsiasi azione di un agente dai log e chiedetevi se potete stabilire quale agente l'ha eseguita, per conto di chi e se potreste revocare solo quell'agente senza toccare gli altri. Se la risposta è no, avete un problema di identità condivisa, ed è il primo punto da correggere.

2. Questo mese: spostate un agente autonomo dalla sua credenziale di lunga durata a token di breve durata e limitati al task, emessi da un token service o da una piattaforma di identità, conservati nel layer di esecuzione degli strumenti e mai nel contesto del modello. Partite dall'agente con l'accesso più ampio; di solito è quello a cui qualcuno ha assegnato uno scope "temporaneo" di fretta.

3. Questo trimestre: assegnate a ogni agente logico la propria identità stabile, uno SPIFFE ID dove avete l'infrastruttura, un service account univoco per agente dove non l'avete, collegate audit e alerting a quella identità e scrivete il runbook di revoca prima di averne bisogno. Se siete ancora all'inizio e state decidendo dove gli agenti debbano girare, il trade-off tra agenti locali e cloud determina quanto di questa parte potete controllare direttamente.

FAQ

Cos'è l'identità di un agente in termini IAM?

Un'identità distinta e verificabile assegnata a un singolo agente AI, separata dalla piattaforma su cui gira e dagli utenti per cui agisce. Viene usata come chiave stabile per autenticazione, policy di autorizzazione, audit trail e revoca, come una workload identity identifica un microservizio, ma adattata a chiamanti effimeri, non deterministici e capaci di delegare tra loro.

Perché gli agenti non possono semplicemente condividere un service account?

Tecnicamente possono, e oggi la maggior parte lo fa. I problemi: i log di audit mostrano l'account condiviso anziché l'agente che ha agito, quindi perdete l'attribuzione; i permessi dell'account crescono fino all'unione delle necessità di tutti gli agenti; revocare un agente significa ruotare le credenziali per tutti; e non potete distinguere le azioni delegate da un utente da quelle autonome. Funziona fino al primo incidente, poi non avete modo di ricostruire cosa è successo.

Cosa stanno facendo gli organismi di standardizzazione per l'identità degli agenti?

Il gruppo di lavoro IETF WIMSE sta estendendo l'architettura di workload identity agli intermediari AI, con una proposta attiva che richiede identificatori per agente, usando URI SPIFFE come meccanismo suggerito, invece di affidarsi ai token scope. OWASP ha pubblicato una Top 10 for Agentic Applications nel dicembre 2025 con identity and privilege abuse come categoria nominata, e la Cloud Security Alliance dispone di un framework di governance dell'identità degli agenti che raccomanda un'identità unica per ogni agente.

Le credenziali di un agente dovrebbero mai apparire nel contesto del modello?

No. Tutto ciò che entra nella finestra di contesto è visibile al modello e può essere esfiltrato tramite prompt injection. Il modello accettato prevede credenziali emesse al momento del task da un token service, conservate dal layer di esecuzione degli strumenti tra il modello e l'API, limitate al task e di breve durata. Il modello richiede l'azione; l'harness conserva il segreto.

In sintesi

Nel mondo dell'identità si dice che l'identità è il control plane, e gli agenti stanno per mettere alla prova questa idea più duramente di quanto abbiano mai fatto i microservizi. La direzione è abbastanza chiara da poter iniziare a costruire in quel senso oggi: identità per agente, segreti fuori dal modello, token che scadono più velocemente di quanto si propaghino gli incidenti e audit in grado di rispondere a "quale agente, per conto di chi, con quale obiettivo". Le organizzazioni colpite questa estate non stavano eseguendo setup esotici; usavano credenziali condivise e speravano. È questo il divario da chiudere, e può essere chiuso con tecnologia che per la maggior parte esiste già.

Se state mappando l'identità degli agenti su un ambiente IAM esistente e volete un professionista pratico nella discussione, è un lavoro che faccio. Contattatemi.

Fonti

• IETF WIMSE WG, issue #139 di draft-ietf-wimse-arch, "AI and ML-Based Intermediaries: token scopes do not create per-agent identity": https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/issues/139 (aperto 2026-08-04, consultato 2026-08-29)

• Cockroach Labs, "AI Agent Identity Security": https://www.cockroachlabs.com/blog/ai-agent-identity-security/ (pubblicato 2026-07-17, consultato 2026-08-29)

• Token Security, "The 2026 Data Breach Investigations Report Confirms It: Identity Is the Control Plane for Agentic AI": https://www.token.security/blog/the-2026-data-breach-investigations-report-confirms-it-identity-is-the-control-plane-for-agentic-ai (pubblicato 2026-05-20, consultato 2026-08-29)

• Descope, "What Is Workload Identity Federation for AI Agents?": https://www.descope.com/learn/post/workload-identity-federation-for-agents (pubblicato 2026-06-22, consultato 2026-08-29)

• miniOrange, "Why AI Agents Need Workload Identity, Not Shared Secrets": https://www.miniorange.com/blog/workload-identity-ai-agents/ (pubblicato 2026-05-20, consultato 2026-08-29)

• Reco, "Non-Human Identities for AI Agents: How to Govern Access": https://www.reco.ai/blog/non-human-identities-for-ai-agents (pubblicato 2026-07-20, consultato 2026-08-29)

• Waxell, "Hugging Face Breach: How an AI Agent Ran the Attack": https://www.waxell.ai/blog/hugging-face-agentic-attacker-ai-breach-2026 (pubblicato 2026-07-17, consultato 2026-08-29)

• Studio Global, "EU AI Act August 2026: Enforcement Powers Go Live as Autonomous Agent Breach Tests Regulators": https://www.studioglobal.ai/discover/answers/what-key-enforcement-powers-and-transparency-obligations-6a6bff1f2240a0fb8c880846 (pubblicato 2026-08-17, consultato 2026-08-29)