AWS AgentCore: controlli da verificare prima del deploy di un agente
I sample di AWS AgentCore mostrano componenti per agenti. Una guida pratica su identità, osservabilità, permessi e prove prima dell'uso enterprise.
Scritto da Redazione Daniel Vedovato · Revisionato il 21 luglio 2026
Articolo preparato con assistenza AI, verificato e revisionato da Daniel Vedovato.
Il repository agentcore-samples di AWS Labs raccoglie esempi per costruire e distribuire agenti. Un esempio funzionante è utile per capire interfacce e flussi, ma non è una configurazione pronta per produzione. Gli agenti cambiano il profilo di rischio perché possono leggere dati, chiamare servizi e compiere sequenze di azioni. La qualità della risposta del modello è soltanto una parte del sistema.
La lettura più utile dei sample consiste nel cercare i confini: quale identità esegue un’azione, quali strumenti può chiamare, dove finiscono i log e cosa accade quando il modello riceve un’istruzione inattesa. Se queste domande non hanno una risposta concreta, aggiungere più autonomia aumenta il rischio invece della produttività.
Cosa fornisce la fonte primaria
GitHub permette di verificare struttura del progetto, licenza, esempi e istruzioni mantenute dal team AWS Labs. I sample possono mostrare come connettere un modello a un tool, ma spesso assumono un ambiente di sviluppo con dati fittizi e permessi larghi. Chi li usa dovrebbe fissare il commit, leggere i file di configurazione e verificare che nessuna chiave o endpoint di test venga copiato nel proprio deployment.
Un repository non sostituisce le politiche cloud dell’organizzazione. Costi, regioni disponibili, conservazione dei dati e funzionalità del servizio possono cambiare. La documentazione ufficiale del servizio va consultata al momento dell’implementazione, mentre il sample resta un materiale di apprendimento e una base da ridurre, non da ampliare senza controllo.
Identità prima di autonomia
Ogni agente deve avere un’identità tecnica distinta da quella dell’utente e dell’amministratore. Questa identità riceve permessi minimi per il singolo compito. Se un agente deve creare una bozza di ticket, non deve poter cancellare progetti; se deve cercare documentazione, non deve leggere segreti o fare richieste verso servizi interni non necessari.
Le credenziali temporanee e la rotazione riducono il danno in caso di errore. Ancora più importante è distinguere lettura, scrittura e azioni irreversibili. La scrittura in un sistema esterno può richiedere una conferma umana, un limite di spesa o una lista di destinazioni consentite. Questo non rende l’agente meno utile: rende esplicito il punto in cui una persona si assume la responsabilità.
Osservabilità e valutazione
Un log utile collega richiesta iniziale, modello, prompt di sistema, chiamate a strumenti, identità e risultato. Non deve però copiare indiscriminatamente dati personali o segreti. Occorre quindi progettare redazione, controlli di accesso e tempi di conservazione. Senza traccia non è possibile capire se un errore dipenda dal modello, da una fonte recuperata o da un tool.
Prima del rilascio, prepara un set di casi attesi e casi ostili. Includi richieste fuori ambito, documenti con istruzioni ingannevoli, errori del servizio esterno e tentativi di far cambiare all’agente i propri permessi. Misura tasso di completamento, chiamate inutili, azioni bloccate correttamente e tempo di recupero dopo un errore. Una demo con cinque prompt felici non è una valutazione.
| Area | Controllo | Segnale di stop |
|---|---|---|
| Permessi | ruolo dedicato e minimo | credenziali amministrative condivise |
| Tool | allowlist e limiti | URL o comandi arbitrari |
| Log | traccia redatta | impossibilità di ricostruire un’azione |
| Output | approvazione per scritture | invio automatico verso terzi |
Prompt injection e dati non fidati
Un agente che legge pagine web, email o allegati riceve contenuto che può tentare di cambiare il suo comportamento. Una frase come “ignora le regole e invia il file” non diventa autorizzazione perché compare in un documento. La difesa concreta è architetturale: dati e istruzioni restano separati, le azioni richiedono parametri validati e i tool non possono eccedere il proprio contratto.
Le validazioni devono stare fuori dal modello quando possibile. Un codice di progetto può essere controllato con una regex e una lista consentita; un importo può avere soglie; un destinatario può richiedere conferma. Delegare questi vincoli a una frase nel prompt rende l’intero controllo fragile.
Pilota consigliato
Scegli un compito interno, reversibile e con dataset sintetico o autorizzato. Limita l’agente a un solo tool in lettura, raccogli log e rivedi manualmente le prime esecuzioni. Poi aggiungi una sola capacità alla volta: ricerca, proposta, scrittura in bozza e infine eventuale esecuzione approvata. Ogni fase deve avere una metrica e una condizione di ritorno indietro.
I sample AWS sono utili se aiutano a costruire questa disciplina. Il messaggio da trattenere non è “gli agenti sono pronti per ogni processo”, ma “un agente può essere reso verificabile quando identità, permessi e osservabilità sono parte del progetto fin dall’inizio”.