Dare poteri agli agenti senza dare le chiavi all’LLM: dentro l’MCP Gateway di AIsuru

Dare poteri agli agenti senza dare le chiavi all’LLM: dentro l’MCP Gateway di AIsuru

Un agente conversazionale che risponde è utile. Un agente che agisce — manda email, scrive su un database, pianifica lavori, interroga altri agenti — è un’altra categoria di prodotto. Ma nel momento in cui un’AI può compiere azioni reali su sistemi reali, la domanda non è più «funziona?». La domanda è: chi sta agendo, con quali credenziali, e chi glielo permette?

È la domanda da cui è nato l’MCP Gateway di AIsuru: il piano di controllo che sta tra gli agenti AIsuru e il mondo esterno, e che fa una cosa apparentemente semplice ma decisiva — dà poteri agli agenti senza mai mettere le credenziali nelle mani del modello linguistico.

In questo articolo apriamo il cofano: prima il modello di sicurezza, poi i tre MCP che abbiamo costruito dentro il gateway — MCP Aisuru, MCP Persistence e MCP Scheduler.

Il principio: le credenziali non passano mai dall’LLM

È la regola architetturale numero uno, e tutto il resto discende da qui.

Quando un agente AIsuru deve usare uno strumento autenticato — leggere una casella Outlook, scrivere su un database, chiamare Microsoft Graph — non vede mai il token. Il gateway risolve l’identità della sessione, recupera la credenziale corretta dal proprio archivio cifrato e la inietta a runtime nel canale verso il sistema di destinazione. Il modello orchestra cosa fare; il gateway decide con quali chiavi. Le chiavi restano invisibili all’agente, ai prompt e ai log conversazionali.

Su questo principio abbiamo costruito una difesa in profondità, a strati:

Cifratura at-rest. Ogni segreto sensibile — access token, refresh token, client secret, parametri dei server MCP — è cifrato nel database con Lockbox (AES-256-GCM) e una master key che non vive nel codice. Un dump del database non espone credenziali in chiaro.

Token di sessione a vita breve. La comunicazione interna tra il gateway e i sotto-processi MCP (es. il connettore Outlook in modalità DCR) è protetta da un JWT firmato HS256 con scadenza di 15 minuti, sufficiente per una singola tool call. Niente token a lungo termine che girano tra i componenti.

IP allow-list sui path fiduciari. Gli endpoint che eseguono azioni (/execute, discovery dei tool, persistence) possono essere chiusi dietro una allow-list di indirizzi IP attivabile a caldo: solo le sorgenti autorizzate raggiungono il piano di esecuzione, le altre ricevono un 403 neutro.

Isolamento per identità. Ogni operazione è legata a un principal derivato dalla sessione AIsuru. Un utente non vede né tocca i dati o i task di un altro. E quando un’identità non è verificabile — per esempio una sessione anonima che pretende di agire per conto di un’email — il gateway blocca, non indovina.

Audit e interruttori. Ogni uso di una credenziale a runtime è tracciato in log strutturati. E dove serve, esistono kill switchglobali e circuit breaker automatici che mettono in pausa un comportamento anomalo senza bisogno di un deploy.

C’è poi un dettaglio che amiamo particolarmente, a metà tra sicurezza e robustezza: quando un agente sbaglia una chiamata, il gateway non risponde con un errore tecnico criptico ma con un messaggio semantico e azionabile (“questo strumento non esiste, forse intendevi X”). Il modello capisce e si corregge, invece di mostrare all’utente un “problema tecnico”. È sicurezza e affidabilità, perché un sistema prevedibile è un sistema più difficile da rompere.

Tutto questo gira su infrastruttura europea, coerente con il posizionamento di AIsuru sulla conformità all’AI Act e sulla sovranità del dato.

Su questo fondamento abbiamo costruito tre MCP interni. Non sono connettori a servizi di terzi: sono capacità native del gateway, pensate per agenti che devono ricordare, collaborare e agire nel tempo.

MCP Aisuru — gli agenti che parlano tra loro

Il primo MCP interno trasforma ogni agente in un interlocutore per gli altri agenti. Con MCP Aisuru, un agente AIsuru può aprire una sessione verso un altro agente, fargli una domanda, cercare nella sua conoscenza, e usarne la risposta come parte del proprio ragionamento.

È il fondamento dei sistemi multi-agente: un agente “concierge” che interpella lo specialista legale, quello tecnico e quello commerciale e compone una risposta unica. Tutto resta dentro la piattaforma, con la stessa identità di sessione e lo stesso modello di sicurezza del resto del gateway.

La parte interessante è come lo fa. Le risposte veloci tornano subito, nello stesso turno. Quelle lente — una ricerca complessa, una generazione articolata — non bloccano: il lavoro pesante viene messo in coda e l’agente ritira il risultato in un turno successivo. Questo modello asincrono a turni evita che una chiamata lunga saturi le risorse, e rende l’orchestrazione tra agenti scalabile invece che fragile. Abbiamo portato questa logica dentro il gateway, sostituendo un microservizio esterno: meno superfici, più controllo.

MCP Persistence — una memoria strutturata, isolata per agente

Gli LLM sono senza stato: dimenticano tutto tra una sessione e l’altra. MCP Persistence dà a ogni agente una memoria strutturata e duratura — un vero database — gestibile interamente in linguaggio naturale.

«Gestiscimi un’anagrafica clienti con nome, azienda, settore, ultimo contatto e note.» L’agente capisce la struttura, la crea da solo, e da quel momento la gestisce: inserisce, cerca, aggiorna, cancella. Nessun foglio Excel, nessun database da configurare, nessuna app da sviluppare.

Dietro la semplicità c’è un’architettura di isolamento rigorosa, ed è qui che la sicurezza torna protagonista. Ogni agente ha il proprio database MongoDB dedicato, con un proprio utente tecnico le cui autorizzazioni sono limitate esclusivamente a quel database. I dati di un agente sono fisicamente separati da quelli di ogni altro: non c’è una collezione condivisa con un campo “tenant” su cui un errore di query potrebbe far trapelare dati altrui. C’è proprio un confine di database, con credenziali a scope minimo.

E poi una serie di accorgimenti pensati perché un’AI possa amministrare un database senza farsi male:

• Auto-indicizzazione delle collezioni nuove e index advisor che suggerisce cosa creare prima di andare in produzione, con un tetto al numero di indici per evitare che il modello ne crei a sproposito.
• Retention configurabile (TTL) consentita solo su campi-timestamp riconosciuti, mai su campi arbitrari: la cancellazione automatica è uno strumento potente e va recintato.
• Data View anti-allucinazione. Per mostrare dati in tabella, l’agente non riformatta i numeri “a memoria” — genera una vista HTML servita direttamente dal database e la incorpora. I dati che vedi sono i dati che ci sono, non una loro parafrasi probabilistica.

MCP Scheduler — agenti che lavorano anche quando non ci sei

Il terzo MCP è quello che chiude il cerchio tra “rispondere” e “agire nel tempo”. Con MCP Scheduler un utente, semplicemente parlando con l’agente, può dire: «ogni mattina alle 7 analizza i dati del CRM e mandami un riassunto» oppure «tra dieci minuti ricordami di chiamare il fornitore». Il gateway crea un task autonomoche gira in background — ricorrente (cron) o una tantum — e che all’orario stabilito riapre una sessione con l’agente ed esegue il lavoro da solo, orchestrando i propri MCP collegati.

Supporta anche task multi-fase: l’agente esegue un primo passo (produrre un report), poi i passi successivi nella stessa sessione, mantenendo il contesto (“ora mandalo via email”, “ora registralo nel CRM”). Un piccolo flusso di lavoro autonomo, descritto in una frase.

Far agire un’AI senza un umano davanti allo schermo è esattamente lo scenario in cui la sicurezza non è negoziabile. Per questo lo Scheduler è il componente più blindato del gateway:

• Nessuna delega “al buio”. Durante l’esecuzione, l’autorizzazione del task verso i sistemi autenticati è una mappatura a vita brevissima (con un tetto rigido), legata all’unica credenziale che il proprietario aveva al momento della creazione, revocata appena il task finisce. Non c’è impersonificazione: l’identità non cambia, cambia solo lo specifico permesso, e ogni utilizzo è tracciato.
• Niente task fantasma. Un task è persistente, può girare per mesi: per crearlo serve un’identità AIsuru verificabile. Le sessioni anonime vengono rifiutate, così ogni task resta sempre attribuibile e revocabile dal suo proprietario.
• Isolamento doppio. Un utente vede e gestisce solo i propri task, e solo quelli creati sull’agente con cui sta parlando.
• Sicurezza operativa. Un kill switchglobale ferma tutti i task in un istante senza deploy; un circuit breaker mette automaticamente in pausa un task dopo una serie di fallimenti consecutivi; una modalità dry run permette di provare un task senza eseguire azioni irreversibili. E i job non vengono mai ritentati ciecamente: un task non è idempotente — un retry ripetuto significherebbe mandare due volte la stessa email — quindi gli errori transitori vengono assorbiti dal ciclo successivo, non duplicati.

Non un connettore in più: un piano di controllo

La differenza tra un assistente che chiacchiera e un agente che lavora è tutta qui: nella capacità di agire in sicurezza. Si può collegare un LLM a un database in un pomeriggio. Costruire il livello che decide chi può fare cosa, con quali chiavi, per quanto tempo e sotto quale audit — quello è il lavoro.

L’MCP Gateway di AIsuru è questo livello. E i tre MCP che ci girano sopra — Aisuru per la collaborazione tra agenti, Persistence per la memoria isolata, Scheduler per l’autonomia nel tempo — non sono integrazioni di terzi: sono capacità native, progettate fin dall’inizio con la sicurezza come vincolo, non come ripensamento.

Perché gli agenti del futuro non si limiteranno a rispondere. Agiranno. E il punto non è soltanto dargliene il potere — è non dover mai consegnare loro le chiavi.