Amazon AWS ripensa Bedrock Guardrails, sostituendo la scansione continua del codice con controlli basati sul rischio
Amazon AWS ha pubblicato sette pratiche per applicare Bedrock Guardrails senza sovraccaricare i flussi di generazione del codice con controlli di sicurezza ripetuti.
Le linee guida rispondono a un conflitto che diventa evidente quando gli assistenti di programmazione superano i piccoli progetti pilota. La scansione continua offre un'ampia copertura, ma output lunghi e sessioni simultanee degli agenti possono esaurire rapidamente la capacità disponibile dei guardrail.
AWS ora raccomanda di controllare i contenuti quando attraversano un confine di fiducia, invece di valutare ogni frammento intermedio. Questi confini includono l'input degli utenti, il codice completato, le chiamate a strumenti pericolose, le scritture di file e i commit nel repository.
Il cambiamento è rilevante anche oltre Bedrock. Claude Code, Kiro, OpenAI Codex e altri agenti di programmazione operano sempre più attraverso sessioni lunghe e in più passaggi. Il loro comportamento non assomiglia a un breve scambio con un chatbot.
Il nuovo modello tratta la convalida della sicurezza come un hook pre-commit. I team continuano a ispezionare il codice prima che diventi persistente o eseguibile, ma evitano di riesaminare ripetutamente contesto invariato e ragionamenti temporanei.
Il compromesso è chiaro. La valutazione selettiva può ridurre latenza, pressione sulle quote e lavoro duplicato. Affida però ai team di ingegneria una maggiore responsabilità nell'identificare ogni confine di fiducia significativo.
Amazon AWS affronta un problema di scalabilità nascosto dai piccoli progetti pilota
Il cambiamento centrale è architetturale: AWS vuole che gli sviluppatori collochino i guardrail attorno alle azioni rilevanti, non a ogni token generato lungo il percorso.
AWS ha pubblicato le sue raccomandazioni il 23 luglio 2026. L'azienda le ha presentate come risposta agli insoliti schemi di throughput creati dagli assistenti di programmazione e dai flussi di sviluppo agentici.
Una breve risposta conversazionale può contenere alcune centinaia di caratteri. AWS afferma che la generazione di codice può produrre da 5.000 a oltre 50.000 caratteri in un singolo output.
Le sessioni di programmazione riutilizzano inoltre prompt di sistema, definizioni degli strumenti, messaggi precedenti e codice esistente. Un guardrail inline può rivalutare gran parte di questo materiale invariato a ogni turno.
Questa ripetizione è facile da non notare durante un progetto pilota. Due sviluppatori che effettuano richieste occasionali potrebbero non raggiungere mai un limite di quota né rilevare un lieve aumento della latenza.
AWS illustra il problema con uno scenario che coinvolge 15 sviluppatori che usano Claude Code tramite Amazon Bedrock. Ogni funzione generata contiene circa 5.000 caratteri.
Con la configurazione di streaming predefinita descritta nelle linee guida AWS, i guardrail valutano l'output ogni 50 caratteri. Questo produce 100 valutazioni per ciascuna funzione.
Se tutti i 15 sviluppatori generano codice contemporaneamente, lo scenario raggiunge 1.500 richieste di valutazione. Tre protezioni configurate moltiplicano inoltre il consumo associato di unità di testo.
Un'unità di testo rappresenta 1.000 caratteri valutati da un tipo di policy. L'elaborazione di 1.000 caratteri rispetto a tre protezioni distinte consuma quindi tre unità di testo.
Le categorie dei filtri dei contenuti funzionano diversamente. Abilitare più categorie all'interno di una policy di filtro dei contenuti conta comunque come una sola unità di policy per ogni blocco di 1.000 caratteri.
La moltiplicazione avviene tra tipi di policy, come filtri dei contenuti, argomenti negati e filtri per informazioni sensibili. Non avviene tra tutte le categorie all'interno di un singolo filtro.
Questa distinzione trasforma la progettazione dei guardrail in un esercizio di pianificazione della capacità. La lunghezza dell'output, la frequenza delle valutazioni, le sessioni simultanee e i tipi di policy attivi influiscono tutti sul carico risultante.
AWS afferma che il team ipotetico incontra risposte ThrottlingException dopo aver ampliato il deployment. I completamenti del codice si bloccano quindi durante lo streaming, anche se il progetto pilota più piccolo sembrava funzionare bene.
L'esempio è illustrativo, non un caso di studio pubblicato su un cliente. Tuttavia, la sua aritmetica mostra perché una configurazione può superare i test funzionali e fallire comunque in condizioni di concorrenza realistiche.
La scansione inline collega un guardrail direttamente all'inferenza del modello tramite API come Converse o InvokeModel. Bedrock valuta quindi l'input e l'output in streaming come parte di tale invocazione.
Questo modello resta utile quando le applicazioni necessitano di una moderazione immediata prima che qualsiasi output raggiunga un utente. Diventa meno efficiente quando un agente produce un'estesa mole di lavoro temporaneo.
Gli agenti di codice possono ispezionare file, ragionare su alternative, rivedere una funzione e scartare bozze precedenti. Scansionare ogni stato intermedio non migliora necessariamente l'artefatto finale.
AWS separa quindi il materiale generato in base alle conseguenze. Il ragionamento temporaneo ha un profilo di rischio, mentre il codice che entra in un repository ne ha un altro.
La proposta non elimina i controlli di sicurezza. Sposta la valutazione completa più vicino ai punti in cui il contenuto può influire su dati, infrastruttura, utenti o sistemi di produzione.
Questo spostamento crea la tensione centrale dell'articolo. Una minore frequenza di valutazione può rendere i guardrail sostenibili su larga scala, ma solo se i team classificano correttamente le azioni rilevanti.
Perché gli assistenti di programmazione mettono sotto pressione la capacità dei guardrail
Gli assistenti di programmazione mettono sotto pressione i sistemi di sicurezza perché combinano output prolissi, contesto ripetuto, concorrenza e azioni autonome in un unico carico di lavoro.
I guardrail dei chatbot tradizionali spesso presumono uno scambio compatto. Un utente invia un prompt, il modello restituisce una risposta e entrambe le parti ricevono un numero limitato di controlli.
Un assistente di programmazione mantiene sessioni più lunghe. Può leggere un repository, generare diverse modifiche candidate, eseguire test, rivedere file e preparare un commit.
I flussi agentici aggiungono più passaggi intermedi. Un ciclo agentico è una sequenza in cui un modello ragiona, chiama strumenti, osserva i risultati e decide cosa fare successivamente.
AWS afferma che un ciclo di questo tipo può includere da cinque a dieci passaggi di ragionamento prima di produrre il codice finale. Valutare ogni passaggio può consumare capacità per contenuti che scompaiono pochi istanti dopo.
Il contesto ripetuto conta altrettanto. Le istruzioni di sistema e gli schemi degli strumenti possono essere ampi, ma in genere rimangono invariati per tutta la sessione.
Una configurazione inline di base potrebbe rieseguire la scansione di tali istruzioni a ogni nuova richiesta. Può anche rivalutare la cronologia della conversazione che una precedente chiamata al guardrail ha già esaminato.
Questo schema crea lavoro ridondante. La capacità di sicurezza aumenta con la quantità di testo elaborato, anche quando gran parte di quel testo non presenta nuove informazioni.
Lo streaming rende più visibile il disallineamento. Con un intervallo di 50 caratteri, una funzione di 5.000 caratteri produce 100 eventi di valutazione.
AWS raccomanda di aumentare l'intervallo a 1.000 caratteri quando i controlli in streaming restano necessari. La stessa funzione produrrebbe allora cinque valutazioni anziché 100.
Un file di 50.000 caratteri passerebbe da 1.000 valutazioni a 50. AWS descrive questa modifica della configurazione come in grado di offrire fino a una riduzione di 20 volte nella frequenza delle valutazioni.
Il risultato non è automaticamente una riduzione di 20 volte del costo totale o della latenza. Gli esiti effettivi dipendono dalle policy abilitate, dalla lunghezza dei contenuti, dalle quote regionali e dal comportamento dell'applicazione.
Tuttavia, il cambiamento di frequenza evidenzia un problema di progettazione più ampio. Una valutazione di 600 caratteri consuma lo stesso limite completo di unità di testo di una valutazione contenente 1.000 caratteri.
I piccoli blocchi possono quindi sprecare capacità inutilizzata. Raggruppare i contenuti vicino ai limiti di 1.000 caratteri consente a ogni unità fatturata o conteggiata nella quota di contenere materiale più utile.
La concorrenza amplifica l'effetto. Gli sviluppatori spesso iniziano a lavorare nello stesso momento, mentre gli agenti automatizzati possono operare continuamente su più repository.
Un flusso che funziona bene per un singolo sviluppatore può creare picchi concentrati in un team. Tali picchi competono con l'inferenza del modello e con altro traffico dell'applicazione.
Questo mette sotto pressione i team di piattaforma, gli ingegneri della sicurezza e gli sviluppatori in modi diversi. I team di piattaforma devono prevedere la capacità, mentre i team di sicurezza devono preservare una copertura significativa.
Gli sviluppatori sperimentano le conseguenze attraverso completamenti ritardati o sessioni fallite. Potrebbero anche cercare soluzioni alternative se un livello di sicurezza interrompe regolarmente la normale programmazione.
AWS sta di fatto chiedendo a questi gruppi di smettere di considerare i guardrail come un unico interruttore. La configurazione corretta dipende dal contenuto, dall'azione e dalla conseguenza in ogni fase.
Questo argomento mette sotto pressione anche i fornitori di assistenti di programmazione. Devono offrire confini degli strumenti osservabili e hook affidabili in cui i clienti possano inserire controlli di policy.
Un assistente chiuso che nasconde le azioni intermedie rende più difficile la valutazione basata sul rischio. Una piattaforma con strumenti espliciti per file, shell, deployment e rete offre punti di controllo più chiari.
Il cambiamento ha implicazioni anche per la memoria organizzativa. I team devono documentare perché esiste ciascun checkpoint e quali policy vi si applicano.
Una base di conoscenza ingegneristica ricercabile può conservare tali decisioni accanto a note architetturali, modelli di minaccia e risultati degli incidenti.
Senza questa documentazione, un'ottimizzazione successiva potrebbe rimuovere un controllo il cui scopo non è più evidente. L'architettura dei guardrail richiede responsabilità, versionamento e revisione come il codice applicativo.
La strategia Bedrock Guardrails sposta i controlli ai confini di fiducia
Amazon Bedrock Guardrails si adatta ora meglio alla generazione di codice quando la valutazione segue le transizioni di fiducia, soprattutto prima che il contenuto diventi persistente o eseguibile.
AWS identifica tre checkpoint principali. I team possono convalidare il nuovo input utente, ispezionare l'artefatto di codice completato ed eseguire un altro controllo prima di salvare o effettuare il commit delle modifiche.
Il primo checkpoint protegge il modello da istruzioni non attendibili. Può rilevare attacchi ai prompt, richieste proibite e informazioni sensibili prima dell'inizio dell'inferenza.
Il secondo checkpoint esamina l'output assemblato. È utile per individuare credenziali, informazioni personali, argomenti negati o contenuti che violano le regole dell'organizzazione.
Il terzo checkpoint agisce come un hook Git pre-commit. Valuta il codice quando sta per entrare in un repository condiviso o diventare eseguibile.
Questa disposizione ricorda pratiche consolidate di garanzia del software. Gli sviluppatori non eseguono ogni linter e scanner di sicurezza dopo ogni carattere digitato.
Eseguono controlli leggeri durante la modifica, poi applicano una convalida più ampia in corrispondenza di commit, build, revisioni e deployment. Ogni fase calibra lo sforzo in base alle conseguenze.
AWS raccomanda l'API standalone ApplyGuardrail per questa architettura. L'API valuta il testo rispetto a un guardrail configurato senza invocare un foundation model.
Secondo la documentazione ApplyGuardrail, i chiamanti etichettano il contenuto come INPUT oppure OUTPUT. Questa distinzione indica a Bedrock quale lato del flusso di lavoro viene valutato.
Un team può convalidare soltanto il messaggio utente più recente come INPUT. Può quindi eseguire l'inferenza del modello senza inviare nuovamente il contesto statico attraverso lo stesso guardrail.
Dopo la generazione, il team può inviare l'artefatto completato come OUTPUT. Questo design separa la valutazione della sicurezza dalla tempistica e dal fornitore dell'inferenza del modello.
Questo disaccoppiamento significa inoltre che Guardrails può valutare testo prodotto al di fuori di Amazon Bedrock. AWS afferma che l'API standalone funziona indipendentemente dal foundation model scelto.
La flessibilità è importante per le organizzazioni che utilizzano più assistenti di programmazione. Un livello di policy condiviso può coprire gli output di modelli diversi senza richiedere integrazioni di inferenza identiche.
AWS raccomanda inoltre la cache basata su hash per i file invariati. Un hash crittografico agisce come un'impronta compatta, consentendo all'applicazione di riconoscere contenuti che hanno già superato la validazione.
Se il file non è cambiato, il flusso di lavoro salta un'ulteriore valutazione. I file modificati ricevono un nuovo hash e tornano al checkpoint appropriato.
La cache deve rimanere legata alla versione esatta del guardrail e alla configurazione delle policy. Un file approvato con una policy precedente non dovrebbe ereditare silenziosamente l'approvazione dopo una modifica delle regole.
La classificazione del rischio fornisce un ulteriore livello. AWS propone valutazioni più approfondite per le policy IAM, il codice che gestisce credenziali, le migrazioni di database e la logica di autenticazione.
Un semplice componente dell'interfaccia utente può ricevere un trattamento più leggero durante la generazione, seguito da un controllo completo prima del commit. L'artefatto deve comunque superare un controllo finale.
Gli strumenti per agenti pericolosi meritano un'attenzione analoga. Scritture su file, esecuzione della shell, modifiche all'infrastruttura e azioni di deployment possono avere conseguenze immediate.
Le ricerche in sola lettura o l'evidenziazione della sintassi presentano in genere un rischio diretto inferiore. I team possono rinviarne il contenuto a una successiva valutazione a livello di artefatto.
Questa è la parte più solida della proposta AWS. Collega la spesa per la sicurezza a un modello esplicito di fiducia, persistenza ed esecuzione.
Riflette inoltre il principio del privilegio minimo. Un agente dovrebbe ricevere solo le autorizzazioni necessarie per il compito corrente, mentre le azioni a rischio più elevato attivano controlli e approvazioni più rigorosi.
I filtri per le informazioni sensibili possono bloccare o mascherare dati personali riconosciuti. Espressioni regolari personalizzate possono individuare segreti, identificatori o formati di credenziali specifici dell'organizzazione.
Gli argomenti vietati possono interrompere richieste che coinvolgono attività proibite. I filtri sui contenuti possono identificare categorie quali condotta scorretta, violenza o attacchi ai prompt.
Questi controlli non sostituiscono la sicurezza del codice convenzionale. Un guardrail potrebbe rilevare una chiave esposta, ma non è un analizzatore statico completo né uno scanner delle dipendenze.
I team necessitano comunque di revisione del codice, scansione dei segreti, analisi della composizione software, test, sandboxing e policy di deployment. Ogni controllo intercetta una diversa categoria di errore.
Il design migliore, quindi, sovrappone Bedrock Guardrails ai controlli ingegneristici esistenti. Non chiede a un singolo filtro probabilistico di certificare che un'applicazione sia sicura.
La valutazione selettiva crea un nuovo compromesso sulla sicurezza
Allontanare i controlli dai flussi continui riduce gli sprechi, ma aumenta il costo di un checkpoint mancato o di una classificazione del rischio errata.
AWS presenta il ragionamento intermedio come contenuto effimero che in genere non attraversa un confine di fiducia. Saltare quel materiale può eliminare molte valutazioni di scarso valore.
Tuttavia, non ogni azione intermedia è innocua. Un agente può eseguire un comando shell, inviare una richiesta di rete o modificare un file prima di produrre la risposta finale.
Un flusso di lavoro che controlla solo la risposta finale potrebbe non rilevare danni creati in precedenza. L'unità corretta di analisi è quindi l'azione, non soltanto l'output visibile.
I team devono intercettare le chiamate agli strumenti pericolose prima dell'esecuzione. Non dovrebbero attendere un artefatto di codice finale quando l'agente ha già ricevuto credenziali di produzione.
Questo requisito rende essenziale la strumentazione degli strumenti. Ogni strumento necessita di un livello di rischio definito, argomenti consentiti, ambito delle autorizzazioni, policy di logging e comportamento in caso di errore.
Anche la risposta del guardrail necessita di un percorso di applicazione. Rilevare un intervento significa poco se l'applicazione continua con la stessa scrittura su file o lo stesso comando.
Le applicazioni dovrebbero adottare per impostazione predefinita uno stato sicuro quando la valutazione va in timeout o restituisce un errore. Il fallback corretto dipende dal potenziale impatto dell'azione.
Un suggerimento ritardato per l'interfaccia utente potrebbe proseguire verso un controllo successivo. Un deployment in produzione o una modifica alla policy di identità dovrebbe in genere fermarsi finché la valutazione non riesce.
I falsi positivi rappresentano un'altra preoccupazione. Il codice generato contiene naturalmente parole, stringhe ed esempi che possono assomigliare a credenziali, istruzioni di attacco o attività proibite.
Il software di sicurezza potrebbe includere descrizioni di exploit per test difensivi. Il codice di autenticazione tratta necessariamente controlli di accesso, token e resistenza ai bypass.
I filtri personalizzati necessitano di test su repository rappresentativi. I team dovrebbero misurare tassi di intervento, override degli sviluppatori, rilevamenti mancati e risultati delle revisioni.
AWS raccomanda la pianificazione della capacità, ma la stessa disciplina dovrebbe coprire la qualità delle policy. Un volume inferiore di richieste non garantisce decisioni di sicurezza migliori.
Anche gli esempi numerici dell'azienda richiedono un'interpretazione attenta. Lo scenario con 15 sviluppatori illustra il comportamento dell'architettura anziché riportare prestazioni osservate presso i clienti.
Il miglioramento di 20 volte riguarda la frequenza di valutazione passando da intervalli di 50 caratteri a intervalli di 1.000 caratteri. Non costituisce una garanzia di prestazioni universale.
Le quote di servizio regionali possono differire e le allocazioni degli account possono cambiare. AWS consiglia ai clienti di verificare i propri limiti effettivi anziché presumere che si applichino i valori predefiniti pubblicati.
Il consumo delle policy rimane moltiplicativo tra i tipi di salvaguardie configurati. Un intervallo di streaming più ampio riduce la frequenza delle chiamate, ma i controlli completi elaborano comunque il contenuto selezionato.
La valutazione selettiva può anche creare lacune di visibilità. I team di sicurezza potrebbero perdere una registrazione dettagliata delle generazioni intermedie problematiche che non arrivano mai a un commit.
Questa perdita potrebbe essere accettabile per ragioni di privacy ed efficienza. Potrebbe anche limitare l'analisi forense dopo un comportamento inatteso di un agente.
Le organizzazioni dovrebbero decidere quali metadati intermedi conservare senza archiviare contenuti privati della catena di pensiero. Richieste agli strumenti, decisioni delle policy e hash degli artefatti offrono segnali di audit più sicuri.
La documentazione di Guardrails descrive diversi componenti delle policy, ma le organizzazioni definiscono comunque i propri confini di utilizzo accettabile. Bedrock non può dedurre ogni rischio specifico di un'azienda.
Anche i controlli formali delle policy hanno dei limiti. Amazon Bedrock offre il ragionamento automatizzato per convalidare affermazioni in linguaggio naturale rispetto a regole definite.
I controlli di ragionamento utilizzano la logica formale per restituire risultati strutturati. Le affermazioni al di fuori dell'ambito definito dalla policy rimangono non convalidate.
I controlli di grounding contestuale affrontano un problema diverso. Confrontano le risposte con il materiale sorgente fornito e valutano la rilevanza rispetto alla query dell'utente.
AWS osserva che i controlli di grounding sono destinati a compiti quali riepilogo, parafrasi e risposta alle domande. Non sono test generali di correttezza del codice.
Nessuno di questi meccanismi dimostra che il codice generato sia sicuro, corretto o manutenibile. Valutano i contenuti rispetto alle policy configurate e ai metodi di rilevamento supportati.
Questo confine dovrebbe rimanere esplicito nella documentazione interna. Altrimenti, “guardrail superati” può diventare un sostituto fuorviante di una revisione della sicurezza.
La lezione più profonda è che la copertura di sicurezza ha due dimensioni. I team necessitano di policy adeguate e devono invocarle prima di ogni transizione con conseguenze.
La scansione continua rende più facile dare per scontata la seconda condizione. La scansione selettiva rende necessario progettarla e verificarla.
Cosa dovrebbero osservare ora i clienti Amazon AWS
Il modello avrà successo solo se i deployment reali mostreranno meno eventi di throttling senza consentire ad azioni pericolose degli agenti di sottrarsi alla valutazione.
Il primo segnale sono i dati operativi provenienti da deployment più ampi di assistenti di programmazione. I team dovrebbero monitorare chiamate ai guardrail, unità di testo, latenza, throttling e tassi di intervento per checkpoint.
Un deployment riuscito dovrebbe ridurre le valutazioni ripetute preservando o migliorando il rilevamento durante scritture su file, commit, comandi e deployment.
Se il throttling diminuisce ma aumentano le azioni non revisionate, l'architettura ha ottimizzato il risultato sbagliato. Metriche di capacità e sicurezza devono comparire nella stessa dashboard.
Il secondo segnale è una maggiore integrazione tra agenti di programmazione e checkpoint delle policy. I fornitori necessitano di hook espliciti attorno a strumenti, artefatti, operazioni sui repository e ambienti di esecuzione.
Hook chiari rafforzerebbero il modello dei confini di fiducia di AWS. Azioni degli agenti nascoste o incoerenti lo indebolirebbero, poiché i clienti non potrebbero collocare i controlli in modo affidabile.
I fornitori di modelli devono inoltre esporre quali contenuti diventano visibili, persistenti o eseguibili. Questi stati determinano se una valutazione può essere rinviata in sicurezza.
Il terzo segnale è costituito dalle evidenze sull'accuratezza delle policy nei contesti specifici del codice. Le organizzazioni necessitano di test pubblicati su segreti, codice infrastrutturale, modifiche all'autenticazione e attività di sicurezza difensiva.
I soli conteggi degli interventi non sono sufficienti. I team dovrebbero esaminare veri positivi, falsi positivi, override, difetti sfuggiti e incidenti rilevati dagli scanner a valle.
Questi risultati possono guidare i livelli di rischio. Le policy IAM potrebbero ricevere tutte le salvaguardie configurate, mentre il normale codice di presentazione attende una revisione a livello di artefatto.
Il modello necessita anche di test di carico regolari. Un progetto pilota con due persone non può rivelare il comportamento a raffica di un reparto che avvia sessioni di agenti concorrenti.
I team dovrebbero simulare dimensioni di output realistiche, uso degli strumenti in più passaggi e contesto ripetuto. Dovrebbero inoltre testare i fallimenti nelle chiamate ai guardrail e nell'inferenza del modello.
Ogni checkpoint necessita di una risposta definita a GUARDRAIL_INTERVENED, throttling, negazione dell'accesso, timeout e contenuti malformati. Gli errori non definiti diventano spesso errori permissivi.
Le modifiche alla configurazione meritano gli stessi controlli. Versioni dei guardrail, soglie dei filtri, espressioni personalizzate e classificazioni degli strumenti dovrebbero passare attraverso revisione e rollout graduale.
Gli sviluppatori possono sostenere questo processo mantenendo modelli di minaccia e risultati delle valutazioni vicini alle decisioni di implementazione. Un sistema personale di conoscenza può aiutare a collegare specifiche, incidenti e risultati dei test dispersi.
Amazon AWS ha individuato una reale discrepanza di scalabilità. Gli agenti di codice producono troppo materiale temporaneo e ripetitivo perché un modello di sicurezza da chat breve possa restare efficiente.
La risposta proposta non è una copertura più debole per impostazione predefinita. È una copertura concentrata nei momenti in cui il contenuto acquisisce conseguenze.
Questa distinzione determinerà se i team adotteranno il modello in modo responsabile. Saltare il ragionamento intermedio è ragionevole solo quando le azioni pericolose rimangono protette separatamente.
Prima di modificare una configurazione Bedrock, i team dovrebbero mappare ogni percorso dal prompt a un'azione persistente o eseguibile. Dovrebbero quindi assegnare una policy, un responsabile e una modalità di errore.
Successivamente, possono testare l'intervallo di streaming di 1.000 caratteri nei casi in cui rimane necessaria la scansione immediata dell'output. Possono confrontare questo design con controlli disaccoppiati sugli input e sugli artefatti.
Infine, dovrebbero convalidare il sistema in condizioni di concorrenza realistiche. La domanda importante non è se un guardrail funzioni durante una singola richiesta.
La domanda è se Amazon AWS Guardrails possa sostenere flussi di lavoro di programmazione estesi a tutto il team bloccando al contempo le azioni che contano di più.
