Un agente che gira su AWS o contro AWS non dovrebbe mai detenere una credenziale a lunga durata. Non un utente IAM, non una access key in un secrets manager, non un service account "agents" condiviso. Ogni percorso di autenticazione serio che AWS offre, instance profile, IRSA, EKS Pod Identity, federazione OIDC, IAM Roles Anywhere, AgentCore Identity, esiste per fare la stessa cosa: scambiare una prova di identità verificabile con credenziali temporanee che scadono da sole. Se la vostra piattaforma di agenti parte da questa regola, la maggior parte delle domande difficili si risponde da sola.

Ieri ho scritto del livello di protocollo di questo problema sul sito gemello: SEP-1046 che dà agli agenti MCP una vera storia di client credentials, con asserzioni JWT firmate al posto dei segreti condivisi. Questo post è il livello sottostante: quando il target dell'agente è AWS stesso, o l'agente gira su AWS e deve raggiungere tutto il resto, che aspetto ha davvero la sua identità? La risposta, in quasi tutti i casi, ha la stessa forma scelta da SEP-1046: un token firmato a vita breve in ingresso, credenziali a vita breve in uscita. AWS fa girare questo pattern su larga scala da anni. Dovete solo smettere di combatterlo con chiavi statiche.

Un solo pattern sotto tutto: la federazione OIDC

Togliete i nomi dei prodotti e l'autenticazione degli agenti su AWS è un unico meccanismo. Un identity provider firma un JWT su un workload. Registrate l'issuer URL di quel provider in IAM come OIDC identity provider; IAM recupera le chiavi pubbliche dal jwks_uri del provider tramite il documento di discovery /.well-known/openid-configuration. Il workload presenta il suo token a sts:AssumeRoleWithWebIdentity e ottiene credenziali di ruolo che scadono entro l'ora. La trust policy del ruolo blocca chi entra con condizioni sui claim aud e sub del token.

La versione di questo schema che ogni platform team conosce già è GitHub Actions: il runner riceve un token OIDC il cui claim sub codifica repo e branch, la trust policy del ruolo fa match su repo:my-org/my-repo:ref:refs/heads/main, e nessuna access key vive mai nei secrets del repository. Non è un trucco da CI. È il modello per ogni workload non presidiato, agenti inclusi. Un'asserzione firmata, legata all'audience e con una vita di minuti che sostituisce un segreto memorizzato è esattamente quello che fa private_key_jwt a livello MCP; l'industria è arrivata alla stessa risposta da due direzioni diverse, che di solito è il segno che la risposta è quella giusta.

Dove gira l'agente decide il meccanismo

Raramente costruite la federazione da soli. Scegliete il pacchetto che corrisponde al runtime:

  • Su EC2 o ECS: instance profile o task role. La credential chain dell'SDK li raccoglie da sola, niente da configurare nell'agente. Se il vostro framework per agenti chiede una access key qui, è un difetto del framework, non un requisito di AWS.
  • Su EKS: due opzioni. IRSA (IAM Roles for Service Accounts) è la più vecchia: il cluster espone un issuer OIDC, lo registrate in IAM e annotate un ServiceAccount con l'ARN di un ruolo. EKS Pod Identity è la più recente: nessuna registrazione del provider OIDC per cluster, un add-on agent sul nodo scambia le credenziali, e la trust policy del ruolo punta a pods.eks.amazonaws.com una volta sola invece che agli issuer URL di ogni cluster. Per una flotta di cluster, Pod Identity elimina fatica operativa reale; per un cluster singolo vanno bene entrambe. Tutte e due finiscono nello stesso punto: un ruolo IAM per workload agente, nessuna chiave nel pod.
  • Fuori da AWS, con un IdP: semplice federazione OIDC come sopra. Il workload nel vostro datacenter, nell'altro cloud, nel runner SaaS si autentica verso il proprio identity provider e federa l'accesso. È il pattern di GitHub Actions generalizzato.
  • Fuori da AWS, senza un IdP: IAM Roles Anywhere. Il workload presenta un certificato X.509 emesso da una CA che avete registrato come trust anchor (AWS Private CA o la vostra PKI) e lo scambia con credenziali di ruolo temporanee tramite un profile. L'avvertenza onesta: ereditate la gestione del ciclo di vita dei certificati, emissione, rotazione, revoca. Se non gestite già una PKI, mettere in piedi un identity provider di solito pesa meno a livello operativo che adottarne una.

AgentCore Identity: il livello a misura di agente sopra il resto

IAM risponde a "come fa questo workload a chiamare AWS". Gli agenti hanno altri due problemi: chi è autorizzato a chiamare l'agente, e come l'agente raggiunge servizi non AWS, Slack, GitHub, Google, per conto di un utente. Questa è la fetta che copre Amazon Bedrock AgentCore Identity, e vale la pena capirla anche se non userete mai AgentCore, perché è AWS che mette per iscritto cosa serve all'identità di un agente oltre a un ruolo.

  • Workload identity per gli agenti. Ogni agente ha la propria voce nella directory, non un principal condiviso. La stessa regola una-identità-per-workload dei ruoli IAM, applicata un livello più in alto.
  • Autenticazione in ingresso. I chiamanti raggiungono l'agente o con SigV4 puro (IAM come al solito) o attraverso un JWT authorizer: configurate un discovery URL e le audience ammesse, e i token di Cognito, Okta o Entra ID fanno da cancello all'agente. AgentCore Gateway espone lo stesso authorizer CUSTOM_JWT per gli endpoint dei tool, ed è così che un gateway in stile MCP su AWS valida i token di cui il post precedente raccontava l'emissione.
  • Autenticazione in uscita. Un token vault conserva i grant OAuth per i servizi di terze parti, two-legged per il service-to-service, three-legged dove un utente ha dato il consenso una volta e l'agente agisce su quel consenso in seguito. È il pattern dell'agire per conto di qualcuno con il consenso conservato lato server invece di un refresh token incollato in una variabile d'ambiente.
  • Nota sui prezzi. Attraverso AgentCore Runtime o Gateway non costa nulla in più; l'uso standalone fattura per ogni richiesta OAuth token o API key andata a buon fine. Economico in entrambi i casi; la parte costosa è sempre stata l'incidente che evitate.

Anche lo strato di protocollo sopra tutto questo continua a muoversi. La coda auth del repo della spec MCP contiene proposte che il vostro gateway incontrerà entro l'anno: securitySchemes nei metadati dei tool per i server ad auth mista (SEP-1488), errori dei tool standardizzati che innescano un flusso OAuth a metà sessione (SEP-1489), e metodi di autenticazione dichiarati per i server remoti (SEP-2742). Se gestite un gateway MCP su AWS, tenete d'occhio quel label come tenete d'occhio le release notes di EKS.

L'attribuzione è la parte che gli audit chiedono davvero

Le credenziali temporanee risolvono il furto; da sole non risolvono "quale agente ha fatto questo". Tre abitudini chiudono quel buco. Un ruolo per agente, così la role session di CloudTrail nomina già il workload. sts:SourceIdentity impostato al momento dell'assunzione del ruolo, così l'umano o il sistema che ha attivato l'agente sopravvive in ogni riga di log a valle, anche attraverso il role chaining. E session policy per restringere un ruolo ampio al compito del momento, così il raggio d'impatto di un agente vittima di prompt injection, o semplicemente in errore, è dato dai permessi del compito, non da quelli del ruolo. Tenete i permessi permanenti in sola lettura e mettete un cancello davanti a ogni azione che modifica; l'ho sostenuto abbastanza volte che i lettori abituali possono recitarlo a memoria.

Cosa fare lunedì

  • Eseguite aws iam list-users e trattate ogni utente IAM con access key attive che appartiene a un'automazione come un finding. Gli agenti sono automazioni.
  • Mappate ogni agente sul suo runtime e adottate il meccanismo corrispondente: instance/task role, IRSA o Pod Identity, federazione OIDC, Roles Anywhere. In quest'ordine di preferenza.
  • Vincolate ogni trust policy OIDC su aud e sul pattern sub più stretto che riuscite a scrivere. Una trust policy senza condizione su sub è una porta aperta con un bel cartello.
  • Impostate sts:SourceIdentity in ogni chiamata assume-role degli agenti e fate in modo che le vostre query CloudTrail lo usino. Aggiungere l'attribuzione dopo un incidente non funziona.
  • Se siete su AgentCore, mettete il JWT authorizer davanti agli agenti e spostate i grant OAuth di terze parti nel token vault. Se non lo siete, copiatene la forma: identità per agente, token in ingresso validati, consenso conservato lato server.

Il filo conduttore con il pezzo su MCP è difficile da non vedere. Protocollo dopo protocollo, piattaforma dopo piattaforma, l'identità degli agenti sta convergendo su asserzioni firmate a vita breve, audience binding e principal per workload, e i pezzi ora esistono a entrambi i livelli. I team che ancora copiano access key nelle configurazioni degli agenti non sono early adopter di niente. Stanno applicando una postura di sicurezza del 2015 a workload del 2026.

Leggi questo dopo

Agent Toolkit for AWS: The Docs Have a New Reader racconta cosa fanno davvero con l'accesso ad AWS quegli agenti autenticati. Sul sito gemello, Enterprise MCP Auth: Agents Finally Get Service Accounts è la metà di questo post a livello di protocollo, e ercanermis.com mappa tutto il resto che scrivo.

Riferimenti