Quando un agente AI chiama un’API a valle per conto di un utente, si pone un problema di identità: chi è l’identità che viaggia con la chiamata? Usare l’identità di servizio dell’agente distrugge l’audit trail; inoltrare il token dell’utente invariato trasforma ogni tool a valle in un confused deputy. Nessuna delle due opzioni scala quando un solo agente serve molti tenant e l’utente non è presente al momento della chiamata.
La specifica OAuth 2.0 Token Exchange (RFC 8693) risolve esattamente questo, e Amazon Bedrock AgentCore Identity la supporta nativamente come grant type di un credential provider. Per chi progetta agenti in produzione multi-tenant, il punto pratico è che l’agente non deve implementare lo scambio: è il Gateway a orchestrarlo in modo trasparente prima di ogni chiamata a valle.
Cosa cambia nel token
Nel pattern on-behalf-of (OBO), il claim sub (l’utente originale) viene preservato end to end, mentre il claim aud viene riscritto verso il servizio a valle: il token risulta così legato crittograficamente a una singola API. Un claim separato (act per RFC 8693, cid in Okta) registra l’attore che ha eseguito lo scambio. Così la stessa firma risponde a due domande: per conto di chi si sta agendo (autorizzazione su sub) e chi sta agendo (audit e rate-limiting sull’attore).
Difesa in profondità e insidie
L’implementazione di riferimento (TravelBot, con due tenant Okta) mostra che il vincolo di audience è applicato in tre punti indipendenti: sul target del Gateway, sull’authorization server del tenant e sul JWT authorizer di API Gateway. Un token con aud di Acme presentato alla route di Globex viene rifiutato con HTTP 401 prima ancora che la Lambda venga invocata. L’isolamento per utente arriva dal partizionamento di DynamoDB sul claim sub.
La guida segnala anche insidie concrete: durante lo scambio, Okta tratta il grant come machine-to-machine e non filtra gli scp per gruppo dell’utente, quindi lo scoping per utente va gestito con un claim Expression (authorized_scopes) valutato dal resource server; il DPoP va disabilitato perché AgentCore Identity è un relay senza la chiave; e il subject_token_type deve essere access_token, non jwt. Onboardare un nuovo tenant richiede solo un credential provider e un target in più, senza modifiche al codice dell’agente.
- OBO preserva l’identità dell’utente (
sub) e vincola ogni token a una sola API tramiteaud: least privilege crittografico. - Il vincolo di audience è applicato in tre layer indipendenti, ognuno che fallisce in modo chiuso.
- Le decisioni di autorizzazione vanno prese su
sube sui claim per-utente, non sull’attore, che appartiene ai log di audit.
Fonte: Implement on-behalf-of token exchange for multi-tenant agents with Bedrock AgentCore Gateway — https://aws.amazon.com/blogs/machine-learning/implement-on-behalf-of-token-exchange-for-multi-tenant-agents-with-amazon-bedrock-agentcore-gateway/
Hai qualcosa da aggiungere? Unisciti alla discussione.