Proteggere gli agenti IA in produzione: identità e controllo degli accessi

I primi assistenti IA distribuiti in azienda avevano un ruolo relativamente passivo. Rispondevano a domande, riassumevano documenti o generavano contenuti. Il loro impatto si limitava alla produzione di informazioni.

Le architetture agentic cambiano completamente questa logica.

Oggi, un agente può aprire un ticket Jira, modificare un CRM, avviare un workflow CI/CD, inviare un'email, attivare un rimborso Stripe o concatenare diversi call API in modo autonomo.

Dal momento in cui un agente agisce su sistemi reali, una domanda diventa imprescindibile:

Chi agisce realmente?

Non è una questione di fornitore del modello, di framework o di protocollo. È una questione di architettura.

---

Una nuova categoria di identità

Per anni, le architetture di sicurezza si sono basate su due categorie di identità:

• gli utenti umani;
• le identità tecniche (applicazioni, servizi, microservizi).

Gli agenti IA non appartengono completamente a nessuna di queste categorie.

Ragionano, scelgono gli strumenti, adattano le loro azioni al contesto ed eseguono talvolta decine di operazioni successive.

Costituiscono una nuova categoria di identità che in questo articolo chiameremo identità agentic.

Definizione

Un'identità agentic è l'insieme delle informazioni che consentono di identificare un agente, di determinare per conto di chi agisce, di conoscere i limiti della sua autonomia e di ricostruire ciascuna delle sue decisioni.

Questa definizione servirà come filo conduttore per il resto dell'articolo.

---

Una chiave API non è un'identità

Le prime implementazioni di agenti seguono spesso questa architettura.

Applicazione
      │
      ▼
 Chiave API LLM
      │
      ▼
   Agente IA

Questa rappresentazione è conveniente.

È anche fuorviante.

La chiave API identifica la vostra applicazione presso il fornitore del modello.

Non identifica l'agente che agisce nel vostro sistema informativo.

Due agenti possono condividere la stessa chiave API mentre hanno responsabilità completamente diverse.

L'identità dell'agente appartiene quindi alla vostra architettura, non al fornitore del modello.

---

Il modello non realizza mai direttamente un'azione

Si sente spesso dire:

"Claude ha eliminato un ordine."

oppure

"GPT ha creato un rimborso."

In realtà, un modello linguistico emette solo una proposta.

La vostra infrastruttura decide poi:

• se questa azione è autorizzata;
• con quali permessi;
• per quale utente;
• su quali risorse.

Utente
      │
      ▼
Applicazione
      │
      ▼
Agent Runtime
      │
propone un'azione
      ▼
Policy Engine
      │
      ▼
Strumento business
      │
      ▼
Sistema di destinazione

Questa separazione tra ragionamento ed esecuzione costituisce uno dei principi fondamentali delle architetture agentic moderne.

---

La vera questione è la responsabilità

Un'azienda deve essere in grado di rispondere, settimane dopo un incidente:

• Quale agente ha agito?
• Per quale utente?
• In quale tenant?
• Quale politica ha autorizzato questa operazione?
• Quale strumento è stato invocato?

Un log che indica solo:

"Il modello ha chiamato updateCustomer()"

fornisce praticamente nessun valore.

Un'architettura moderna deve consentire di ricostruire l'intera catena di decisione.

---

Un'identità è sempre contestuale

Lo stesso agente può operare:

• per più utenti;
• in più organizzazioni;
• su più ambienti;
• con permessi diversi a seconda dell'attività.

La sua identità non si riduce mai a un semplice identificatore.

Agente
 ├ identità
 ├ utente rappresentato
 ├ tenant
 ├ ambiente
 ├ sessione
 └ permessi temporanei

Il contesto fa parte integrante dell'identità.

---

Le architetture storiche non affrontano questa problematica

OAuth, OpenID Connect, Kubernetes Service Accounts o le identità dei workload rispondono principalmente a una domanda:

Quale componente richiede l'accesso a una risorsa?

Gli agenti IA aggiungono una dimensione supplementare:

Perché questa azione viene eseguita, per conto di chi e entro quali limiti?

È questa differenza che giustifica un nuovo livello di governance.

---

Prima di parlare di JWT o rbac

La maggior parte degli articoli inizia subito con le tecnologie:

• JWT;
• OAuth;
• RBAC;
• Vault;
• rotazione dei segreti.

Tutte sono importanti.

Ma arrivano troppo presto.

Prima di scegliere una tecnologia, bisogna definire cos'è l'identità di un agente e quali informazioni deve portare.

Questo è precisamente l'obiettivo del capitolo successivo, che introduce un Agent Identity Reference Model indipendente dai fornitori, dai framework e dai modelli linguistici.

Da ricordare

I modelli evolveranno.

I framework cambieranno.

I protocolli appariranno e poi scompariranno.

D'altro canto, ogni architettura agentic dovrà sempre rispondere alla stessa domanda:

Chi agisce realmente, per conto di chi, con quali permessi e sotto quale controllo?

Definizione

Un Agent Identity Reference Model è un modello concettuale che descrive le informazioni minime che una piattaforma deve conoscere per identificare un agente, determinare in nome di chi agisce, decidere quali azioni può realizzare e assicurare la tracciabilità completa della sua attività.

Una volta che si considera un agente come una vera identità software, una nuova domanda appare immediatamente:

Di quali informazioni ha veramente bisogno una piattaforma per autorizzare un agente ad agire?

La maggior parte delle implementazioni risponde con un elenco di meccanismi tecnici: un JWT, una chiave API, alcuni permessi e talvolta un ruolo RBAC.

In realtà, questi meccanismi esprimono solo una parte dell'identità. Affinché un agente possa agire in modo sicuro, è necessario rispondere a diverse domande indipendenti.

Panoramica

Livello	Domanda	Esempi di tecnologie
Identity	Chi è questo agente?	UUID, SPIFFE ID
Authentication	Può provare la sua identità?	JWT, OAuth 2.0, mTLS
Delegation	Per conto di chi agisce?	OAuth, OIDC
Authorization	Cosa può fare?	RBAC, ABAC, Cedar, OPA
Secrets	Come accede alle risorse?	Vault, AWS Secrets Manager
Observability	Si può spiegare ogni decisione?	OpenTelemetry
Revocation	Si può fermarlo immediatamente?	Token revocation

I livelli sono indipendenti

Un errore frequente consiste nel mescolare diverse responsabilità.

Un JWT non decide i permessi. Un motore di politiche non prova l'identità. Un gestore di segreti non autorizza alcuna azione.

Ogni livello risponde a una responsabilità unica. Questa separazione consente di sostituire una tecnologia senza mettere in discussione l'architettura globale.

Schema del modello

                         Identity
                              │
            ┌─────────────────┴─────────────────┐
            │                                   │
    Authentication                    Delegation
            │                                   │
            └─────────────────┬─────────────────┘
                              ▼
                      Authorization
                              │
             ┌────────────────┴────────────────┐
             │                                 │
         Secret Access                 Observability
             │                                 │
             └────────────────┬────────────────┘
                              ▼
                         Revocation

Identity non è authentication

Questi due concetti sono spesso confusi.

L'identità descrive chi è l'agente.

L'autenticazione verifica che sia realmente chi dice di essere.

Essere autenticati non significa mai essere autorizzati.

I sei livelli

1. Identity

Ogni agente possiede un identificatore stabile, una versione, un proprietario e un ambiente di esecuzione.

agente:
  id: support-agent
  version: 2.3.1
  owner: customer-support
  environment: production

2. Authentication

L'autenticazione consente di provare questa identità mediante un JWT, OAuth, mTLS o un'identità di workload.

3. Delegation

Un agente agisce raramente per proprio conto. Agisce per un utente, un tenant o un processo di business.

4. Authorization

Le autorizzazioni moderne si basano sempre più su motori di politiche.

I principali modelli sono:

• RBAC
• ABAC
• PBAC
• ReBAC

Le architetture agentic generalmente privilegiano PBAC, capace di valutare il contesto di esecuzione.

Esempio Node.js:

const decision = await policyEngine.evaluate({
  identity,
  tool: "refundOrder",
  amount: 75,
  tenant: "acme",
});

if (!decision.allow) {
  throw new ForbiddenError(decision.reason);
}

await refundOrder();

5. Secrets

Il modello non manipola mai direttamente i segreti.

Esprime un'intenzione; l'applicazione recupera i segreti presso un gestore dedicato.

6. Observability

Ogni decisione deve essere tracciabile: identità, utente rappresentato, politica applicata, risultato e durata dell'esecuzione.

7. Revocation

Qualsiasi identità deve poter essere disabilitata immediatamente per prevenire qualsiasi nuova azione.

Da ricordare

I modelli cambiano.

I framework evolvono.

I protocolli appaiono e poi scompaiono.

D'altro canto, un'architettura dovrà sempre rispondere alle stesse domande:

• Chi agisce?
• Per conto di chi?
• Cosa può fare?
• Come si proteggono le risorse?
• Come si spiegano le decisioni?
• Come si ferma immediatamente questo agente?

Finché queste domande trovano una risposta, la vostra architettura rimane valida indipendentemente dal fornitore del modello o dal framework utilizzato.

L'Agent Identity Reference Model presentato nel capitolo precedente è volontariamente indipendente dalle tecnologie.

Risponde a una domanda di architettura:

Quali informazioni è necessario gestire per proteggere un agente?

Questo capitolo risponde a un'altra domanda:

Come implementare concretamente questo modello in un'applicazione moderna?

La buona notizia è che non è necessario inventare un nuovo stack di sicurezza. La maggior parte delle aziende possiede già i mattoni necessari.

Un'architettura di riferimento

                  Utente
                        │
                        ▼
              Identity Provider
                        │
                        ▼
             Applicazione business
                        │
                        ▼
                 Agent Runtime
        ┌───────────────┼────────────────┐
        ▼               ▼                ▼
 Policy Engine    Secret Manager    Observability
        │
        ▼
    Tool Gateway
        │
   ┌────┼───────────────┐
   ▼    ▼               ▼
 CRM PostgreSQL      Stripe

Il modello linguistico non è volontariamente il centro dello schema.

Produce proposte.

Il runtime applica le politiche di sicurezza.

Il runtime diventa il punto di controllo

Ogni chiamata di strumento deve essere trattata come una decisione di sicurezza.

Prima di eseguire un'azione, il runtime deve rispondere a diverse domande:

• Chi è l'agente?
• Per quale utente agisce?
• Quale tenant è interessato?
• Questa azione è autorizzata?
• I limiti di sicurezza sono rispettati?

In altre parole, il runtime diventa un Policy Enforcement Point (PEP).

Un middleware node.js piuttosto che logica dispersa

Una buona pratica consiste nel centralizzare i controlli.

export async function authorizeTool(ctx, toolName) {

  const decision = await policyEngine.evaluate({
    identity: ctx.identity,
    tool: toolName,
    tenant: ctx.tenant,
    delegatedUser: ctx.user.id
  });

  if (!decision.allow) {
    throw new ForbiddenError(decision.reason);
  }

  return decision;
}

Poi ogni strumento utilizza questo middleware.

server.registerTool({
  name: "refundOrder",

  async execute(args, ctx) {

    await authorizeTool(ctx, "refundOrder");

    return refundService.execute(args);
  }
});

In questo modo, le regole di sicurezza restano indipendenti dal modello e dal prompt.

Un JWT trasporta un'identità, non decide nulla

Un JWT può contenere informazioni utili:

{
  "agent":"support-agent",
  "tenant":"acme",
  "delegatedUser":"user-482",
  "scope":["orders.read","orders.update"]
}

Ma un JWT non risponde mai alla domanda:

Questa operazione è autorizzata adesso?

Questa decisione appartiene sempre al motore di politiche.

I permessi sono valutati ad ogni azione

In un'architettura agentic, i permessi non sono fissi al momento del login.

Ogni chiamata di strumento costituisce una nuova decisione.

Ad esempio, un rimborso può dipendere da:

• l'importo;
• il tenant;
• il ruolo dell'utente rappresentato;
• l'ambiente;
• la politica di rischio.

Il runtime deve quindi interrogare un motore di politiche prima di ogni operazione sensibile.

Gli strumenti rappresentano capacità di business

Evitate di esporre primitive tecniche direttamente.

Da evitare:

executeSQL()
executeShell()
deleteCustomer()

Preferite strumenti che esprimono un'intenzione di business.

findCustomer()
refundOrder()
updateShippingAddress()
generateInvoice()

Questo approccio riduce notevolmente la superficie di attacco e semplifica le politiche di autorizzazione.

I segreti non escono mai dall'infrastruttura

Il modello non dovrebbe mai ricevere una chiave Stripe, una password PostgreSQL o un token AWS.

Il runtime recupera questi segreti presso un gestore dedicato.

import Stripe from "stripe";

const stripe = new Stripe(
  await secretManager.get("stripe-API-key")
);

Il modello esprime un'intenzione.

L'applicazione realizza la chiamata tecnica.

MCP non sostituisce i controlli

Il Model Context Protocol (MCP) standardizza la scoperta e l'invocazione degli strumenti.

Non decide mai se uno strumento può essere utilizzato.

Anche se un server MCP espone:

deleteAllCustomers()

la decisione finale appartiene sempre a:

• il runtime;
• il motore di politiche;
• la vostra architettura.

MCP descrive le capacità.

La vostra piattaforma decide quali sono realmente accessibili.

Build o buy?

Non tutti i team hanno le stesse esigenze.

Dimensione del progetto	Raccomandazione
Prototipo	Regole codificate nel runtime
Pochi agenti	RBAC semplice
Multi-tenant	Policy Engine
Organizzazione regolamentata	Cedar, OPA o soluzione equivalente

Il passaggio a un motore di politiche si giustifica quando le regole diventano numerose, dinamiche o condivise tra più agenti.

Un'architettura durevole

Uno dei principali vantaggi di questo approccio è la sua indipendenza dai fornitori.

Potete sostituire:

• Claude con GPT;
• GPT con Gemini;
• LangGraph con CrewAI;
• MCP con un altro protocollo.

L'architettura di sicurezza rimane invariata.

Il vostro runtime, le vostre politiche, i vostri segreti e i vostri log di audit appartengono al vostro sistema informativo.

Costituiscono il vero strato di fiducia della vostra piattaforma.

Da ricordare

Il modello linguistico non è mai l'autorità di sicurezza.

Propone azioni.

La vostra infrastruttura decide se possono essere eseguite.

A questo punto, un'architettura moderna dispone di:

• un'identità per ogni agente;
• un meccanismo di autenticazione;
• un motore di politiche;
• una gestione centralizzata dei segreti.

Questi componenti sono necessari, ma non sono sufficienti.

Un'architettura è realmente sicura solo se può essere verificata, spiegata e fermata in qualsiasi momento.

L'audit non è più un semplice file di log

In un sistema agentic, non basta più registrare che un endpoint è stato chiamato.

Ogni decisione importante dovrebbe produrre un evento che traccia:

• l'identità dell'agente;
• l'utente rappresentato;
• il tenant;
• lo strumento richiesto;
• la politica applicata;
• la decisione (ALLOW o DENY);
• il risultato dell'esecuzione.

Esempio:

{
  "timestamp": "2026-07-17T10:48:31Z",
  "agent": "support-agent",
  "delegatedUser": "user-482",
  "tenant": "acme",
  "tool": "refundOrder",
  "decision": "ALLOW",
  "policy": "refund-policy-v3",
  "durationMs": 91
}

Questi eventi permettono di ricostruire una decisione settimane dopo la sua esecuzione.

Gli anti-pattern più frequenti

1. Una chiave API condivisa

Tutti gli agenti utilizzano la stessa identità.

Conseguenza: impossibile sapere quale sia responsabile.

2. I segreti trasmessi al modello

Una chiave Stripe o una password SQL non dovrebbero mai apparire nel contesto inviato all'LLM.

3. Permessi definiti nel prompt

Un prompt non costituisce un meccanismo di sicurezza.

Le regole di autorizzazione devono essere implementate lato infrastruttura.

4. Strumenti troppo generici

Evitate:

executeSQL()
executeShell()

Preferite:

createInvoice()
updateShippingAddress()

Gli strumenti devono rappresentare intenzioni di business.

Una checklist di audit

Prima della messa in produzione, verificate in particolare:

• Ogni agente possiede un'identità univoca?
• Gli utenti rappresentati sono identificati?
• Le autorizzazioni sono valutate prima di ogni chiamata di strumento?
• I segreti sono archiviati in un Secret Manager?
• Ogni decisione è registrata in un log?
• Un agente può essere revocato immediatamente?
• Gli strumenti espongono capacità di business piuttosto che primitive tecniche?

Se una risposta è negativa, l'architettura merita probabilmente di essere rivista.

Zero trust applicato agli agenti

I principi di Zero Trust rimangono perfettamente adatti alle architetture agentic.

Ogni richiesta deve essere:

• autenticata;
• autorizzata;
• tracciata;
• limitata al necessario.

Nessun agente dovrebbe essere considerato implicitamente affidabile.

Domande frequenti

È necessario un JWT per agente?

Non necessariamente.

L'importante è che ogni esecuzione disponga di un'identità autenticabile e contestualizzata.

Rbac è sufficiente?

Per un prototipo, spesso sì.

Per più agenti, più tenant o regole dinamiche, un motore di politiche diventa rapidamente preferibile.

MCP protegge gli strumenti?

No.

MCP descrive gli strumenti disponibili.

I controlli di accesso rimangono a carico della vostra piattaforma.

Il modello deve conoscere i segreti?

Mai.

Il modello formula un'intenzione.

Il runtime realizza le chiamate tecniche con le proprie identità.

Conclusione

Per molto tempo, la sicurezza delle applicazioni si è organizzata intorno agli utenti e ai servizi.

Le architetture agentic introducono una terza categoria di identità: l'agente autonomo.

Questa evoluzione impone di ripensare diversi fondamenti:

• l'identità;
• la delega;
• l'autorizzazione;
• la gestione dei segreti;
• l'osservabilità;
• la revoca.

Le tecnologie continueranno a evolversi.

I modelli linguistici verranno sostituiti.

I framework cambieranno.

D'altro canto, le domande fondamentali rimangono le stesse:

• Chi agisce?
• Per conto di chi?
• Con quali permessi?
• Come spiegare ogni decisione?
• Come interrompere immediatamente un agente?

Le organizzazioni in grado di rispondere avranno un'architettura durevole, indipendente dai fornitori di modelli e sufficientemente robusta per far evolvere i loro sistemi agentic nel tempo.