Agent gateway: il control plane che i tuoi agenti IA in produzione non dovrebbero ignorare

Finché un agente IA si limita a cercare informazioni o redigere una risposta, un errore rimane generalmente reversibile. Il rischio cambia natura quando può modificare un database, attivare un pagamento, inviare un'email, aprire un ticket o chiamare un servizio di terze parti.

A questo punto, una questione di architettura diventa centrale:

chi decide effettivamente se l'azione proposta dal modello può essere eseguita?

La risposta non può poggiare unicamente sul prompt dell'agente. Un modello probabilistico non deve essere l'unico responsabile dell'autorizzazione di un'azione deterministica.

Questo è il ruolo dell'agent gateway: posizionare un livello di controllo tra l'intenzione prodotta dall'agente e la sua esecuzione nel sistema reale.

AWS descrive ormai il suo AgentCore Gateway come uno strato di connettività unificato tra gli agenti, i loro strumenti e le loro risorse. Il suo motore di politiche può intercettare le richieste e valutare ogni chiamata prima di autorizzare l'accesso a uno strumento. Google presenta similmente il suo Agent Gateway come un punto centrale di applicazione delle politiche per le chiamate agli strumenti e le comunicazioni agentiche. (AWS Documentation)

La categoria è ancora in costruzione. Non tutte le piattaforme danno esattamente lo stesso ambito al termine agent gateway. Ma il bisogno architetturale è già chiaro:

Non appena un agente può produrre effetti collaterali significativi, uno strato di controllo deterministico deve separare la sua decisione dall'esecuzione.

Cos'è un agent gateway?

Un agent gateway è un punto di intercettazione e applicazione delle politiche posizionato sul percorso di esecuzione delle azioni di un agente.

Il suo ruolo non è rendere il modello più intelligente. Consiste nel verificare che l'azione proposta sia autorizzata, valida, tracciabile e compatibile con i vincoli operativi del sistema.

Un flusso semplificato funziona così:

1. Il modello propone l'utilizzo di uno strumento con parametri strutturati.
2. L'orchestratore trasmette questa richiesta al gateway.
3. Il gateway verifica l'identità, le permissions, i parametri, i quota e le regole di business.
4. L'azione è autorizzata, rifiutata o sospesa in attesa di una validazione umana.
5. Il risultato dello strumento è registrato e restituito all'orchestratore.

Nel caso degli strumenti eseguiti lato client con Claude, il modello non avvia da solo il codice di business. Restituisce un blocco tool_use, quindi l'applicazione decide se eseguire o meno lo strumento e gli trasmette il suo risultato. Questa separazione fornisce precisamente il punto di intercettazione necessario per l'applicazione delle politiche. (Claude Platform Docs)

Un agent gateway può essere:

• un componente sviluppato nell'orchestratore;
• un servizio indipendente;
• uno strato costruito attorno a un API gateway esistente;
• un policy engine collegato a server MCP;
• un servizio gestito fornito da una piattaforma cloud.

L'essenziale non è quindi acquistare un prodotto chiamato « Agent Gateway ». L'essenziale è disporre di un punto di enforcement non aggirabile prima di qualsiasi azione sensibile.

Perché i prompt e le permission statiche non bastano

Un'istruzione come « non rimborsare mai più di 5.000 € » è utile per guidare il modello. Non è una regola di sicurezza.

Può essere mal interpretata, aggirata da un injection di prompt, persa in un contesto troppo lungo o ignorata a seguito di un errore di ragionamento.

OWASP classifica l'excessive agency tra i rischi principali delle applicazioni basate su LLM: un modello dotato di funzionalità, permission o autonomia eccessive può provocare azioni dannose a partire da un output inaspettato, ambiguo o manipolato. La sua guida dedicata agli agenti raccomanda in particolare il least privilege, la validazione indipendente delle azioni sensibili e una supervisione umana adatta al loro impatto. (OWASP Gen AI Security Project)

Il problema non proviene solo da un agente « malevolo ». Un agente può provocare un incidente mentre persegue correttamente il suo obiettivo:

• ripete un'azione a causa di una cattiva gestione dei retry;
• interpreta scorrettamente una risposta di API;
• riutilizza un'informazione proveniente dal tenant sbagliato;
• sceglie uno strumento troppo potente per l'operazione richiesta;
• encatena più azioni valide producendo collettivamente un risultato indesiderato;
• applica un'istruzione iniettata in un email, un documento o una pagina web;
• continua un'operazione mentre il primo step ha parzialmente fallito.

La protezione deve quindi trovarsi fuori dal ragionamento del modello, in uno strato capace di applicare regole deterministiche.

I sei controlli di un agente in produzione

Un gateway serio non si riduce a una whitelist di strumenti. Deve rispondere a sei domande.

1. Controllo dell'identità

Chi richiede l'azione?

Bisogna poter distinguere:

• l'agente;
• l'applicazione o il workflow che lo esegue;
• l'utente finale per il quale agisce;
• l'organizzazione o il tenant interessato;
• la sessione;
• il livello di delegazione concesso.

L'identità dell'agente non deve limitarsi a un campo agent_id fornito nel payload. Deve essere attestata da un meccanismo di autenticazione verificabile.

Google per esempio distingue l'identità propria dell'agente e la sua capacità di agire per conto proprio o per conto di un utente. Il suo sistema Agent Identity si appoggia su un'identità crittografica e sullo standard SPIFFE. (Google Cloud Documentation)

2. Controllo dell'autorizzazione

Questo agente può utilizzare questo strumento in questo contesto preciso?

La regola non deve soltanto dire:

support-agent -> accesso CRM

Deve poter esprimere:

support-agent -> lettura degli ordini del tenant attuale -> nessuna esportazione globale -> nessuna cancellazione -> modifica limitata a certi campi

Il principio del least privilege deve applicarsi agli strumenti, alle operazioni, alle risorse e ai dati.

AWS permette per esempio di associare un motore di politiche a un gateway per valutare le chiamate agli strumenti prima della loro esecuzione. Le regole possono essere espresse in forma di politiche deterministiche, in particolare con Cedar. (AWS Documentation)

3. Controllo dei parametri

L'azione è permessa con questi parametri particolari?

Autorizzare lo strumento approve_refund non significa autorizzare tutti i rimborsi.

Il gateway deve in particolare poter verificare:

• gli importi;
• i destinatari;
• gli identificatori di tenant;
• le tabelle o colonne interrogate;
• i domini accessibili;
• i tipi e le dimensioni di file;
• gli intervalli di date;
• gli schemi di dati;
• i valori vietati.

Questa validazione deve essere deterministica e idealmente fondata su schemi rigorosi, non su una seconda istruzione in linguaggio naturale.

4. Controllo comportamentale

Il comportamento globale dell'agente rimane normale?

Una chiamata isolata può essere valida mentre la sequenza completa non lo è.

Il gateway deve poter rilevare:

• i loop;
• le raffiche di chiamate;
• i retry senza backoff;
• i costi anomali;
• i cambiamenti bruschi di strumenti;
• una successione inusuale di azioni;
• un volume di rifiuti che rivela un agente bloccato o mal configurato.

I rate limit e i circuit breaker devono essere calcolati per agente, utente, tenant, strumento e tipo di azione, non solo per indirizzo IP.

5. Controllo degli effetti

L'azione deve essere eseguita immediatamente?

Non tutte le azioni presentano lo stesso rischio.

Una politica ragionevole può distinguere:

• le azioni in lettura solo;
• le scritture reversibili;
• le azioni esterne visibili da un terzo;
• le operazioni finanziarie;
• le cancellazioni;
• le modifiche di permission;
• le azioni irreversibili.

Per le operazioni critiche, il gateway può imporre:

• una validazione umana;
• un'autenticazione rinforzata;
• una conferma dell'utente;
• un meccanismo a doppia approvazione;
• una simulazione preliminare;
• una chiave di idempotenza;
• un'esecuzione differita.

I meccanismi di approvazione proposti dalle piattaforme di agenti seguono questa logica. OpenAI prevede in particolare pause e validazioni per le chiamate che producono effetti collaterali o considerate distruttive. (OpenAI Developers)

6. Controllo post-esecuzione

Cosa è successo realmente?

Autorizzare un'azione non basta. Bisogna inoltre registrare:

• la richiesta iniziale;
• l'identità e la delegazione;
• la politica applicata;
• la decisione del gateway;
• i parametri validati;
• lo strumento chiamato;
• la risposta dello strumento;
• lo stato finale;
• gli eventuali errori o compensazioni.

Questa traccia permette di ricostruire un incidente, di misurare le prestazioni degli agenti e di distinguere una cattiva decisione del modello da un'avaria del sistema esterno.

Il tracing dell'OpenAI Agents SDK registra per esempio le generazioni, le chiamate agli strumenti, gli handoff, i guardrail e gli eventi personalizzati di una run. Questa osservabilità è utile, ma non sostituisce un journal aziendale duraturo e adatto agli obblighi dell'azienda. (OpenAI)

Dove posizionare il gateway nell'architettura?

La rappresentazione corretta non è necessariamente:

LLM -> gateway -> strumento

In molti sistemi, il modello non contatta mai direttamente lo strumento. Produce una proposta di chiamata strutturata, quindi l'orchestratore decide del proseguimento.

Un'architettura più fedele assomiglia a questa:

┌────────────────────────┐
│ Utente / evento        │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ Agent orchestrator     │
│ LangGraph, n8n, custom │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ LLM                    │
│ Proposta di tool call  │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ AGENT GATEWAY          │
│                        │
│ • identità             │
│ • autorizzazione       │
│ • validazione          │
│ • quota                │
│ • approvazione umana   │
│ • journalizzazione     │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ Tool executor          │
│ API, MCP, worker       │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ Sistema aziendale      │
│ CRM, DB, email, ERP    │
└────────────────────────┘

Il gateway è quindi un Policy Enforcement Point posizionato prima dell'esecutore di strumenti.

Deve essere impossibile aggirare questo punto chiamando direttamente:

• il database;
• un server MCP;
• l'API aziendale;
• una funzione cloud;
• un worker;
• un servizio di terze parti.

Un gateway che controlla solo un percorso di accesso mentre l'agente dispone di credenziali dirette agli strumenti crea un'illusione di sicurezza.

Agent gateway, API gateway e ai gateway: quali differenze?

Le tre categorie si sovrappongono parzialmente, ma non rispondono esattamente allo stesso problema.

Un API gateway come Kong, Nginx o un servizio cloud può costituire una parte della soluzione. Sa già autenticare, limitare e journalizzare le richieste.

Ciò che generalmente manca è il contesto agenticio e aziendale:

• quale agente agisce;
• per conto di chi;
• quale intenzione o compito è in corso;
• quale strumento è invocato;
• quali effetti l'azione può produrre;
• quale politica aziendale si applica;
• un'approvazione umana è richiesta;
• questa invocazione fa parte di un loop anormale.

L'approccio corretto non è quindi necessariamente sostituire l'API gateway. Può essere arricchito o completato da uno strato di politiche dedicato agli agenti.

Google infatti definisce il suo Agent Gateway come un'astrazione di rete che governa le interazioni client-agent, agent-strumento e agent-agent, con applicazione di politiche di sicurezza e controllo di accesso. (Google Cloud Documentation)

Tre casi d'uso concreti

Caso 1: un agente gestisce i rimborsi ai clienti

L'agente analizza una richiesta e propone un rimborso.

Una politica di gateway potrebbe imporre:

Importo ≤ 200 €:
    esecuzione automatica

200 € < importo ≤ 2.000 €:
    esecuzione autorizzata se l'account soddisfa i criteri aziendali

Importo > 2.000 €:
    validazione umana obbligatoria

Importo > 10.000 €:
    rifiuto automatico per questo workflow

La decisione del modello rimane utile: può qualificare il fascicolo e proporre un importo. Ma l'autorizzazione finanziaria è controllata da una regola indipendente.

AWS usa precisamente uno scenario di trattamento dei rimborsi nella sua documentazione per mostrare come le politiche possono limitare gli importi autorizzati. (AWS Documentation)

Caso 2: un agente interroga dati sensibili

Dare a un agente una connessione SQL generica è raramente una buona idea.

Un'architettura più sicura espone strumenti stretti:

get_customer_orders(customer_id)
get_order_status(order_id)
get_monthly_sales_summary(period)

Il gateway verifica quindi:

• che l'utente possa accedere al cliente richiesto;
• che il tenant corrisponda alla sessione;
• che solo le colonne autorizzate siano restituite;
• che le PII inutili siano mascherate;
• che la chiamata rimanga in sola lettura;
• che il volume di dati sia ragionevole.

Il miglior controllo di una query SQL pericolosa rimane spesso non fornire al modello la possibilità di generare SQL arbitrario.

Caso 3: un agente consuma API a pagamento

Un agente può produrre una fattura importante senza che nessuna chiamata individuale sia anormale.

Il gateway può applicare diversi budget:

100 chiamate per minuto e per agente
1.000 chiamate per ora e per tenant
200 € al giorno per il workflow
10 € massimo per un'esecuzione individuale

Oltre una soglia, può:

• rallentare le chiamate;
• aprire un circuit breaker;
• cambiare verso un modello o un fornitore meno costoso;
• sospendere solo lo strumento interessato;
• chiedere una validazione;
• arrestare la run.

Un'implementazione minimale

La prima versione non ha bisogno di essere un prodotto autonomo. Un wrapper ben congegnato attorno all'esecutore di strumenti può bastare.

from dataclasses import dataclass
from datetime import datetime, timezone
from decimal import Decimal
from typing import Any, Callable


class GatewayDenied(Exception):
    pass


@dataclass(frozen=True)
class InvocationContext:
    agent_id: str
    user_id: str
    tenant_id: str
    run_id: str


@dataclass(frozen=True)
class ToolPolicy:
    handler: Callable[..., Any]
    write_operation: bool = False
    max_amount: Decimal | None = None
    requires_approval: bool = False


class AgentGateway:
    def __init__(self, policies: dict[str, ToolPolicy], audit_sink):
        self.policies = policies
        self.audit_sink = audit_sink

    def invoke(
        self,
        context: InvocationContext,
        tool_name: str,
        params: dict[str, Any],
        approved_by: str | None = None,
    ) -> Any:
        started_at = datetime.now(timezone.utc)
        decision = "denied"
        result_status = "not_executed"

        try:
            policy = self.policies.get(tool_name)

            if policy is None:
                raise GatewayDenied("Tool not allowed")

            self._verify_identity(context)
            self._check_rate_limits(context, tool_name)
            self._validate_schema(tool_name, params)
            self._enforce_tenant_scope(context, params)

            if policy.max_amount is not None:
                amount = Decimal(str(params.get("amount", 0)))

                if amount > policy.max_amount:
                    raise GatewayDenied("Amount exceeds policy limit")

            if policy.requires_approval and approved_by is None:
                raise GatewayDenied("Human approval required")

            decision = "allowed"

            # Utilizzare una chiave di idempotenza per le scritture ritentabili.
            result = policy.handler(
                **params,
                tenant_id=context.tenant_id,
                idempotency_key=f"{context.run_id}:{tool_name}",
            )

            result_status = "succeeded"
            return result

        except Exception:
            result_status = "failed"
            raise

        finally:
            self.audit_sink.write({
                "timestamp": started_at.isoformat(),
                "agent_id": context.agent_id,
                "user_id": context.user_id,
                "tenant_id": context.tenant_id,
                "run_id": context.run_id,
                "tool": tool_name,
                "decision": decision,
                "result_status": result_status,
                # Non journalizzare ciecamente i segreti o le PII.
                "params": self._redact(params),
                "approved_by": approved_by,
            })

Questo codice illustra il principio di intercettazione. Non è un gateway pronto per la produzione.

Mancano ancora, a seconda del contesto:

• un'autenticazione crittografica;
• uno storage distribuito per i quota;
• una politica di delegazione;
• una validazione rigorosa degli schemi;
• la gestione dei segreti;
• la redazione dei dati sensibili;
• journal duraturi e protetti;
• i timeout;
• i retry limitati;
• i meccanismi di compensazione;
• l'alta disponibilità;
• le procedure di revoca;
• la protezione contro gli accessi diretti agli strumenti.

Roadmap di implementazione

Fase 1: inventariare le azioni e ridurre le permission

Prima di sviluppare un gateway, elencate tutti gli strumenti accessibili agli agenti.

Per ogni strumento, documentate:

• le risorse accessibili;
• le operazioni possibili;
• gli effetti collaterali;
• il carattere reversibile o irreversibile;
• i dati sensibili esposti;
• il costo potenziale;
• il livello di approvazione necessario.

Iniziate quindi da:

• rimuovere gli strumenti inutili;
• separare lettura e scrittura;
• sostituire gli strumenti generici con operazioni aziendali ristrette;
• aggiungere una validazione di schema;
• journalizzare le chiamate e i loro risultati.

Fase 2: centralizzare le politiche

Aggiungete un contesto di esecuzione strutturato:

• identità dell'agente;
• utente;
• tenant;
• run;
• obiettivo del workflow;
• livello di rischio;
• delegazione attiva.

Quindi centralizzate:

• le regole di autorizzazione;
• i limiti di importo;
• i quota;
• le approvazioni;
• le restrizioni temporali;
• le regole di dati;
• i circuit breaker.

Fase 3: industrializzare

Quando più team, agenti o ambienti utilizzano gli stessi strumenti, trasformate lo strato in servizio condiviso.

Aggiungete:

• un policy engine;
• una gestione centralizzata delle identità;
• un registro di agenti e strumenti;
• politiche versionizzate;
• tracce correlate;
• alert;
• test delle politiche;
• una modalità di osservazione senza blocco;
• una procedura di incidente;
• controlli di conformità.

Il NIST AI Risk Management Framework raccomanda di identificare le funzioni che richiedono supervisione umana, di definire i ruoli e le responsabilità e di adattare i meccanismi di controllo al contesto e al livello di rischio. (NIST)

Gli errori di implementazione più frequenti

1. Controllare il nome dello strumento, ma non i suoi parametri

Una whitelist che autorizza send_email senza verificare il destinatario, il dominio, il contenuto o il volume fornisce solo una protezione limitata.

Un'autorizzazione utile riguarda:

agente + utente + tenant + strumento + operazione + risorsa + parametri

2. Lasciare un percorso di aggravamento

Se il workflow può chiamare direttamente il CRM o il database, il gateway non è un punto di enforcement.

Le credenziali dei sistemi aziendali devono essere detenute dall'esecutore controllato, non esposte direttamente al modello o a un worker alternativo.

3. Journalizzare solo la richiesta

Un'azione può essere autorizzata quindi fallire parzialmente.

Bisogna registrare:

• la decisione;
• l'inizio dell'esecuzione;
• il risultato;
• i retry;
• lo stato finale;
• le compensazioni eventuali.

Per i sistemi asincroni, utilizzate un identificatore di correlazione comune tra la run dell'agente, l'invocazione, il job e l'evento aziendale.

4. Registrare i segreti nelle tracce

Gli strumenti manipolano spesso token, PII, dati finanziari o contenuti dei clienti.

Un audit trail utile non significa registrare l'integrità dei parametri e delle risposte senza filtaggio. La redazione e le regole di ritenzione devono essere concepite fin dall'inizio.

5. Applicare gli stessi limiti a tutte le azioni

Cento letture di catalogo e cento trasferimenti non presentano lo stesso rischio.

Le politiche devono dipendere da:

• dello strumento;
• dell'impatto;
• del tenant;
• del valore finanziario;
• del carattere reversibile;
• della fiducia accordata al workflow.

6. Bloccare senza informare l'orchestratore

Quando un'azione è rifiutata, l'agente deve ricevere un errore sfruttabile:

{
  "code": "HUMAN_APPROVAL_REQUIRED",
  "message": "I rimborsi superiori a 2000 EUR richiedono approvazione.",
  "retryable": false
}

Una risposta vaga come Access denied spinge spesso l'agente a ripetere la stessa azione.

7. Confondere osservabilità e autorizzazione

Tracciare una chiamata non ne impedisce l'esecuzione.

Il tracing aiuta a comprendere. Il gateway deve anche poter:

• autorizzare;
• rifiutare;
• modificare;
• sospendere;
• chiedere un'approvazione;
• aprire un circuit breaker.

Gateway interno o soluzione specializzata?

Il numero di agenti non è il criterio giusto.

Un singolo agente capace di effettuare trasferimenti può giustificare un'infrastruttura forte. Cinquanta agenti in sola lettura su dati pubblici possono rimanere dietro un wrapper relativamente semplice.

La decisione deve dipendere dalla criticità.

Iniziate in interno quando:

• avete pochi strumenti;
• i workflow sono controllati;
• le regole sono semplici;
• avete già un'infrastruttura IAM e di osservabilità solida;
• lo strato può rimanere vicino all'applicazione.

Industrializzate o comprate quando:

• più team duplicano gli stessi controlli;
• le politiche devono essere centralizzate;
• gli agenti utilizzano più runtime;
• i server MCP e gli strumenti si moltiplicano;
• gli obblighi di audit diventano importanti;
• mantenere le regole diventa un onere cognitivo o operativo.

Come sapere se il vostro agente ha bisogno di un gateway?

Attribuite un punto per ogni risposta positiva:

• L'agente scrive in un sistema aziendale?
• Può cancellare o rendere pubblici i dati?
• Manipola dati personali o confidenziali?
• Può impegnare una spesa?
• Può contattare un cliente o una terza parte?
• Dispone di più strumenti?
• Agisce per più utenti o tenant?
• Un'azione può essere irreversibile?
• Un errore può produrre un incidente normativo?
• Il workflow funziona senza supervisione umana diretta?

Interpretazione

• 0-2 punti: un wrapper semplice, permission ristrette e log possono bastare.
• 3-5 punti: mettete in atto un punto di enforcement esplicito e politiche versionizzate.
• 6 punti o più: trattate il gateway come un componente critico della vostra architettura.

Questa griglia non è uno standard. Serve a evitare una decisione fondata solo sulla dimensione del progetto o sul numero di agenti.

Conclusione

Un agent gateway non è un proxy magico che sicurizza automaticamente un sistema agenticio.

È un principio di architettura:

la decisione probabilistica del modello non deve mai costituire da sola l'autorizzazione di un'azione reale.

Non appena un agente produce effetti collaterali, dovete disporre di un punto di controllo capace di verificare la sua identità, la sua delegazione, le sue permission, i suoi parametri, il suo comportamento e l'impatto dell'azione.

Tre principi sono da ricordare:

1. Il prompt guida; la politica autorizza.
   Un'istruzione in linguaggio naturale non sostituisce una regola deterministica.

2. Il controllo deve essere non aggirabile.
   Tutti gli accessi sensibili devono passare per lo stesso punto di enforcement.

3. Il livello di controllo dipende dall'impatto, non dal numero di agenti.
   Un singolo agente può necessitare una governance forte se manipola pagamenti, permission o dati sensibili.

Non avete necessariamente bisogno di una piattaforma specializzata fin dal primo prototipo. Ma dovete definire molto presto dove si trova il confine tra ciò che l'agente propone e ciò che il vostro sistema autorizza realmente.

response = client.messages.create(
    model=MODEL_NAME,
    max_tokens=1024,
    tools=tool_definitions,
    messages=messages,
)

for block in response.content:
    if block.type != "tool_use":
        continue

    try:
        result = gateway.invoke(
            context=invocation_context,
            tool_name=block.name,
            params=block.input,
        )

        tool_result = {
            "type": "tool_result",
            "tool_use_id": block.id,
            "content": serialize_result(result),
        }

    except GatewayDenied as exc:
        tool_result = {
            "type": "tool_result",
            "tool_use_id": block.id,
            "is_error": True,
            "content": str(exc),
        }

    messages.append({
        "role": "assistant",
        "content": response.content,
    })

    messages.append({
        "role": "user",
        "content": [tool_result],
    })