Cosa significa autorizzazione degli agenti
L'autorizzazione degli agenti è la decisione su ciò che un agente AI può fare: quali route può chiamare, quali dati può leggere, quali azioni può eseguire e a quale volume. È distinta dall'identità dell'agente, che riguarda l'accertamento di quale agente, o dell'agente di quale operatore, stia effettuando la richiesta.
Le due cose sono facili da confondere perché spesso arrivano insieme. Una richiesta firmata ti dice chi l'ha inviata. Non ti dice se quel mittente debba essere autorizzato a modificare un account, effettuare un ordine o esportare dati. L'identità è evidenza; l'autorizzazione è policy. Il nostro articolo su cosa dimostrano le richieste firmate di agenti AI, e cosa no chiarisce la differenza.
Perché la distinzione conta
Le applicazioni separano già autenticazione e autorizzazione per gli utenti umani: l'accesso dimostra chi sei, e ruoli e permessi decidono cosa puoi fare. Gli agenti hanno bisogno della stessa separazione, con un livello aggiuntivo di attenzione:
- L'identità può essere forte mentre il permesso manca. Un crawler con una firma HTTP message signature perfettamente valida non ha alcun diritto intrinseco di chiamare un endpoint di scrittura.
- Il permesso può esistere senza un'identità forte. Un agente che usa una API key di un cliente è autorizzato da quella chiave, anche se nulla identifica quale software agente la stia usando.
- Conta la persona dietro l'agente. Quando un agente agisce per qualcuno, la domanda diventa se quella persona gli abbia conferito l'autorità (vedi autorità delegata).
Fondere questi aspetti in un solo controllo porta a due modalità di errore: bloccare automazioni legittime perché non dispongono di un accesso umano, oppure fidarsi di un agente ben identificato per azioni che non avrebbe mai dovuto compiere.
Come si esprime di solito l'autorizzazione
La maggior parte delle applicazioni autorizza gli agenti con meccanismi che ha già a disposizione:
- Credenziali e scope. API key o token OAuth 2.0 con scope limitati a ciò che l'integrazione richiede. Anche i server MCP usano lo stesso modello: la specifica di autorizzazione MCP tratta un server protetto come un resource server OAuth 2.1.
- Policy a livello di route. Route in sola lettura aperte ad agenti noti; route di scrittura che richiedono una credenziale collegata a un account.
- Livelli di rischio. Azioni a basso impatto consentite in modo ampio, azioni ad alto impatto che richiedono credenziali più forti, conferma o revisione.
- Limiti di frequenza e quote per operatore, per credenziale o per route.
L'evidenza dell'identità dell'agente alimenta queste decisioni come uno degli input. Per un approccio completo, vedi progettare policy a livello di applicazione per persone e agenti AI. Ti consente di trattare un operatore verificato in modo diverso da un client anonimo, ma il permesso in sé continua a derivare dalla tua policy.
Idee sbagliate comuni
- "Agente verificato significa autorizzato." La verifica attribuisce una richiesta. La tua policy decide comunque che cosa può fare la parte attribuita.
- "Gli agenti dovrebbero essere bloccati a meno che non sia provato che sono umani." Molti agenti sono partecipanti legittimi. La domanda migliore è cosa debba essere consentito a ciascun tipo di attore, route per route.
- "L'autorizzazione può essere dedotta dal comportamento." Il comportamento può aumentare o ridurre la fiducia su quale tipo di attore sia presente. Non dovrebbe concedere il permesso da solo.
Come Proof of Actor lo gestisce
Proof of Actor risponde alla domanda sull'evidenza: che tipo di attore è presente, su quale base (verified, declared, inferred o unknown), e che cosa è noto e che cosa non lo è. Deliberatamente non decide il permesso. Un risultato Agent, anche se verificato, non implica mai autorizzazione. In Route, la tua applicazione combina il risultato dell'attore con le proprie credenziali, scope e livelli di rischio per allow, adapt, challenge, review o limit each interaction, iniziando in observation mode così puoi verificare gli esiti prima di enforce anything.
Scopri di più su come le decisioni si integrano nella tua app, consulta i casi d'uso per APIs e MCP servers, oppure richiedi l'accesso anticipato.
Fonti
- RFC 6749: The OAuth 2.0 Authorization Framework: token con scope per i client
- MCP specification 2026-07-28: Authorization: autorizzazione basata su OAuth per i server MCP
- RFC 9421: HTTP Message Signatures: ciò che stabilisce una richiesta firmata