Un agente è un chiamante che non puoi prevedere completamente, il che è esattamente il tipo di chiamante che dovrebbe avere il minimo privilegio. L'istinto con un nuovo agente è dargli un ruolo ampio così "funziona e basta" mentre iteri. Quell'istinto è come finisci con un language model che detiene credenziali capaci di leggere ogni bucket e cancellare ogni tabella, guidato da testo che un attaccante può influenzare. Il least privilege è sempre stata la regola. Un chiamante non deterministico la rende non negoziabile.

Il cambio di mentalità consiste nello smettere di pensare all'agente come al tuo codice e iniziare a pensarlo come un attore semi-fidato che agisce per tuo conto. Il tuo codice fa quello che hai scritto. Un agente fa quello che il modello ha deciso, e il modello ha deciso in base a input che non controlli. Il confine IAM è ciò che sta tra "l'agente ha fatto una scelta strana" e "l'agente ha fatto una scelta strana con privilegi admin".

Un ruolo per tool, non un ruolo per agente

L'anti-pattern comune è un unico ruolo di esecuzione collegato all'intero agente, che porta l'unione di ogni permesso di cui qualsiasi tool potrebbe aver bisogno. Quel ruolo è ora il raggio d'azione di ogni tool contemporaneamente. Un prompt injection che raggiunge il tool più debole eredita i permessi del più forte.

Definisci lo scope dei permessi per tool, non per agente. La Lambda dietro un tool lookup_order ottiene un ruolo che può leggere una tabella e nient'altro. La funzione dietro send_email ottiene un ruolo che può chiamare SES per una identità verificata. Nessun tool porta un permesso che non usa, quindi una chiamata di tool compromessa può fare solo il lavoro di quel tool.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "dynamodb:GetItem",
    "Resource": "arn:aws:dynamodb:eu-west-1:111122223333:table/orders",
    "Condition": {
      "ForAllValues:StringEquals": {
        "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
      }
    }
  }]
}

Questo è l'intero permesso per il tool di ricerca ordini: leggere un elemento, da una tabella, e solo righe per il tenant del chiamante. Non c'è nient'altro che un'istruzione iniettata possa raggiungere.

Restringi ulteriormente il ruolo a runtime con le session policy

I ruoli per tool sono il pavimento. Per sistemi multi-tenant vuoi anche che il permesso sia ristretto alla richiesta specifica. Le session policy ti permettono di farlo: quando il tuo backend assume il ruolo del tool, passa una policy inline che si interseca con i permessi del ruolo per quella singola sessione, quindi una richiesta che agisce per il tenant A non può toccare i dati del tenant B anche se il ruolo tecnicamente copre l'intera tabella.

aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/order-lookup \
  --role-session-name agent-tenant-a \
  --policy '{"Version":"2012-10-17","Statement":[{
    "Effect":"Allow","Action":"dynamodb:GetItem",
    "Resource":"arn:aws:dynamodb:eu-west-1:111122223333:table/orders",
    "Condition":{"ForAllValues:StringEquals":
      {"dynamodb:LeadingKeys":["tenant-a"]}}}]}'

Il permesso effettivo è l'intersezione tra il ruolo e la session policy, quindi le credenziali che il tool detiene effettivamente vengono ristrette a questa richiesta. I session tag più una condizione sul tenant nel ruolo ottengono lo stesso risultato in modo dichiarativo. In entrambi i casi, le credenziali consegnate alla chiamata guidata dal modello sono l'insieme più piccolo che completa il task corrente.

Policy davanti alle credenziali

IAM decide cosa può fare un principal. Non decide se questo particolare agente, in questo particolare turno, debba chiamare questo tool. Quella domanda di autorizzazione ora ha una risposta costruita apposta su AWS: Policy in Amazon Bedrock AgentCore, generalmente disponibile da inizio mese, valuta ogni richiesta da agente a tool rispetto a regole che scrivi in linguaggio naturale e che vengono compilate in Cedar, applicate a un AgentCore Gateway prima che la chiamata proceda. Leggila come un livello davanti a IAM, non un sostituto: il gateway decide se la chiamata al tool è permessa, e un ruolo IAM ristretto decide quanto poco danno può fare se lo è.

Registra l'assunzione del ruolo, non solo la chiamata API

Poiché i tool assumono ruoli ristretti, CloudTrail ti offre una traccia di audit pulita: quale ruolo è stato assunto, con quale nome di sessione, per quale task. Imposta il role-session-name su qualcosa che si ricollega al turno dell'agente e al tenant, e puoi ricostruire esattamente cosa ha fatto un agente e sotto l'autorità di chi. Quando un agente si comporta male, quella traccia è la differenza tra un incidente circoscritto che puoi spiegare e un mistero che non puoi.

Il punto chiave

Il least privilege non si allenta perché il chiamante è intelligente. Si stringe, perché il chiamante è non deterministico e influenzato da input non fidato. Dai a ogni tool il suo ruolo ristretto, intersecalo con una session policy per richiesta, metti davanti un livello di autorizzazione come AgentCore Policy, e registra ogni assunzione di ruolo. Quando il modello fa una scelta sbagliata, e lo farà, IAM è ciò che decide che la scelta sbagliata resti piccola.

Leggi questo dopo

Il lato più profondo di IAM e dell'hardening degli account vive nelle field notes cloud: mettere in sicurezza il tuo account AWS, su ercan.cloud. L'hub è su ercanermis.com.