AWS annuncia tre funzioni di governance per Bedrock AgentCore: temporal policies basate su Dogwood (un linguaggio di policy open source per agenti AI), rate limiting sul gateway e visibilità tramite CloudWatch.

Le temporal policies sono regole con stato: valutano l’autorizzazione di un agente in base alla sua storia di sessione, non solo all’azione singola. Puoi forzare l’ordine di un workflow (prima recuperi i dati, poi scrivi), bloccare la fabbricazione di dati, mettere un tetto all’esposizione finanziaria e richiedere approvazione umana per le azioni ad alto valore.

Il rate limiting protegge i target: definisci limiti di richieste, token e connessioni per utente e per destinazione, con regole basate sull’identità IAM o sui claim JWT. Se un agente entra in loop e inizia a chiamare un modello o un tool senza fermarsi, il gateway lo blocca prima che bruci il budget.

La visibilità passa da CloudWatch: metriche su cosa fa l’agente, quanto spende, dove si rompe.

Perché ti riguarda. Se stai mettendo agenti in produzione, il modello sa già fare il compito. Quello che manca è impedire che faccia la cosa sbagliata al momento sbagliato, e sapere quanto ti costa prima che te ne accorga. Come raccontavamo ieri per il GA di AgentCore, il centro di gravità si sposta dalla chat al runtime. Queste tre feature sono la governance che rende quel runtime usabile fuori dalla demo.

Il pattern è lo stesso che Cloudflare ha descritto tre giorni fa con il suo modello zero-trust per agenti: credenziali temporanee, gateway comportamentale, tetto di spesa. AWS chiude lo stesso cerchio sul suo stack.

Nel dettaglio

Cosa c’era prima.

Fino a ieri, controllare un agente su Bedrock significava valutare ogni azione singola. Potevi permettere o negare una chiamata a un tool, ma non potevi dire: «questo agente può chiamare lo strumento di scrittura solo dopo aver chiamato quello di lettura». L’autorizzazione era senza stato. L’agente poteva fare i passi nell’ordine sbagliato, ripetere la stessa azione all’infinito, accumulare costo senza che nessun controllo lo fermasse a livello di sessione.

Cosa cambia con le temporal policies.

Dogwood è un linguaggio di policy open source, creato per agenti AI. Le temporal policies scritte in Dogwood tengono traccia dello stato della sessione: ogni volta che l’agente vuole fare qualcosa, la policy guarda cosa ha fatto finora e decide se l’azione è ammessa.

I casi d’uso dichiarati da AWS sono quattro:

• Sequenziazione dei workflow: l’agente deve completare il passo A prima di poter eseguire il passo B. Una regola deterministica, non un suggerimento nel prompt.
• Prevenzione della fabbricazione: blocca l’agente se cerca di produrre dati senza averli prima recuperati da una fonte verificata.
• Tetto finanziario: metti un limite di spesa per sessione. Quando l’agente lo raggiunge, non può fare altre chiamate a pagamento.
• Approvazione umana: per le azioni ad alto valore (un bonifico, una modifica al database di produzione, l’invio di un’email a una lista), la policy ferma l’agente e aspetta il sì di una persona.

Cosa cambia con il rate limiting.

Il gateway di AgentCore sta fra l’agente e i modelli o tool che chiama. Con il rate limiting, configuri limiti per utente e per destinazione: numero massimo di richieste, token consumati, connessioni simultanee. I limiti sono ancorati all’identità (IAM o claim JWT), quindi puoi dare tariffe diverse a utenti o ruoli diversi.

Il caso reale: un agente ha un bug, entra in un loop e chiama lo stesso endpoint cento volte al secondo. Senza rate limiting, il downstream crolla e il conto sale. Con il rate limiting, il gateway throttia le chiamate e l’agente si ferma.

Cosa cambia con CloudWatch.

Le metriche su comportamento, costo ed errori degli agenti finiscono in CloudWatch. Per chi usa già AWS, niente strumento nuovo da imparare: gli allarmi e le dashboard che già usi per il resto dell’infrastruttura coprono anche gli agenti.

Limiti di quello che si sa ora.

I tre post del blog AWS sono annunci di prodotto con esempi di configurazione, ma senza numeri su latenza o overhead delle temporal policies. Dogwood è open source, ma è nuovo: l’ecosistema di chi lo usa e lo stressa fuori dai demo è ancora da formare. Il rate limiting e le metriche CloudWatch sono feature standard di gateway, quindi il dubbio minore è lì. La domanda vera è quanta frizione aggiungano le temporal policies sul percorso critico dell’agente: ogni azione passa da un controllo con stato, e su volumi alti questo conta. AWS non pubblica benchmark. Per chi valuta, la cosa onesta è provarlo sul proprio carico prima di fidarsi dei tempi.