Nel modello descritto da AWS, l’accesso di un agente IA passa da tre controlli distinti: Okta rilascia il token delegato ID-JAG, Amazon Bedrock AgentCore Gateway ne verifica i parametri, Cedar decide quali strumenti l’agente può usare e il server MCP controlla ancora i permessi dell’utente. Questa separazione chiarisce chi autorizza ogni passaggio; resta però una domanda diversa: che cosa può dedurre l’agente combinando risultati ottenuti con chiamate singolarmente consentite? AWS ha illustrato l’architettura e i relativi test in un tutorial pubblicato il 6 novembre 2026.
Chi controlla l’accesso di un agente IA?
Un ID-JAG, cioè un token di autorizzazione delegata, rappresenta l’accesso concesso all’agente per conto di un utente. Nel flusso descritto da AWS, il backend passa il token all’agente, che lo inoltra al proprio Gateway. Il Gateway controlla che emittente, destinatario, client autorizzato e ambiti corrispondano alla configurazione prevista; anche gli ambiti richiesti dalla destinazione devono coincidere con quelli dell’ID-JAG.
Poi interviene Cedar, il linguaggio di policy usato per decidere se l’agente può visualizzare uno strumento o invocarlo. Questa regola riguarda l’identità dell’agente, lo strumento e l’ambito delegato. Il server MCP, che espone gli strumenti all’agente tramite il Model Context Protocol, esegue comunque un controllo separato sui gruppi dell’utente e sui suoi ambiti. In breve: il permesso dell’agente non sostituisce quello dell’utente.
AWS descrive policy Cedar basate solo su autorizzazioni esplicite: se una regola di permesso non si applica, l’esito predefinito è negare l’accesso. La separazione è concreta anche nella configurazione: nell’esempio ogni agente ha un proprio Gateway e un proprio provider di credenziali.
Un controllo per ogni chiamata è utile, ma non basta a stabilire quali informazioni l’agente può ricavare unendo più risultati consentiti.
XAA e consenso OAuth per utente: chi autorizza e come cambia la revoca
La scelta dipende dal sistema di autorizzazione della destinazione. Cross App Access (XAA) è adatto al flusso descritto quando il server di autorizzazione della destinazione accetta gli ID-JAG: nell’esempio AWS, un amministratore Okta stabilisce quali agenti possano agire per quali utenti, senza una richiesta di consenso mostrata a ogni utente. Per un’applicazione con un proprio server di autorizzazione, come GitHub nell’esempio, AWS usa invece il consenso OAuth per utente.
| Aspetto | XAA con destinazione che accetta ID-JAG | Consenso OAuth per utente |
| Chi autorizza | Un amministratore Okta decide quali agenti possono agire per quali utenti. | Ogni utente concede il consenso alla destinazione. |
| Richiesta di consenso all’utente | Nel flusso descritto, l’utente non vede una richiesta di consenso. | L’utente deve collegare l’app e concedere il consenso. |
| Sospensione dell’utente nel test AWS | I controlli Okta bloccano la successiva emissione di ID-JAG; quelli già emessi scadono in circa cinque minuti. | Sospendere Alice non ha invalidato il token d’ingresso, valido un’ora nel test, né il consenso memorizzato. Un nuovo accesso è stato rifiutato; dopo la riattivazione, l’accesso è ripreso senza un nuovo consenso. |
Nel test sul flusso OAuth, scollegare il consenso ha fatto risultare la destinazione non connessa. I risultati descrivono quei due flussi di prova: non sono una regola valida per ogni applicazione. La compatibilità del server di autorizzazione della destinazione con gli ID-JAG è il criterio che determina se il flusso XAA descritto è applicabile.
Che cosa ha riportato AWS dai suoi test
Nel test AWS, l’agente A ha elencato sei strumenti. Alice e Carol non hanno potuto creare attività, mentre Bob ci è riuscito. L’agente B ne ha elencati quattro perché Cedar ne nascondeva gli strumenti di scrittura; non aveva quindi uno strumento di scrittura da usare neppure per Bob. Sono esiti riferiti alla configurazione provata da AWS.
AWS ha inoltre riportato misure di latenza ricavate da 24 ore di tracce di Gateway A. La latenza d’ingresso del Gateway ha avuto una mediana di 34 ms e un 90º percentile di 69 ms. Per le tracce di identità e policy, AWS indica circa 0,2 secondi complessivi alle rispettive mediane per una chiamata; il controllo authz.check del server MCP è durato meno di 1 ms. La traccia di invocazione della destinazione ha registrato una mediana di 5.565 ms e un 90º percentile di 6.273 ms. Sono osservazioni della prova AWS, non un benchmark generale delle prestazioni.
Nello stesso esempio, un secondo agente ospitato su Amazon EKS aveva una propria registrazione Okta, un Gateway e un provider di credenziali; il collegamento alla risorsa gli consentiva l’ambito xaa:read. AWS riferisce che l’agente B ha respinto l’ID-JAG dell’agente A in 98 ms, prima di una chiamata al modello.
Dettagli che possono far fallire un controllo o una traccia
AWS segnala alcune condizioni concrete della propria implementazione. Le policy che indicano strumenti specifici non si sono collegate alle destinazioni con elenchi dinamici nei test descritti. Inoltre, il Gateway divide la risposta tools/list per destinazione: il client deve seguire il cursore di paginazione per recuperare gli strumenti successivi. Le policy devono essere nello stato ACTIVE prima di collegare il motore di policy.
Per l’agente su Amazon EKS, AWS indica che il gruppo di nodi general purpose di EKS Auto Mode usa l’architettura amd64 e che ha quindi creato immagini multi-architettura. Nella configurazione container descritta, l’SDK Python di AgentCore richiede DOCKER_CONTAINER=true. Per esportare le tracce, AWS segnala anche la necessità di aggiungere botocore dove manca e di mantenere l’instrumentazione del client HTTP necessaria a propagare il contesto delle tracce.
AWS definisce gli snippet concettuali, non una soluzione completa pronta per il deployment, e dichiara il codice di esempio destinato a un uso non produttivo.
Quando risultati consentiti rivelano insieme informazioni sensibili
Un partecipante a r/LLMDevs propone uno scenario ipotetico: un agente riceve i totali delle retribuzioni per team e, con un’altra chiamata consentita, il numero di persone in ogni team. Se un team ha una sola persona, combinare i due risultati potrebbe rivelarne lo stipendio. È un esempio di ragionamento, non un incidente misurato né un risultato dei test AWS.
Il suggerimento del partecipante è valutare la domanda combinata con uno strumento sottoposto a policy, oppure impedire che i risultati vengano riuniti fuori dallo strumento. Il caso mette in evidenza una distinzione pratica: controllare chi può effettuare ogni chiamata non affronta automaticamente ciò che si può dedurre dall’insieme delle risposte.
