AWS Impone Limiti Rigidi agli Agenti AI mentre si Intensifica la Competizione sulla Sicurezza tra Amazon e Google

AWS ha introdotto limiti applicabili agli agenti AI, nonostante il rischio che aggressori o dati avvelenati possano manipolarne il ragionamento. La mossa rende più serrata la competizione tra Amazon e Google su quale cloud possa collegare in sicurezza gli agenti a sistemi aziendali di valore.

Amazon Bedrock AgentCore Policy verifica le azioni sugli strumenti richieste da un agente prima che raggiungano il servizio sottostante. Un agente manipolato può comunque generare una richiesta pericolosa, ma la richiesta dovrebbe fallire quando entra in conflitto con una policy esterna.

Questa distinzione conta perché i filtri sui prompt non hanno mai fornito un confine di sicurezza completo. I modelli elaborano istruzioni e dati non attendibili attraverso gli stessi meccanismi probabilistici. AWS ora considera il modello un decisore non attendibile, anziché l'autorità finale.

Google Cloud e Microsoft stanno seguendo la stessa direzione generale attraverso i rispettivi controlli su identità, gateway e flusso delle informazioni. La competizione emergente non si limita più alla qualità dei modelli. I provider cloud devono dimostrare che gli agenti possono agire senza ereditare un accesso illimitato a ogni sistema collegato.

AWS Sposta l'Autorizzazione al di Fuori dell'Agente

AWS separa ciò che un agente vuole fare da ciò che l'infrastruttura gli consente di fare.

Le policy in Amazon Bedrock AgentCore creano un confine protettivo attorno alle interazioni tra agenti e strumenti. Il servizio intercetta le richieste instradate attraverso un AgentCore Gateway, quindi valuta ogni richiesta prima di consentire l'invocazione dello strumento.

Un AgentCore Gateway collega gli agenti ad API, funzioni e altri strumenti attraverso un'interfaccia gestita. Il motore delle policy si colloca accanto a questa connessione, anziché all'interno del prompt dell'agente o del codice di orchestrazione.

Questa collocazione cambia il modello di sicurezza. Un system prompt potrebbe dire a un agente di non recuperare mai record riservati dei clienti. Tuttavia, un prompt injection può convincere il modello a ignorare tale istruzione o a interpretarla diversamente.

Un motore di autorizzazione esterno non ha bisogno dell'accordo del modello. Valuta l'azione proposta usando regole esplicite, identità autenticata, parametri dello strumento e il contesto della richiesta disponibile.

AWS utilizza Cedar, il suo linguaggio open source per l'autorizzazione, per esprimere queste regole. Una policy Cedar identifica il principal che effettua una richiesta, l'azione richiesta, la risorsa protetta e le eventuali condizioni necessarie.

Il servizio segue una semantica di negazione predefinita. Un'azione non riceve alcun accesso a meno che una policy non lo consenta esplicitamente. Un divieto corrispondente prevale inoltre su qualsiasi autorizzazione più ampia che altrimenti potrebbe consentire la richiesta.

AWS spiega questi meccanismi nella sua guida alle policy di AgentCore. La guida afferma che ogni richiesta dell'agente instradata viene valutata prima che sia concesso l'accesso allo strumento.

Gli sviluppatori possono scrivere Cedar direttamente oppure descrivere i requisiti in linguaggio naturale. Il servizio di authoring in linguaggio naturale traduce tali requisiti in policy Cedar candidate.

AWS afferma che il servizio convalida le policy generate rispetto allo schema degli strumenti del gateway. Verifica inoltre la presenza di regole apparentemente troppo permissive, troppo restrittive o impossibili da soddisfare.

Questo processo di generazione non rende sicuri requisiti vaghi. AWS avverte che le policy in linguaggio naturale richiedono comunque formulazioni precise e non ambigue. I team di sicurezza devono esaminare il Cedar risultante anziché trattare la policy generata come codice indiscutibile.

Il modello che crea una policy è separato anche dal meccanismo che la applica. Una volta distribuita, la policy formale controlla la decisione di autorizzazione invece di chiedere un parere a un altro modello.

Si consideri un agente interno di assistenza con strumenti per leggere gli account ed emettere rimborsi. Un'azienda potrebbe consentire a ogni addetto all'assistenza di leggere gli account assegnati, permettendo però solo ai supervisori di approvare rimborsi più elevati.

Se un'email contiene istruzioni malevole che richiedono un rimborso, l'agente potrebbe tentare l'operazione. Il gateway può comunque rifiutarla quando il dipendente autenticato non dispone del ruolo richiesto o l'importo supera quanto previsto dalla policy.

La richiesta negata non deve mai raggiungere il sistema di pagamento. Questo risultato è più solido che chiedere all'agente di riconoscere ogni variante di un'istruzione malevola.

AgentCore Policy è generalmente disponibile in 13 regioni AWS, secondo la documentazione di rilascio di AWS. Le policy centralizzate possono applicarsi in modo coerente a più agenti e strumenti collegati attraverso gateway associati.

L'integrazione con CloudWatch registra le decisioni di autorizzazione per il monitoraggio e gli audit. Tali record offrono ai team di sicurezza un resoconto più chiaro delle azioni richieste, consentite o negate dagli agenti.

Il cambiamento immediato è quindi architetturale, non cosmetico. AWS colloca un checkpoint deterministico tra il comportamento incerto del modello e i sistemi aziendali con conseguenze rilevanti.

Perché il Prompt Injection Cambia la Competizione tra Amazon e Google

La competizione cloud tra Amazon e Google dipende ora dal contenimento degli agenti compromessi, non soltanto dal miglioramento delle loro risposte.

Gli agenti AI diventano utili quando possono recuperare informazioni private, chiamare API, inviare messaggi o modificare record. Le stesse autorizzazioni determinano il danno possibile dopo una manipolazione.

Il prompt injection inserisce istruzioni ostili nei contenuti elaborati da un modello. L'iniezione diretta deriva da una richiesta dell'utente, mentre quella indiretta può nascondersi in siti web, documenti, email o risposte degli strumenti.

Un agente che ricerca un fornitore potrebbe incontrare istruzioni incorporate in una pagina web. Tali istruzioni potrebbero dirgli di recuperare file riservati e inviarli attraverso un altro strumento collegato.

Un filtro dei contenuti potrebbe rilevare uno schema d'attacco noto. Potrebbe anche non riconoscere una formulazione insolita, un comando codificato o una sequenza distribuita su più interazioni.

Il problema di fondo va oltre i prompt malevoli. Un modello può allucinare un'azione, fraintendere una regola aziendale o combinare strumenti singolarmente accettabili in un flusso di lavoro inaccettabile.

OWASP descrive questa condizione come eccessiva autonomia. Il rischio emerge quando un LLM riceve funzionalità o autorizzazioni sufficienti a causare effetti dannosi dopo un output inatteso.

L'autorizzazione limita il raggio d'impatto risultante. Il sistema presume che un agente prima o poi prenderà una decisione errata, quindi impedisce che tale decisione diventi un'azione senza restrizioni.

Questo approccio richiama pratiche consolidate di sicurezza cloud. Le applicazioni dovrebbero ricevere solo le autorizzazioni necessarie per un'attività, mentre le operazioni sensibili dovrebbero affrontare controlli aggiuntivi.

Gli agenti complicano questo principio perché selezionano gli strumenti dinamicamente. Possono anche concatenare molte chiamate, mantenere il contesto tra i passaggi e operare per periodi più lunghi senza supervisione diretta.

Un account di servizio statico con autorizzazioni ampie può quindi diventare una seria passività. L'agente acquisisce di fatto ogni capacità associata a tale credenziale, indipendentemente dall'utente o dall'attività coinvolta.

AWS può collegare le richieste AgentCore a utenti OAuth o entità AWS Identity and Access Management. Le policy possono quindi considerare l'identità dietro una richiesta anziché fare affidamento solo sul ruolo di servizio condiviso dell'agente.

Google affronta lo stesso problema mentre amplia gli agenti basati su Gemini e le connessioni Model Context Protocol. MCP è un'interfaccia standard che consente ai modelli di individuare e invocare strumenti esterni.

Le linee guida di sicurezza MCP di Google raccomandano policy di negazione per l'accesso in produzione, autorizzazioni strettamente circoscritte, sanitizzazione degli input e monitoraggio. Avvertono inoltre che, altrimenti, la sicurezza può dipendere interamente dalla programmazione dell'agente.

Questa convergenza è importante. La competizione tra Amazon e Google si è spesso concentrata sulla disponibilità dei modelli, l'infrastruttura, le piattaforme dati e gli strumenti per sviluppatori. L'autorizzazione degli agenti sta diventando un altro importante criterio di acquisto.

I clienti enterprise raramente distribuiscono un agente come chatbot isolato. Vogliono agenti collegati a database, repository di codice, piattaforme di assistenza, console cloud e archivi interni di conoscenza.

Ogni connessione crea sia utilità sia esposizione. Un provider cloud che rende semplice il collegamento ma debole l'autorizzazione trasferisce il rischio operativo al cliente.

AWS sta posizionando AgentCore Policy come livello di applicazione riutilizzabile tra framework e modelli. Gli sviluppatori possono usare AgentCore con agenti realizzati mediante diversi framework di orchestrazione diffusi.

Questa apertura consente ad AWS di sostenere che le policy di sicurezza dovrebbero restare stabili anche quando un'azienda cambia modello. Un'organizzazione potrebbe sostituire un foundation model senza riscrivere ogni regola di autorizzazione.

Google può sostenere un argomento analogo attraverso i suoi controlli di identità cloud, Model Armor e autorizzazioni a livello di risorsa. Il suo vantaggio è la vicinanza a Google Workspace, Gemini e a un'ampia piattaforma dati.

Microsoft aumenta la pressione attraverso l'identità Entra, Copilot e il proprio stack di sviluppo per agenti. Il mercato sta diventando una competizione a tre su chi controlla il confine tra ragionamento AI ed esecuzione aziendale.

Per gli acquirenti, la questione rilevante tra Amazon e Google non è quale modello rifiuti sempre un prompt malevolo. Nessun fornitore può promettere credibilmente un rifiuto perfetto in ogni combinazione di input e strumenti.

La domanda migliore è cosa accade dopo che il rifiuto fallisce. Una piattaforma sicura dovrebbe limitare gli strumenti, i record, i parametri, le destinazioni e le sequenze di azioni disponibili per l'agente compromesso.

Le Strategie di Sicurezza di Amazon e Google si Incontrano al Confine degli Strumenti

AWS, Google e Microsoft convergono sull'applicazione deterministica, ma organizzano tale applicazione in modo diverso.

AWS colloca AgentCore Policy direttamente nel percorso del gateway. Ogni richiesta coperta da agente a strumento raggiunge il motore delle policy prima che l'invocazione richiesta proceda.

Cedar offre ad AWS un linguaggio formale che i team possono ispezionare, convalidare e analizzare. AWS ha utilizzato concetti Cedar anche oltre gli agenti, contribuendo a collegare l'autorizzazione degli agenti a pratiche consolidate di sicurezza applicativa.

I ricercatori di sicurezza dell'azienda adottano un'assunzione netta sul modello stesso. La loro analisi di sicurezza Cedar afferma che le organizzazioni dovrebbero trattare un LLM come attore non attendibile all'interno di un modello di difesa in profondità.

Ciò non significa che il modello sia malevolo. Significa che il sistema di autorizzazione non può dipendere da un comportamento prevedibile del modello, poiché il modello è probabilistico e suscettibile al contesto manipolato.

Le linee guida pubblicate da Google sottolineano attualmente controlli stratificati attorno ai server MCP e alle risorse Google Cloud. Tali controlli includono policy di negazione, credenziali ristrette, ambienti di test separati, input sanitizzati e accesso alla produzione limitato.

Google raccomanda inoltre di impedire agli strumenti di lettura-scrittura di raggiungere le risorse di produzione, salvo quando il flusso di lavoro lo richieda. Le funzionalità di ripristino restano importanti perché anche un'azione autorizzata può produrre un risultato indesiderato.

La differenza pratica può emergere nell'esperienza degli sviluppatori. AWS offre un motore di policy AgentCore dedicato, con valutazione basata su Cedar presso il suo gateway gestito.

Google può attingere a Cloud IAM maturo e a policy specifiche dei prodotti. Tuttavia, gli sviluppatori devono comunque assicurarsi che ogni percorso di strumenti rilevante passi effettivamente attraverso il controllo previsto.

Questa avvertenza vale anche per AWS. AgentCore Policy regola il traffico instradato attraverso un AgentCore Gateway associato. Un agente con un altro percorso di esecuzione potrebbe aggirare quel particolare punto di controllo.

Per esempio, una policy potrebbe bloccare un'operazione S3 tramite uno strumento MCP gestito. La restrizione non coprirebbe automaticamente uno strumento shell separato in grado di eseguire un comando equivalente.

Le revisioni dell'architettura devono quindi elencare le capacità, non soltanto gli strumenti nominati. I team di sicurezza devono chiedersi se un agente possa raggiungere la stessa risorsa tramite un SDK, la riga di comando, un browser, una funzione o un agente secondario.

Microsoft sta sviluppando un'altra variante attraverso il controllo del flusso di informazioni. Il suo middleware FIDES etichetta i contenuti in base a integrità e riservatezza, quindi trasporta tali etichette attraverso le chiamate agli strumenti.

Il modello di sicurezza FIDES di Microsoft può impedire che contenuti non attendibili influenzino un'operazione sensibile. Può inoltre limitare il flusso di dati privati verso una destinazione pubblica.

Questo approccio affronta una debolezza dell'autorizzazione per singola azione. Una ricerca nel database potrebbe essere consentita, così come l'invio di un'email. Il comportamento pericoloso emerge quando risultati di query privati confluiscono in un'email esterna.

AWS ha esteso le proprie policy verso una valutazione consapevole della sessione. I controlli temporali possono esaminare le azioni recenti di un agente invece di giudicare ogni richiesta come un evento isolato.

Questa direzione è importante perché gli aggressori possono suddividere un obiettivo dannoso in più passaggi dall'apparenza legittima. Una sequenza può rivelare un rischio che nessuna singola azione espone.

Un agente potrebbe prima leggere un portafoglio riservato, poi calcolare un riepilogo e infine tentare una trasmissione esterna. Ogni chiamata a uno strumento può apparire valida senza considerare la traiettoria che le collega.

Per i clienti che confrontano i progetti di sicurezza di Amazon e Google, la copertura conta più della terminologia. Un linguaggio di policy formale offre poca protezione quando percorsi di esecuzione ad alto rischio restano fuori dall'applicazione dei controlli.

Anche la propagazione dell'identità è importante. Il motore delle policy necessita di informazioni affidabili su utente, workload, risorsa, azione e contesto aziendale pertinente.

Un'identità generica di “agente” è insufficiente quando l'agente serve molti dipendenti. Può concedere a ogni utente il set massimo di autorizzazioni dell'agente e cancellare la responsabilità garantita dai normali controlli di accesso.

Le organizzazioni dovrebbero preservare l'identità umana o del workload alla base di ogni richiesta delegata. Dovrebbero inoltre assegnare all'agente una propria identità limitata, invece di nasconderlo dietro una credenziale condivisa.

Questa separazione aiuta a rispondere a due domande distinte. La prima chiede se l'utente possa richiedere l'azione. La seconda chiede se questo agente possa eseguire quell'azione tramite questo specifico strumento.

Le policy centralizzate riducono inoltre l'incoerenza tra i team. Senza di esse, ogni sviluppatore può implementare l'autorizzazione all'interno dei prompt, di middleware personalizzati o di singoli gestori degli strumenti.

Questi controlli dispersi diventano difficili da sottoporre ad audit. Inoltre, divergono man mano che gli agenti acquisiscono nuovi strumenti, modelli e rami del workflow.

Un gateway condiviso non può sostituire ogni autorizzazione a livello di risorsa. Può offrire un punto coerente in cui le organizzazioni applicano le policy prima che l'intento dell'agente raggiunga i servizi downstream.

La policy è forte solo quanto la sua copertura

AgentCore Policy riduce il rischio, ma non dimostra che un agente ospitato su AWS sia sicuro.

Il servizio controlla le richieste che passano attraverso il gateway configurato e il relativo motore di policy. Non può governare strumenti, credenziali o percorsi di rete che gli sviluppatori lasciano al di fuori di questo perimetro.

Questo crea un problema di copertura. Un team di sicurezza potrebbe ritenere di aver bloccato un'azione pericolosa mentre uno strumento alternativo offre un'altra via verso la stessa risorsa.

Autorizzazioni IAM troppo ampie possono aggravare questa lacuna. Se il ruolo di runtime di un agente può chiamare direttamente i servizi, le restrizioni del gateway devono essere abbinate a policy sulle risorse che bloccano i percorsi non autorizzati.

Anche la progettazione delle policy resta difficile. La creazione in linguaggio naturale riduce la barriera sintattica, ma non risolve requisiti aziendali vaghi o presupposti di sicurezza mancanti.

“Consentire agli analisti di visualizzare i report appropriati” non è una regola di autorizzazione precisa. L'organizzazione deve definire quali analisti, report, classificazioni, regioni, clienti e condizioni operative siano considerati appropriati.

Il Cedar generato richiede revisione, test e controllo delle modifiche. I team dovrebbero testare approvazioni previste, dinieghi previsti, richieste malformate, contesto mancante e combinazioni di parametri deliberatamente avversarie.

Una policy che nega tutto provoca un fallimento operativo. Una regola che consente silenziosamente tutto crea il problema opposto. Entrambi gli esiti possono apparire sintatticamente validi.

Gli sviluppatori devono anche considerare il contesto di autorizzazione fornito dall'agente. Gli attributi sensibili per la sicurezza dovrebbero provenire da token di identità attendibili, metadati delle risorse o infrastruttura controllata.

Al modello non dovrebbe essere consentito dichiarare che una transazione è a basso rischio o che un documento è pubblico. Queste affermazioni richiedono verifica al di fuori del processo di ragionamento del modello.

I log di audit introducono un altro obbligo. Registrare ogni decisione aiuta le indagini, ma i team devono monitorare attivamente i record e preservare un contesto utile.

Un'azione negata può indicare un controllo di sicurezza riuscito. Dinieghi ripetuti potrebbero anche rivelare un workflow compromesso, un errore di policy o un agente che ritenta continuamente un obiettivo vietato.

Anche le azioni consentite meritano attenzione. Un aggressore può abusare di autorizzazioni singolarmente legittime, specialmente quando le policy non considerano la cronologia della sessione o il movimento dei dati.

L'approvazione umana rimane utile per operazioni irreversibili o ad alto impatto. Tuttavia, una schermata di approvazione può fallire quando l'agente fornisce una descrizione fuorviante dell'azione richiesta.

L'interfaccia dovrebbe presentare dettagli attendibili provenienti dall'effettiva richiesta allo strumento. I revisori necessitano della destinazione, della risorsa, dei parametri, della classificazione dei dati e dell'effetto previsto.

I team di sicurezza devono anche difendere il piano di amministrazione delle policy. Un agente non dovrebbe essere in grado di modificare le proprie regole, associare un motore di policy più debole o ottenere credenziali con accesso più ampio.

La separazione dei compiti aiuta in questo caso. Gli sviluppatori possono proporre modifiche alle policy, mentre i responsabili della sicurezza le revisionano e distribuiscono attraverso workflow controllati.

La stessa disciplina si applica ai sistemi di conoscenza interni. I team che costruiscono una base di conoscenza ricercabile dovrebbero preservare le autorizzazioni dei documenti prima di esporre tali contenuti a un agente.

Il recupero delle informazioni dovrebbe filtrare i record in base all'autorizzazione dell'utente richiedente. Il modello dovrebbe ricevere solo il sottoinsieme di informazioni a cui l'utente potrebbe accedere direttamente.

Questo design previene una modalità di guasto critica. Anche un modello manipolato con successo non può rivelare informazioni che non sono mai entrate nel suo contesto accessibile.

Le organizzazioni dovrebbero evitare di riporre tutta la fiducia nel rilevamento della prompt injection. Il rilevamento aggiunge una difesa utile, ma attacchi sconosciuti e istruzioni dall'aspetto innocuo possono eludere i classificatori.

AWS supporta Bedrock Guardrails a livello di policy per valutare input e output del gateway. Questa funzionalità integra l'applicazione di Cedar anziché sostituirla.

La differenza è semplice. Un guardrail stima se un contenuto appare pericoloso, mentre l'autorizzazione decide se un'operazione richiesta è consentita.

Il rilevamento probabilistico e l'applicazione deterministica risolvono problemi diversi. Combinarli riduce la superficie d'attacco senza fingere che uno dei due livelli intercetti ogni errore.

La corsa alla sicurezza tra Amazon e Google premierà i fornitori che rendono difficile aggirare questi livelli. Le affermazioni di marketing su agenti sicuri contano meno di una copertura di controllo dimostrabile.

I clienti dovrebbero verificare tali affermazioni con esercitazioni di red team che coinvolgano injection indirette, strumenti compromessi, percorsi di esecuzione alternativi e movimento dei dati in più passaggi.

Dovrebbero inoltre verificare il comportamento in caso di errore. Una chiamata a uno strumento negata deve fermare l'operazione protetta senza esporre dettagli sensibili tramite errori o percorsi di fallback.

AWS ha stabilito un modello predefinito più solido collocando le policy al di fuori del codice dell'agente. La domanda restante è se i clienti configureranno con uguale attenzione le identità e i percorsi circostanti.

Cosa dovrebbero osservare ora gli acquirenti enterprise

La prossima fase metterà alla prova la copertura delle policy, la consapevolezza della sessione e la portabilità tra piattaforme di agenti concorrenti.

Il primo segnale è la rapidità con cui i clienti adotteranno policy temporali. Le regole per singola richiesta funzionano bene per restrizioni chiare, ma molti attacchi contro gli agenti emergono attraverso sequenze di azioni autorizzate.

La valutazione temporale può rilevare che un agente ha letto dati sensibili prima di tentare un trasferimento esterno. Può inoltre richiedere un'approvazione aggiuntiva dopo una particolare sequenza di operazioni.

La parte difficile riguarda lo stato e l'interpretazione. I sistemi devono tracciare una cronologia sufficiente a riconoscere traiettorie pericolose senza bloccare workflow ordinari o aggiungere una latenza eccessiva.

Gli acquirenti dovrebbero cercare documentazione tecnica pubblica che descriva esattamente quanta cronologia di sessione venga valutata. Dovrebbero inoltre chiedere come lo stato venga isolato tra utenti, agenti e attività simultanee.

Il secondo segnale è il modo in cui Google e Microsoft espongono controlli equivalenti attraverso le loro piattaforme di agenti gestite. Tutti e tre i fornitori riconoscono che le sole istruzioni nei prompt non possono proteggere i sistemi connessi.

La risposta di Google sarà importante perché gli agenti Gemini possono trovarsi vicini ai contenuti di Workspace, ai dati cloud e all'infrastruttura per sviluppatori. Esistono già robuste autorizzazioni sulle risorse, ma una composizione specifica per gli agenti resta essenziale.

Microsoft può combinare l'identità Entra con Copilot, Agent Framework ed etichette di flusso delle informazioni. Il suo vantaggio dipenderà dall'applicazione coerente dei controlli tra strumenti Microsoft e di terze parti.

Il confronto tra Amazon e Google dovrebbe concentrarsi sui percorsi end-to-end. Gli acquirenti necessitano di prove che la policy segua un'azione dall'identità dell'utente, passando per il ragionamento dell'agente e l'esecuzione tramite gateway, fino all'accesso finale alla risorsa.

Il terzo segnale è il testing di sicurezza indipendente. La documentazione dei fornitori descrive il comportamento previsto, mentre i red team rivelano percorsi mancanti, identità confuse, impostazioni predefinite non sicure e combinazioni di strumenti inattese.

I test dovrebbero includere una pagina web dannosa, un ticket di supporto avvelenato, una risposta MCP compromessa e un documento ostile all'interno di un repository approvato. Ogni fonte può trasportare istruzioni indirette nel contesto di un agente.

I ricercatori dovrebbero inoltre testare se gli agenti possano trasformare richieste vietate in azioni tecnicamente differenti. Un'esportazione bloccata potrebbe diventare un caricamento tramite browser, un comando shell, un messaggio codificato o una richiesta a un altro agente.

I risultati determineranno se le policy esterne producano un contenimento significativo oppure soltanto un ulteriore livello di configurazione. Le prove più solide verranno da attacchi che modificano il comportamento del modello ma non riescono comunque ad attraversare i confini dell'autorizzazione.

Le imprese non devono attendere tali risultati prima di migliorare la propria architettura. Possono iniziare censendo ogni agente, strumento, credenziale, fonte di dati e destinazione in uscita.

A ogni strumento dovrebbe essere assegnato l'ambito d'azione più ristretto possibile. L'accesso in sola lettura dovrebbe restare separato da modifica, eliminazione, condivisione esterna o esecuzione finanziaria.

I team dovrebbero rimuovere le credenziali permanenti quando può funzionare una delega a breve durata. Dovrebbero preservare l'identità dell'utente attraverso le chiamate agli strumenti e registrare sia le operazioni tentate sia quelle completate.

Le azioni ad alto impatto dovrebbero richiedere un contesto di approvazione affidabile. I team di sicurezza dovrebbero testare regolarmente percorsi alternativi verso risorse protette invece di convalidare soltanto il percorso previsto tramite gateway.

Per la decisione cloud di Amazon Google, i benchmark dei modelli non sono più sufficienti. Gli acquirenti dovrebbero confrontare il comportamento default-deny, la propagazione dell'identità, l'analisi delle policy, il livello di dettaglio dell'audit, i controlli sulle sessioni e la copertura dell'enforcement.

Dovrebbero inoltre chiedersi come le policy resistano ai cambiamenti di modelli e framework. Un'autorizzazione strettamente legata a una sola implementazione di agente diventa costosa da mantenere e più facile da aggirare durante le migrazioni.

AWS ha fatto una chiara scommessa architetturale. Presuppone che il ragionamento degli agenti rimarrà manipolabile, quindi ne limita le conseguenze tramite controlli deterministici esterni all'agente.

Questa ipotesi è più credibile della promessa di una perfetta obbedienza del modello. Accetta che si verificheranno errori e attacchi, preservando al contempo un'autorità separata su strumenti e dati.

L'approccio dipende comunque da una configurazione rigorosa. Una policy di gateway restrittiva non può compensare un runtime con privilegi eccessivi, una shell non gestita o dati recuperati prima del filtraggio dell'autorizzazione.

I team aziendali dovrebbero ora testare un flusso di lavoro concreto dall'inizio alla fine. Manipolare l'agente, osservare le azioni richieste e confermare che le operazioni protette falliscano a un confine esterno.

Questo test offre uno standard pratico per Amazon Google e per ogni altra piattaforma di agenti: il modello può essere ingannato, ma l'infrastruttura deve comunque dire no.