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à distinta, creando un buco di sicurezza invisibile nelle infrastrutture enterprise. Quando inizia il 2026, questa non è più una preoccupazione teorica. L’identity crisis per gli AI agent è reale, diffusa, e la maggior parte delle organizzazioni ancora non ha capito quanto sia critica.
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à, 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.
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 è solo compliance: è sopravvivenza operativa.
Perché l’Identity Management per Agenti AI è Diverso (e Più Difficile)
Durante una recente implementazione, mi sono ritrovato a discutere con lo sviluppatore di un agente: “Ma perché non posso dare al bot i miei stessi permessi? È più veloce”. Comprensibile dal punto di vista della delivery, ma è esattamente il problema che dobbiamo risolvere.
Un agente AI nel 2026 ha identità, credenziali e scope – ma lo scope cambia per ogni invocazione. A differenza di un account di servizio tradizionale (che ha un’identità 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.
L’intero macchinario dell’IAM, dai workflow di provisioning alle certificazioni di accesso, è stato progettato sul presupposto che le identità appartengano a persone. Questo presupposto è ora obsoleto.
Le Tre Crisi dell’Identity per Agenti AI
Crisis 1: Autorizzazioni Ereditate (Il Problema del Borrowing)
Quando gli agenti AI operano sotto identità 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.
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. Ma nessuno aveva pensato di creare un’identità dedicata con permessi minimi.
Un agente dovrebbe poter fare solo quello che l’agente è autorizzato a fare AND quello che l’utente delegante è autorizzato a fare – non l’unione di entrambi. Questo si chiama permission intersection pattern, e non è standard oggi.
Crisis 2: Audit Trail Opaco (“Chi ha fatto cosa?”)
Loggare che un agente “ha eseguito” non è un audit trail. Avete bisogno di: quale agente, quale utente ha delegato, quale tool è stato chiamato, con quali argomenti, quali dati sono stati accessati, e qual è stato il risultato.
Il 68% delle organizzazioni non riesce a distinguere chiaramente tra azioni eseguite da agenti AI rispetto a umani. 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à, siete ciechi.
Crisis 3: Identità Frammentate e Scope Scope Creep
Con l’aumentare dell’adozione dell’IA, cresce anche il sprawl di identità. 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à fisse, gli agenti AI possono richiedere privilegi aggiuntivi, accedere a nuovi sistemi, e intraprendere azioni non esplicitamente predefinite.
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ù. Policy drift totale.
Fondamenti: Service Account Policies per Agenti AI
Principio 1: Identità Distinta, Non Impersonazione
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.
La differenza è fondamentale:
- Impersonazione (Sbagliato): Agent assume la vostra identità 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.
- Delega (Giusto): L’agente riceve un set limitato di privilegi – un grant esplicito che limita quello che può fare. L’identità dell’agente rimane separata dalla vostra, ogni hop nella catena è tracciabile, e i permessi seguono il principio del least privilege per design.
Nella pratica, ho implementato questo creando JWT scoped per ogni agente. Ecco un esempio:
Token AI Agent (Corretto):
{
"sub": "agent-email-processor-v2",
"aud": ["gmail-read-only", "slack-webhook"],
"scope": "read:email write:slack_notification",
"delegated_by": "user@company.com",
"permitted_labels": ["support-inbox"],
"expires_in": 3600,
"delegation_context": {
"task_id": "task-2026-08-15-001",
"max_operations": 1000,
"data_classification_max": "internal"
}
}
Notice: questo token ha scope limitato (read:email, write:slack), risorse target** (support-inbox), **expiry a breve termine (1 ora), e context di delega completo. Non è un copy/paste del vostro token personale.
Principio 2: Scope Binding Dinamico per Task
Sharma et al. propongono PAuth, che sfida il modello di autorizzazione scoped da operator di OAuth. PAuth introduce “NL slices” – specifiche simboliche delle tool call attese per servizio derivate da descrizioni di task in linguaggio naturale – e “envelopes” che legano i valori degli operandi alla provenienza simbolica.
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.
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:
Esempio MCP con Authorization Envelope: Task: "Summarize Q3 revenue report from Salesforce" Generated Scope: - Tool: salesforce/read-report (report_id: Q3-revenue-2026) - Tool: gpt4-write-draft-email - Denied: salesforce/write, delete, admin - Duration: 30 minutes - Data Classification Max: "confidential-finance" Task: "Send meeting summary to team Slack" Generated Scope: - Tool: slack/post-message (channel: #team-updates) - Denied: slack/delete, edit-others, admin - Duration: 5 minutes
Questo pattern garantisce che se l’agente viene compromesso durante il task Q3-revenue, l’attaccante non può accedere ai tool Slack o a report di altri quarters.
Principio 3: Zero Trust Authorization at Every Tool Call
L’agente gateway è il punto di enforcement della policy tra l’agente e ogni tool o API che chiama. Ogni invocazione di tool è una decisione di autorizzazione separata, non un grant di fiducia generale. Il gateway convalida: questo agente è autorizzato a chiamare questo tool? È questa chiamata dentro l’envelope operativo dichiarato dell’agente?
Ho deployato un agent gateway che ispeziona ogni tool call prima che raggiunga l’API target. Ecco il flusso:
- Agent esegue: “Leggi email da support-inbox”
- Gateway riceve la richiesta
- Gateway verifica:
- Token ancora valido?
- Scope include “read:email”?
- Mailbox target (support-inbox) è nella lista allowed?
- DLP policy: la query contiene pii-detector trigger?
- Rate limit non superato?
- Se tutto OK: Call raggiunge Gmail API con audit log generato
- Se fallisce: Call bloccata, alert generato, azione loggata
Nel nostro stack abbiamo usato CloudFlare Workers per il gateway, con policy scritta in Rego (OPA language):
Rego Policy Example:
allow_tool_call {
# Agente autenticato
input.token.valid
# Scope contiene la tool richiesta
input.token.scope[_] == input.tool.name
# Risorsa target è whitelisted
input.resource.id in input.token.permitted_resources
# DLP check
not contains_high_sensitivity_data(input.params)
# Rate limit
input.request_count < input.token.max_requests
# Task context ancora valido
time.now_ns() < input.token.expires_at
}
contains_high_sensitivity_data(params) {
regex.match("[0-9]{3}-[0-9]{2}-[0-9]{4}", params.query) # SSN pattern
}
Permission Scoping in Zero Trust: Blast Radius & Least Privilege
Calcolare il Blast Radius
Il blast radius misura il potenziale ambito del danno che un agente compromesso o manipolato potrebbe causare. Gli architetti della sicurezza dovrebbero considerare il blast radius durante la progettazione del connettore e dello scoping dei permessi, prima che un agente raggiunga mai la produzione.
Durante un’implementazione in una fintech, ho calcolato il blast radius di 5 agenti:
| Agent | Permessi Corrente | Blast Radius Assegnato | Blast Radius Target | Azione Richiesta |
|---|---|---|---|---|
| Email Processor | Read email, Write S3, Delete S3, Admin AWS | 🔴 CRITICAL | Read email only | Revoke S3, Delete, Admin |
| Report Generator | Read DB, Write file share, Slack notify | 🟡 MEDIUM | 🟢 LOW | Scope DB queries per report type |
| Slack Notifier | Post Slack, Read Slack, Delete Slack msgs | 🟡 MEDIUM | 🟢 LOW | Revoke Delete, restrict channel list |
Qui il pattern è: Un agente con full mailbox access, CRM write permissions, e repository sorgente collegati crea un livello di esposizione fondamentalmente diverso rispetto un agente limitato a sola lettura dentro una singola cartella di progetto. La tecnologia sottostante può essere simile, ma il rischio operativo è drasticamente diverso. Ecco perché il blast radius dovrebbe funzionare come uno strumento di scoping pratico quando si progettano i permessi del connettore.
Just-in-Time Authorization per Task
Just-in-time authorization si applica qui. Un agente dovrebbe essere scoped al progetto su cui sta lavorando nel momento in cui il suo task inizia, e quello scope dovrebbe essere rimosso quando il task termina. Standing access per agenti idle è esposizione inutile.
Ho implementato questo con una semplice Lambda + DynamoDB:
Pseudo-codice JIT Authorization:
function grant_task_permissions(agent_id, task_id, task_config) {
// 1. Verifica che il task sia approvato nel workflow
const approval = await db.query('approvals', {task_id});
if (!approval.approved) throw Error('Task not approved');
// 2. Genera token temporaneo
const jit_token = jwt.sign({
agent: agent_id,
task: task_id,
scope: task_config.required_scope,
resources: task_config.allowed_resources,
expires_at: now() + task_config.ttl // Es. 1 ora
}, JWT_SECRET);
// 3. Injetta il token come variabile d'ambiente (secure)
await kms.encrypt(jit_token);
await container.inject_env_var('AGENT_TOKEN', encrypted_token);
// 4. Quando task completa, token scade automaticamente
// + il container viene terminated
}
// Task completion hook
process.on('task_complete', async () => {
// Token non è più valido
// Revoke certificate in Vault
await vault.revoke_secret(agent_id);
});
Enforcing Permission Intersection Pattern
Il principio è: l’agente può fare quello che l’agente è autorizzato a fare **AND** quello che l’utente delegante è autorizzato a fare. **Non l’unione**.
Facciamo un esempio reale che ho visto andare male:
- User Alice ha permessi: {read:email, write:drive, admin:mailbox}
- Agent Email-Processor ha permessi dichiarati: {read:email, write:drive}
- Alice delega il task email-summarize all’agente
Cosa NON dovrebbe succedere: L’agente non dovrebbe avere accesso a admin:mailbox solo perché Alice lo ha. È l’unione (sbagliata).
Cosa dovrebbe succedere: L’agente riceve l’intersezione: {read:email, write:drive}. Anche se Alice avrebbe potuto fare admin:mailbox, l’agente no.
Ho implementato questo in Okta + custom OPA policy:
Authorization Policy (Intersection Pattern):
function compute_effective_scope(user_scope, agent_declared_scope, delegation_context) {
// 1. Prendi l'intersezione
const intersection = user_scope.filter(
permission => agent_declared_scope.includes(permission)
);
// 2. Applica il constraint del delegation_context
const task_constraints = delegation_context.allowed_operations || [];
const final_scope = intersection.filter(
permission => task_constraints.includes(permission)
);
return final_scope;
}
// Esempio di esecuzione
const user_alice_scope = ['read:email', 'write:drive', 'admin:mailbox'];
const agent_scope = ['read:email', 'write:drive'];
const delegation = {
allowed_operations: ['read:email'] // Task richiede solo lettura
};
const effective = compute_effective_scope(
user_alice_scope,
agent_scope,
delegation
);
// Result: ['read:email'] <- Intersection più ristretta possibile
Implementazione Pratica: Compliance + Audit Trail
I regolatori si aspettano ora audit trail chiari, documentazione e oversight dei sistemi AI, e i controlli di identity management dell’agente AI aiutano a fornire quel record. La tracciabilità è dove la pressione è più visibile. L’EU AI Act richiede logging, valutazione del rischio, oversight umano, e cybersecurity forte per sistemi AI ad alto rischio.
Le disposizioni di trasparenza dell’EU AI Act entrano in vigore il 2 agosto 2026. Se la vostra piattaforma non può produrre questo log su richiesta, non può supportare la conformità.
Audit Trail Completa (Cosa Loggare)
Ho definitivo uno standard di logging che copra ogni aspetto critico:
Complete Audit Record Structure:
{
"timestamp": "2026-08-15T14:23:45.123Z",
"event_type": "tool_call",
// Identità: chi ha fatto cosa
"actor": {
"type": "ai_agent",
"id": "agent-email-processor-v2",
"version": "2.1.4",
"owner": "platform-ops-team"
},
// Delega: per conto di chi
"delegated_by": {
"user_id": "user_alice_123",
"user_email": "alice@company.com",
"delegation_time": "2026-08-15T14:20:00.000Z",
"delegation_context": "task-process-support-emails-q3"
},
// Autorizzazione: cosa era permesso
"authorization": {
"granted_scope": ["read:email", "write:slack_notification"],
"token_id": "jti_abc123xyz",
"token_expires_at": "2026-08-15T15:20:00.000Z",
"permission_intersection_applied": true
},
// Azione: cosa ha fatto
"action": {
"tool_name": "gmail/list_messages",
"tool_version": "v1",
"parameters": {
"q": "from:customer@external.com",
"maxResults": 100,
"labelIds": ["support-inbox"]
},
"outcome": "success",
"execution_time_ms": 324,
"messages_returned": 45
},
// Dati: cosa è stato accessato
"data_access": {
"resource_type": "email",
"resource_count": 45,
"data_classification": ["internal", "customer-pii"],
"fields_accessed": ["from", "to", "subject", "body_snippet"],
"fields_redacted": ["body", "attachments"] // Sensitive data not logged
},
// Validazione: policy enforcement
"validation": {
"dlp_scan": "passed",
"rate_limit_check": "passed",
"scope_check": "passed",
"resource_whitelist_check": "passed",
"anomaly_score": 0.02 // Low risk
},
// Tracciabilità: per investigazioni
"request_id": "req-2026-08-15-001-abc",
"trace_id": "trace-e8f4d2a1b9c3",
"correlation_id": "task-process-emails-q3-batch-1"
}
Questo log soddisfa ogni requisito di compliance:
– EU AI Act transparency: Abbiamo un record completo di chi/cosa/quando/perché
– GDPR audit right: Possiamo mostrare quando dati personali sono stati processati
– SOX/PCI investigation: Traccia completa per breach post-mortem
Tutte questi log vanno in un SIEM (nel nostro caso Splunk) con alert rules che catturano anomalie:
Splunk Search: Anomalies Detection index=agent_audit actor.type="ai_agent" | stats count by actor.id, delegated_by.user_id | where count > 10000 // Soglia inusuale di operazioni | alert "Potential Agent Compromise" index=agent_audit validation.dlp_scan="failed" | alert "DLP Policy Violation Detected" | contact_security_team index=agent_audit data_access.data_classification="confidential-financial" NOT delegated_by.user_email="*-finance@company.com" | alert "Unauthorized Financial Data Access"
FAQ: Domande Ricorrenti su AI Agent Identity
Se gli agenti non impersonano gli utenti, come sanno chi sono quando operano?
L’agente ha una propria identità permanente (registrata nel catalogo IGA), ma i suoi scope cambiano per ogni task. Quando Alice delega un compito all’agente, quel delegation è parte del token JWT che l’agente riceve – non è impersonamento, è autorizzazione esplicita. L’agente sa: “Sto agendo per Alice su questo task specifico, con questi permessi specifici, per questa durata specifica”. Quando il task finisce, il token scade.
Come gestisco gli agenti che fanno sub-delegazioni (agent che chiama altro agent)?
Questo è critico. Un utente singolo potrebbe delegare a più agenti, ciascuno chiamando altri agenti, ciascuno accedendo a risorse diverse. Senza appropriata delega, si ottiene una rete intracciabile di identità impersonate con ampi permessi – esattamente il tipo di fiducia implicita che le architetture zero trust mirano a eliminare. Ho implementato un “token attenuation” chain: ogni livello di delega restringe i permessi ulteriormente. Così se Agent A delega a Agent B, Agent B avrà un subset di quello che ha Agent A.
E se un agente deve escalare i permessi durante l’esecuzione? Tipo scopre che ha bisogno di più scope mid-task?
Non deve farlo autonomamente. I trigger di escalation identificano cosa richiede revisione umana prima di procedere. Transazioni ad alto valore, accesso a categorie di dati sensibili, o comunicazioni con parti esterne potrebbero richiedere approvazione. Nel nostro sistema, l’agente genera una richiesta di escalation, una persona approva (o nega), e solo allora i permessi vengono espansi. Questo è loggato completamente.
Come proteggo i secret dell’agente (API key, credenziali) da leak in prompt injection o code execution?
Questa è una delle mie implementazioni più orgogliose. Non do all’agente i secret direttamente. Invece:
1. Ogni agente riceve una service account identity (come un cert X.509 o managed identity in cloud).
2. Il secret è conservato in un vault (HashiCorp Vault, AWS Secrets Manager, ecc.).
3. Il gateway che autentica le tool call fa lookup nel vault e inietta il secret just-in-time, senza mai esporlo all’agente.
4. Se l’agente è compromesso, non ha il secret – ha solo una richiesta per usarlo, che il vault può negare.
Questo riduce massivamente la superficie di un secret leak.
Come dimensiono il team security per governare centinaia di agenti in produzione?
Le revisioni manuali sono inadeguate per gestire il volume e la velocità dei deployment di agenti AI. I sistemi automatizzati devono scoprire nuovi agenti, classificare il loro accesso, rilevare comportamenti rischiosi, e far rispettare le policy in tempo reale. Questo approccio garantisce governance senza impedire l’innovazione. Nel nostro setup:
– **Continuous agent discovery:** Script che scansiona infrastruttura ogni ora
– **Automated risk classification:** ML model che valuta blast radius
– **Policy enforcement as code:** OPA policies che si auto-applican
– **Alert + correlation:** SIEM collega comportamenti anomali a agenti specifici
Il team security passa da “reviewing permissions” a “responding to anomalies”.
Link Interni: Approfondimenti Correlati
Se state già lavorando con architetture Zero Trust, vi consiglio di leggere il mio articolo su AI-Powered Zero-Trust Architecture Defense 2026, che approfondisce come rilevare shadow AI e LLM non autorizzate dentro la vostra rete.
Se gestite infrastrutture multi-tenant (come Plesk), il mio articolo su Plesk Multi-Tenant AI Workload Management mostra come isolere workload AI per tenant con proper identity boundaries.
Infine, per compliance NIS2 (che menziona esplicitamente l’AI governance), vedete NIS2 Compliance Readiness Aggiornamento 2026.
Conclusione: Identity è la Fondazione, Non un Optional
Quando ho iniziato a consultare su Identity Management per agenti AI 6 mesi fa, pensavo fosse un problema di compliance. Dopo dozzine di implementazioni, vedo che è il fondamento della security e dell’operabilità. Senza identity clara, scoping granulare, e audit trail completa, non potete:
– Tracciare cosa gli agenti fanno veramente
– Limitare il blast radius di un compromise
– Rispondere velocemente a un breach
– Soddisfare compliance (EU AI Act, NIS2, CRA)
Nel 2026, identity governance per agenti non è un optional. È il perimetro della sicurezza.
Se state deployando agenti in produzione senza questi controlli, vi consiglio di fare un audit urgente. Cominciate da questi step:
1. **Mappate tutti gli agenti** (shadow AI discovery)
2. **Calcolate il blast radius** di ogni agente
3. **Migrate da impersonation a delegation** (anche gradualmente)
4. **Centralizzate audit logging** in un SIEM
5. **Automate policy enforcement** con una policy engine (OPA, etc.)
La buona notizia: MCP OAuth 2.1, MCP-I al DIF, Microsoft Entra Agent ID – gli standard 2026 per l’identità degli agenti AI stanno prendendo forma. Le fondazioni sono qui. Il resto dipende da voi.
Condividete la vostra esperienza nei commenti: avete già affrontato la identity crisis nei vostri ambienti? Come l’avete risolta?