AgentCore Gateway: collegare agenti AI a gestionali e API private con TLS

AgentCore Gateway può collegare un agente AI a strumenti e API private che usano certificati TLS emessi da un'autorità di certificazione privata. Per una PMI con un gestionale interno, la novità riguarda il collegamento sicuro fra i componenti del sistema. Non attribuisce automaticamente all'agente il diritto di leggere o modificare ogni dato.

AWS ha annunciato il supporto il 2 ottobre 2026. I target MCP, OpenAPI e HTTP proxy possono usare TLS con CA privata; il percorso verso endpoint privati impiega VPC Lattice. La disponibilità va verificata nelle regioni in cui coesistono AgentCore Gateway e VPC Lattice. Annuncio AWS.

La conseguenza pratica è poter valutare un'architettura che non esponga direttamente il gestionale sul web per farlo usare da un agente. Rimangono da progettare identità, strumenti consentiti, controlli sulle scritture e gestione degli errori. Sono questi elementi a trasformare un collegamento di rete in un servizio aziendale affidabile.

Perché un gestionale interno crea un problema agli agenti?

Molte applicazioni aziendali sono disponibili soltanto nella rete interna o attraverso percorsi controllati. Un agente eseguito in un altro ambiente non può semplicemente chiamarle come un servizio pubblico. Aprire una porta verso Internet può sembrare la scorciatoia più facile, ma introduce un'esposizione che deve essere motivata e governata.

Inoltre, l'applicazione può utilizzare un certificato riconosciuto dall'infrastruttura aziendale ma non dalle autorità pubbliche normalmente considerate attendibili. Il componente che effettua la chiamata deve sapere quale CA privata accettare. Disabilitare la verifica del certificato per far passare il test elimina proprio il controllo che dovrebbe proteggere il collegamento.

La novità AgentCore affronta questo pezzo dell'architettura. Il gateway può raggiungere target privati attraverso il percorso documentato e usare un trust anchor configurabile per la CA. Non rende superflue le verifiche sull'applicazione. La guida AWS sul VPC egress descrive il disegno da valutare con chi gestisce la rete.

Che cosa garantiscono TLS, rete privata e permessi?

TLS protegge il collegamento e la verifica dell'identità del servizio secondo la configurazione adottata. Una rete privata limita il percorso di raggiungibilità. Le autorizzazioni stabiliscono invece chi possa compiere una determinata operazione su uno specifico dato. Nessuno di questi controlli può essere usato come sinonimo degli altri.

Un agente può raggiungere correttamente un'API privata e avere comunque troppi permessi. Può autenticarsi con successo e chiedere il documento di un cliente estraneo alla richiesta. Può inviare parametri tecnicamente validi che producono un risultato commerciale sbagliato. Questi casi richiedono controlli nel livello applicativo, oltre al collegamento protetto.

Per questo conviene descrivere il sistema con verbi concreti: leggere lo stato dell'ordine, preparare una richiesta, aggiornare un campo consentito. “Accesso al gestionale” è una definizione troppo larga. La guida alla sicurezza dei dati AI aiuta a ragionare su minimizzazione e accessi; l'integrazione deve poi tradurre questi principi in operazioni effettivamente limitate.

Quali API conviene esporre all'agente?

Un gestionale può avere un'API estesa, progettata per utenti o applicazioni con responsabilità diverse. Presentare tutte le sue funzioni a un agente rende più difficile verificare comportamento e autorizzazioni. Spesso è preferibile costruire una superficie più piccola, con operazioni coerenti con il processo scelto.

Per la consultazione di un ordine, per esempio, lo strumento può richiedere identificativo del cliente e numero dell'ordine, controllare la relazione fra i due e restituire soltanto stato e informazioni utili. Non dovrebbe consegnare automaticamente documenti contabili, margini o note interne. I campi del risultato sono una decisione di progetto, non un dettaglio del prompt.

Quando servono modifiche, lo strumento deve verificare parametri e stato corrente. Una richiesta di cambio indirizzo può essere ammessa prima della spedizione e rifiutata dopo, secondo le regole dell'azienda. Il modello non dovrebbe essere l'unico componente che applica questa regola. Gli agenti AI per aziende funzionano meglio quando ragionamento e vincoli operativi restano distinguibili.

Come scegliere il livello di integrazione?

La tabella propone criteri di progettazione. Non significa che ogni applicazione interna sia già compatibile con il gateway. Se manca un'API adatta, può servire un connettore o una modifica del software. Se il problema è un flusso fra applicazioni, integrare un gestionale con n8n affronta una parte diversa del lavoro.

Anche l'espansione europea di AWS MCP Server ha un ruolo distinto: quel server permette agli agenti di sviluppo di interagire con servizi AWS. Qui il punto è portare una richiesta dell'agente verso strumenti privati dell'azienda, con il corretto rapporto di fiducia sul certificato.

Scenario ipotetico: un distributore consulta gli ordini

Immaginiamo un distributore italiano con un gestionale accessibile soltanto alla rete aziendale. Il personale commerciale vuole chiedere a un assistente lo stato delle consegne senza aprire ogni volta più schermate. Il primo pilota permette soltanto la lettura degli ordini collegati ai clienti assegnati all'utente.

Il gateway raggiunge l'API privata tramite l'architettura prevista. L'API controlla identità e perimetro commerciale, quindi restituisce lo stato. L'assistente distingue un dato aggiornato da uno non disponibile e non completa una risposta usando supposizioni. Se l'ordine non appartiene al perimetro dell'utente, la richiesta viene rifiutata anche quando il modello ne conosce il numero.

Questo è uno scenario ipotetico. La prova deve includere clienti omonimi, ordini non accessibili, identificativi inesistenti e gestionale indisponibile. Il successo è una risposta corretta e autorizzata, con una fonte riconoscibile. Non viene assunto alcun risparmio di tempo né un miglioramento misurato: sono risultati da osservare nel progetto, non proprietà automatiche del collegamento.

Scenario ipotetico: un manutentore prepara le richieste d'intervento

Consideriamo una PMI di manutenzione che raccoglie richieste da operatori sul territorio. L'agente aiuta a preparare una scheda con impianto, problema segnalato e documenti pertinenti. Il sistema interno usa certificati della CA aziendale e non è esposto pubblicamente. Il supporto TLS privato può essere rilevante per raggiungerlo nel disegno scelto.

La prima versione prepara una bozza. L'operatore controlla impianto e priorità prima della registrazione definitiva. Le descrizioni ricevute possono essere incomplete o contenere istruzioni estranee: vengono trattate come contenuto della richiesta, senza diventare permessi per cercare altri dati. L'inserimento nel gestionale avviene soltanto attraverso una funzione ristretta.

Anche questo caso è ipotetico. Il test deve verificare soprattutto l'associazione all'impianto corretto e la gestione delle informazioni mancanti. Un agente che chiede un chiarimento può essere preferibile a uno che completa rapidamente una scheda sbagliata. Il collegamento privato protegge il percorso, mentre la correttezza della scheda dipende da dati, regole e controllo del personale.

Che cosa provare con certificati e rete?

Apri la traccia per il collaudo del target privato

Verifica il target corretto, la CA attendibile, il percorso di rete e la regione adottata. Prova un certificato non attendibile, un endpoint irraggiungibile e un'identità priva di permesso. Controlla che nessun errore venga aggirato disabilitando la verifica TLS. Conserva l'esito tecnico e quello applicativo separatamente.

Serve poi un piano per la rotazione dei certificati. Quando cambia la CA o scade un certificato, il sistema deve rilevare il problema e indirizzarlo al responsabile. Una configurazione funzionante il giorno del test non prova che l'integrazione sia mantenibile. L'inventario dovrebbe includere dipendenze, proprietari e procedura di aggiornamento.

La disponibilità regionale non va estesa a tutto AWS: occorre la presenza congiunta dei servizi richiesti. Anche account e architettura possono richiedere verifiche specifiche. La fonte operativa resta la documentazione AgentCore Gateway, insieme all'annuncio del supporto. Non viene qui affermata disponibilità universale o automatica in una regione italiana.

Quando serve ancora un connettore dedicato?

Ridurre la necessità di intermediari per il collegamento privato non elimina ogni funzione di integrazione. Un connettore può ancora servire per trasformare dati, applicare regole aziendali, gestire compatibilità con un software legacy o offrire operazioni più ristrette di quelle originarie. Il criterio è la responsabilità che deve svolgere, non il numero di componenti da rimuovere.

Se il gestionale non dispone di API, automatizzare l'interfaccia grafica è un altro percorso. Le nuove classi di Claude SDK per browser e computer use riguardano quel tipo di interazione. Un accesso tramite API controllata e un'azione sulla schermata hanno fragilità diverse: il secondo dipende anche da layout, sessioni e comportamento dell'interfaccia.

Il medesimo collegamento privato può diventare uno strumento di un agente vocale, come nel caso di Amazon Nova Sonic. Cambia il canale della richiesta, ma restano identità e autorizzazioni. Una voce naturale non deve ottenere più diritti di un utente autenticato attraverso una pagina web.

Quali errori evitare nell'accesso al gestionale?

Il primo è confondere “interno” con “autorizzato”. Una rete protetta può ospitare informazioni che l'agente non dovrebbe vedere. Il secondo è risolvere un problema di certificato spegnendo la verifica TLS. Il terzo è condividere una credenziale amministrativa per tutte le richieste, perdendo la possibilità di distinguere utenti e responsabilità.

Un altro errore è ritentare scritture senza sapere se la prima chiamata abbia avuto effetto. Un timeout non dimostra che il gestionale non abbia registrato l'operazione. La procedura deve usare identificativi e controlli che permettano di riconoscere una richiesta già eseguita. Altrimenti l'automazione può creare interventi, ordini o comunicazioni duplicati.

Infine, è fragile conservare nei log l'intera risposta del gestionale quando bastano stato ed esito. Le tracce devono permettere diagnosi e responsabilità senza diventare una copia indiscriminata dei dati. La revisione dovrebbe comprendere anche ciò che vede il personale di supporto, perché l'accesso ai log è parte del progetto.

Come mantenere l'integrazione quando cambia il gestionale?

Un'API interna può cambiare campi, codici di stato o significato delle risposte. Il collegamento TLS può continuare a funzionare mentre il contenuto diventa incompatibile con lo strumento dell'agente. Per questo il collaudo deve distinguere disponibilità della rete e correttezza del contratto applicativo. Una chiamata riuscita non dimostra che la risposta sia utilizzabile.

Conviene conservare esempi di richieste ammesse e delle relative risposte attese. Quando il fornitore del gestionale aggiorna il software, questi casi aiutano a riconoscere una differenza significativa. Un campo mancante non dovrebbe essere sostituito dal modello con un valore plausibile: il sistema deve trattarlo come un limite e scegliere il percorso previsto.

Lo stesso principio vale per le autorizzazioni. Se una persona cambia ruolo o lascia l'azienda, l'agente non dovrebbe continuare a operare con diritti associati alla vecchia situazione. La revoca e la revisione degli accessi devono seguire i processi del personale, non dipendere da una correzione manuale del prompt. Un'identità tecnica condivisa richiede particolare attenzione al perimetro delle richieste.

Anche la procedura di assistenza va verificata. Chi riceve un errore deve capire se manca una risorsa, è scaduta una credenziale o il servizio non è raggiungibile. Il messaggio rivolto all'utente può restare semplice, mentre la traccia tecnica aiuta il responsabile a intervenire. Nessuno dei due dovrebbe includere segreti o dati eccedenti il problema.

Infine, va prevista la disattivazione del collegamento. Un pilota può rivelare che l'API non offre garanzie sufficienti o che il processo richiede più revisione del previsto. In quel caso il personale deve poter proseguire con una procedura conosciuta, senza perdere le richieste già raccolte. La reversibilità è una proprietà utile anche dopo l'avvio.

Quale risultato chiedere al primo pilota?

Un pilota utile deve dimostrare un percorso completo: richiesta autorizzata, chiamata al target corretto, risposta limitata, gestione di un errore e risultato comprensibile al personale. La prima estensione dovrebbe arrivare dopo aver verificato i confini, non appena l'agente produce una risposta convincente.

L'azienda dovrebbe ricevere anche una mappa delle dipendenze e un elenco di responsabilità. Chi mantiene l'API? Chi ruota i certificati? Chi può revocare l'accesso? Chi controlla una scrittura contestata? Queste risposte rendono concreta la manutenzione. Il costo va stimato sull'architettura completa, senza confondere una nuova funzione cloud con un progetto pronto a costo fisso.

Se il tuo gestionale deve restare privato, un percorso di automazione dei processi aziendali può iniziare da una consultazione delimitata e verificabile. Da lì si decide quali azioni aggiungere, con quale identità e con quale controllo prima che diventino impegni reali per l'azienda.