{"id":3290,"date":"2026-08-15T11:40:17","date_gmt":"2026-08-15T09:40:17","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/identity-management-agentic-ai-2026-authorization-service-accounts-zero-trust\/"},"modified":"2026-08-15T11:40:17","modified_gmt":"2026-08-15T09:40:17","slug":"identity-management-agentic-ai-2026-authorization-service-accounts-zero-trust","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/identity-management-agentic-ai-2026-authorization-service-accounts-zero-trust\/","title":{"rendered":"Identity Management per Agentic AI 2026: La Mia Guida Authorization Crisis Risoluzione, Service Account Policies e AI Agent Permission Scoping in Zero Trust"},"content":{"rendered":"

Negli ultimi mesi, ho visto sul campo un fenomeno che inizialmente non capivo completamente: agenti AI che operano con autorizzazioni troppo ampie, senza una vera identit\u00e0 distinta, creando un buco di sicurezza invisibile nelle infrastrutture enterprise<\/strong>. Quando inizia il 2026, questa non \u00e8 pi\u00f9 una preoccupazione teorica. L’identity crisis per gli AI agent<\/strong> \u00e8 reale, diffusa, e la maggior parte delle organizzazioni ancora non ha capito quanto sia critica.<\/p>\n

Parlando con i colleghi CISO e security engineer, emerge un pattern ricorrente: gli agenti AI vengono deployati rapidamente per automatizzare flussi di lavoro, ma nessuno ha chiarito quale sia veramente la loro identit\u00e0, quali permessi dovrebbero avere, e come tracciare cosa fanno. Spesso ereditano credenziali di servizio umani, o peggio ancora, condividono account. Il risultato? Autorizzazioni a mosaico, audit trail confusi, e una superficie d’attacco che cresce ogni giorno<\/strong>.<\/p>\n

In questo articolo vi mostro come ho risolto concretamente questi problemi nelle ultime implementazioni, partendo dai fondamenti dell’identity management per agenti autonomi fino a un’architettura Zero Trust robusta, con service account policies chiare e permission scoping granulare. Questo non \u00e8 solo compliance: \u00e8 sopravvivenza operativa.<\/p>\n

Perch\u00e9 l’Identity Management per Agenti AI \u00e8 Diverso (e Pi\u00f9 Difficile)<\/h2>\n

Durante una recente implementazione, mi sono ritrovato a discutere con lo sviluppatore di un agente: “Ma perch\u00e9 non posso dare al bot i miei stessi permessi? \u00c8 pi\u00f9 veloce”<\/em>. Comprensibile dal punto di vista della delivery, ma \u00e8 esattamente il problema che dobbiamo risolvere.<\/p>\n

Un agente AI nel 2026 ha identit\u00e0, credenziali e scope \u2013 ma lo scope cambia per ogni invocazione<\/cite>. A differenza di un account di servizio tradizionale (che ha un’identit\u00e0 fissa, credenziali rotanti, e un ambito di permessi statico), lo stesso agente di coding potrebbe agire per conto di Alice per un refactoring task un momento, poi per Bob per un deployment task secondi dopo, ciascuno con requisiti di accesso completamente diversi<\/cite>.<\/p>\n

L’intero macchinario dell’IAM, dai workflow di provisioning alle certificazioni di accesso, \u00e8 stato progettato sul presupposto che le identit\u00e0 appartengano a persone. Questo presupposto \u00e8 ora obsoleto<\/cite>.<\/p>\n

Le Tre Crisi dell’Identity per Agenti AI<\/h2>\n

Crisis 1: Autorizzazioni Ereditate (Il Problema del Borrowing)<\/h3>\n

Quando gli agenti AI operano sotto identit\u00e0 umane o account di servizio condivisi, possono ereditare i permessi associati. E questo indipendentemente dal fatto che questi permessi si allineino con il ruolo previsto dell’agente AI<\/cite>.<\/p>\n

Ho visto questo accadere concretamente: un agente di automazione RPA ereditava tutti i permessi del service account del team operations, che includeva write su database critici, accesso a buste paga, e lettura di dati di bilancio. L’agente aveva bisogno solo di leggere logs e triggerare notifiche Slack<\/strong>. Ma nessuno aveva pensato di creare un’identit\u00e0 dedicata con permessi minimi.<\/p>\n

Un agente dovrebbe poter fare solo quello che l’agente \u00e8 autorizzato a fare AND quello che l’utente delegante \u00e8 autorizzato a fare \u2013 non l’unione di entrambi<\/cite>. Questo si chiama permission intersection pattern<\/strong>, e non \u00e8 standard oggi.<\/p>\n

Crisis 2: Audit Trail Opaco (“Chi ha fatto cosa?”)<\/h3>\n

Loggare che un agente “ha eseguito” non \u00e8 un audit trail. Avete bisogno di: quale agente, quale utente ha delegato, quale tool \u00e8 stato chiamato, con quali argomenti, quali dati sono stati accessati, e qual \u00e8 stato il risultato<\/cite>.<\/p>\n

Il 68% delle organizzazioni non riesce a distinguere chiaramente tra azioni eseguite da agenti AI rispetto a umani<\/cite>. Quando una transazione anomala scatta i vostri sistemi di alert, dovete rispondere in minuti: era un’azione legittima dell’agente A? Oppure era l’agente B che ha escalato via token rubato? Se non avete una traccia completa e separata per ogni identit\u00e0, siete ciechi.<\/p>\n

Crisis 3: Identit\u00e0 Frammentate e Scope Scope Creep<\/h3>\n

Con l’aumentare dell’adozione dell’IA, cresce anche il sprawl di identit\u00e0. Gli agenti AI creano nuovi percorsi di accesso, spesso interagendo con i sistemi in modi non deterministici. A differenza delle NHI tradizionali, che hanno compiti e capacit\u00e0 fisse, gli agenti AI possono richiedere privilegi aggiuntivi, accedere a nuovi sistemi, e intraprendere azioni non esplicitamente predefinite<\/cite>.<\/p>\n

Ho tracciato questo problema in una banca dove avevano deployato 6 agenti in parallelo. Dopo 3 mesi, nessuno sapeva quali API ogni agente stesse effettivamente usando. I permessi si erano accumulati per motivi che nessuno ricordava pi\u00f9. Policy drift totale<\/strong>.<\/p>\n

Fondamenti: Service Account Policies per Agenti AI<\/h2>\n

Principio 1: Identit\u00e0 Distinta, Non Impersonazione<\/h3>\n

L’impersonazione di agenti nei sistemi AI crea rischi di sicurezza concedendo autorizzazioni eccessivamente ampie. Questo post introduce un modello di delega utilizzando un pattern “permission intersection”, assicurando che gli agenti operino secondo il principio del privilegio minimo con una traccia completamente controllabile<\/cite>.<\/p>\n

La differenza \u00e8 fondamentale:<\/p>\n

    \n
  • Impersonazione (Sbagliato):<\/strong> Agent assume la vostra identit\u00e0 completa, eredita tutti i vostri permessi, opera come se fosse voi. Se l’agente viene compromesso, l’attaccante ha accesso a tutto quello che permette il vostro token.<\/li>\n
  • Delega (Giusto):<\/strong> L’agente riceve un set limitato di privilegi \u2013 un grant esplicito che limita quello che pu\u00f2 fare. L’identit\u00e0 dell’agente rimane separata dalla vostra, ogni hop nella catena \u00e8 tracciabile, e i permessi seguono il principio del least privilege per design.<\/li>\n<\/ul>\n

    Nella pratica, ho implementato questo creando JWT scoped per ogni agente. Ecco un esempio:<\/p>\n

    Token AI Agent (Corretto):<\/strong>\n{\n  \"sub\": \"agent-email-processor-v2\",\n  \"aud\": [\"gmail-read-only\", \"slack-webhook\"],\n  \"scope\": \"read:email write:slack_notification\",\n  \"delegated_by\": \"user@company.com\",\n  \"permitted_labels\": [\"support-inbox\"],\n  \"expires_in\": 3600,\n  \"delegation_context\": {\n    \"task_id\": \"task-2026-08-15-001\",\n    \"max_operations\": 1000,\n    \"data_classification_max\": \"internal\"\n  }\n}<\/pre>\n
    Notice: questo token ha scope limitato<\/strong> (read:email, write:slack), risorse target** (support-inbox), **expiry a breve termine<\/strong> (1 ora), e context di delega completo<\/strong>. Non \u00e8 un copy\/paste del vostro token personale.<\/p>\n
    Principio 2: Scope Binding Dinamico per Task<\/h3>\n
    Sharma et al. propongono PAuth, che sfida il modello di autorizzazione scoped da operator di OAuth. PAuth introduce “NL slices” \u2013 specifiche simboliche delle tool call attese per servizio derivate da descrizioni di task in linguaggio naturale \u2013 e “envelopes” che legano i valori degli operandi alla provenienza simbolica<\/cite>.<\/p>\n
    In altri termini: Scope gli strumenti ai task, non agli agenti. Diversi task ricevono diversi set di tool. Un sub-agent delegato per analisi dati di sola lettura non dovrebbe ereditare i permessi di scrittura dell’agente genitore<\/cite>.<\/p>\n
    Ho implementato questo con MCP (Model Context Protocol) + OAuth 2.1. Quando l’agente riceve un task, genero dinamicamente un token con solo i tool necessari:<\/p>\n
    Esempio MCP con Authorization Envelope:<\/strong>\n\nTask: \"Summarize Q3 revenue report from Salesforce\"\nGenerated Scope:\n- Tool: salesforce\/read-report (report_id: Q3-revenue-2026)\n- Tool: gpt4-write-draft-email\n- Denied: salesforce\/write, delete, admin\n- Duration: 30 minutes\n- Data Classification Max: \"confidential-finance\"\n\nTask: \"Send meeting summary to team Slack\"\nGenerated Scope:\n- Tool: slack\/post-message (channel: #team-updates)\n- Denied: slack\/delete, edit-others, admin\n- Duration: 5 minutes<\/pre>\n
    Questo pattern garantisce che se l’agente viene compromesso durante il task Q3-revenue, l’attaccante non pu\u00f2 accedere ai tool Slack o a report di altri quarters.<\/p>\n
    Principio 3: Zero Trust Authorization at Every Tool Call<\/h3>\n
    L’agente gateway \u00e8 il punto di enforcement della policy tra l’agente e ogni tool o API che chiama. Ogni invocazione di tool \u00e8 una decisione di autorizzazione separata, non un grant di fiducia generale. Il gateway convalida: questo agente \u00e8 autorizzato a chiamare questo tool? \u00c8 questa chiamata dentro l’envelope operativo dichiarato dell’agente<\/cite>?<\/p>\n
    Ho deployato un agent gateway che ispeziona ogni tool call prima che raggiunga l’API target. Ecco il flusso:<\/p>\n
      \n
    1. Agent esegue:<\/strong> “Leggi email da support-inbox”<\/li>\n
    2. Gateway riceve la richiesta<\/strong><\/li>\n
    3. Gateway verifica:<\/strong>\n