Cosa è cambiato e cosa non è cambiato in Auth e Identità per le app agentiche

Recentemente ho recensito questo articolo e si è parlato di auth agent:

Stiamo vedendo indizi di come potrebbe apparire. L'ultima specifica MCP, ad esempio, include un framework di autorizzazione basato su OAuth 2.1, segnalando la possibilità di passare a dare agli agenti AI token con scope definiti e revocabili invece di segreti grezzi. Possiamo immaginare uno scenario in cui un agente AI non riceve le tue chiavi AWS effettive, ma ottiene invece una credenziale a breve termine o un token di capacità che gli consente di eseguire un'azione definita in modo ristretto.

https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/

Molti amici e persone che non sono nel campo della sicurezza o della CIAM hanno l'impressione che si tratti di qualcosa di nuovo, ma sicuramente non lo è. OAuth è un protocollo standard di autorizzazione basato su token che coinvolge token con permessi delimitati (token di accesso). Questi sono sensibili al tempo e limitati nel loro scope, il che garantisce la sicurezza e il corretto controllo degli accessi a risorse e servizi. Nel mercato SaaS globale (pre-AI), la maggior parte delle soluzioni professionali di identità sono già costruite su questo.

Quando colleghi il tuo account Google a un'applicazione di terze parti come Notion o Zoom, utilizza OAuth per richiedere solo le autorizzazioni necessarie, come l'accesso al tuo calendario o ai tuoi contatti, senza mai esporre la tua password di Google. Puoi revocare questo accesso in qualsiasi momento dalle impostazioni del tuo account Google. Questo modello di accesso delegato è esattamente ciò per cui OAuth è progettato e lo stesso fondamento si sta estendendo oggi alle applicazioni agentiche.

Cosa non cambia nel mondo agentico#

Auth non è nuova, è ancora basata su OAuth 2.1#

Stanno emergendo due grandi protocolli: MCP e A2A.

• MCP si concentra sull'interazione tra gli LLM e gli strumenti e il contesto della tua app.
• A2A si concentra sull'abilitare lo scambio di compiti tra agenti.

Ma quando si tratta di autenticazione e autorizzazione, entrambi si basano ancora su standard di settore ben consolidati come OAuth.

I server di autorizzazione MCP DEVONO implementare OAuth 2.1 con adeguate misure di sicurezza per i clienti sia confidenziali che pubblici.

Il Client A2A è responsabile per ottenere i materiali di credenziali necessari (ad es., token OAuth 2.0, chiavi API, JWT) tramite processi esterni al protocollo A2A stesso. Questo potrebbe comportare flussi OAuth (codice di autorizzazione, credenziali del client), distribuzione sicura delle chiavi, ecc.

Come dice Google:

Invece di inventare nuovi standard proprietari per la sicurezza e le operazioni, A2A mira a integrarsi senza soluzione di continuità con l'infrastruttura aziendale esistente e le migliori pratiche ampiamente adottate.

Un agente ha bisogno di un'identità unica?#

Un sacco di hype e contenuti FOMO spingono l'idea che, poiché gli agenti diventano più comuni, abbiamo bisogno di un sistema per gestire le identità degli agenti.

La risposta è: sì e no.

Sì, perché stiamo introducendo un nuovo strato tra umani e macchine. Ci sono reali esigenze di:

• Gestire e identificare gli agenti
• Assegnare ID unici
• Monitorare i log
• Verificare le azioni (per sapere se un compito è stato svolto da un umano o da un agente)

Tuttavia, nella maggior parte dei casi tecnici, non è necessario creare un concetto formale di “Identità dell'Agente.”

Agente ≠ Utente, ≠ Account di Servizio.

Dietro ogni agente, c'è ancora un utente e l'identità dell'utente è solitamente sufficiente.

Oggi, la maggior parte degli agenti:

• Agisce in base all'autorizzazione dell'utente (ad esempio, token OAuth)
• Esegue la logica o effettua una chiamata API
• Esegue attività brevi e una tantum (senza bisogno di monitoraggio)

In tal senso, l'agente è solo una funzione-come-strumento e non necessita di un ID globale unico.

Ad esempio:

• Un agente GPT che chiama la tua API Calendar ha bisogno solo dell'accesso che hai concesso.
• Un agente LangChain non ha bisogno di un'identità purché possa chiamare gli strumenti giusti, funziona.

Anche prima dell'AI, avevamo il concetto di auth da macchina a macchina (M2M).

M2M significa scambio automatico di dati tra servizi, senza intervento umano.

In questo contesto, l'autenticazione spesso utilizza un'app client o un account di servizio.

Se desideri davvero che il tuo agente abbia un'identità (per audit, ecc.), puoi utilizzare l'ID dell'app ed è sufficiente.

Devi ancora definire l'architettura del tuo prodotto#

Questo non è cambiato. Indipendentemente dal fatto che il tuo prodotto coinvolga agenti, l'architettura del tuo sistema di identità dipende da chi sono i tuoi utenti e da come il tuo sistema interagisce con loro.

Se stai creando un prodotto agentico rivolto ai consumatori: Dovrai avere metodi di accesso leggeri (email, telefono, accesso social) e un pool utente unificato per gestire gli individui che interagiscono con la tua app e i suoi agenti. Gli agenti agiscono per conto di questi utenti utilizzando token delegati (ad esempio, tramite OAuth).

Esempio:

Immagina di creare un assistente di pianificazione AI, o un bot di calendario alimentato dall'AI.

Ogni utente effettua l'accesso con il proprio account Google personale. Il tuo sistema utilizza OAuth per ottenere l'autorizzazione ad accedere al loro calendario. L'agente non ha una propria identità, utilizza il token dell'utente per pianificare riunioni, verificare la disponibilità o inviare promemoria. L'architettura dell'identità è semplice: un unico pool utente globale, archiviazione dei token e monitoraggio del consenso per utente.

Se stai costruendo una piattaforma agentica B2B:

Dovrai supportare l'identità a livello organizzativo, non solo per singoli utenti. Questo include:

1. SSO per clienti aziendali
2. Separazione a livello di spazio di lavoro o tenant
3. Politiche di delega degli agenti a livello organizzativo (ad esempio, controllare cosa possono fare gli agenti su team diversi)
4. Visibilità e log a livello di amministratore per tutte le attività degli agenti per conto dei dipendenti

Esempio:

Immagina di costruire una piattaforma che fornisce agenti AI per automatizzare i flussi di lavoro interni — come un bot analista di sicurezza che monitora i log e invia avvisi, o un assistente alle vendite che redige email dai dati CRM.

Ogni azienda che utilizza la tua piattaforma vuole:

1. Effettuare l'accesso con il proprio SSO esistente
2. Controllare a cosa possono accedere gli agenti (ad esempio, strumenti interni, sistemi di documenti)
3. Vedere quale agente ha svolto quale compito, con l'autorizzazione di quale dipendente

In questo caso, l'architettura dell'identità deve supportare un design multi-tenant, permessi degli agenti con scope definiti e politiche specifiche per organizzazione. Gli agenti agiscono ancora per conto degli utenti, ma le autorizzazioni e i confini di identità vengono applicati per ciascun tenant aziendale.

In entrambi i casi, il modello di identità definisce come operano gli agenti, a cosa possono accedere e come il tuo sistema garantisce la responsabilità.

Utilizza questa guida per aiutarti a pianificare la tua identità e l'architettura del prodotto.

https://docs.logto.io/introduction/plan-your-architecture/b2c

https://docs.logto.io/introduction/plan-your-architecture/b2b

Hai ancora bisogno di livelli di sicurezza per mantenere al sicuro le tue app alimentate da agenti#

Che si tratti di un'app agentica o meno, questi livelli di sicurezza fondamentali sono necessari per proteggere i tuoi utenti e sistemi:

• Autenticazione a più fattori (MFA)

  Previene l'accesso non autorizzato anche se le credenziali sono compromesse.

  Esempio: Se un agente ti aiuta a eseguire un'azione ad alto rischio, come effettuare una transazione o modificare impostazioni di identità, dovrebbe mantenere un umano nel loop e utilizzare MFA per confermare l'azione prima di procedere.

• CAPTCHA

  Blocca l'abuso automatizzato come il credential stuffing o le registrazioni bot-driven.

  Esempio: Mostra CAPTCHA dopo 3 tentativi di accesso falliti per prevenire attacchi brute-force.

• Controllo degli accessi basato sui ruoli (RBAC)

  Garantisce che utenti e agenti accedano solo a ciò a cui sono autorizzati.

  Esempio: Un assistente AI in un ambiente di lavoro aziendale può leggere eventi del calendario, ma non può accedere ai dati di fatturazione a meno che non venga assegnato esplicitamente un ruolo superiore.

• Accesso senza password

  Migliora l'UX e riduce il rischio di password deboli.

  Esempio: Consenti agli utenti di accedere utilizzando un link magico inviato all'email o un prompt biometrico come il Face ID.

Queste caratteristiche si applicano ad app sia tradizionali che basate su agent, specialmente mentre gli agenti iniziano a operare su dati e sistemi sensibili.

Cosa è cambiato nel mondo agentico#

Auth è più importante che mai#

Mentre emergono agenti e flussi di lavoro multi-agente, stiamo vedendo nuovi casi d'uso in cui utenti, agenti, API e server MCP interagiscono tutti. Il numero e la varietà di questi scenari stanno crescendo rapidamente, molto più che in passato.

Ogni volta che si verificano queste connessioni, l'autorizzazione diventa più visibile che mai. Gli utenti devono dare un chiaro consenso e i permessi devono essere gestiti accuratamente attraverso i sistemi. Ecco perché tutti ora parlano di mantenere un “umano nel loop”, assicurandosi che gli utenti abbiano abbastanza controllo e visibilità su ciò che gli agenti possono fare, e su quali ambiti sono autorizzati.

La tua app AI potrebbe dover integrare molti servizi esterni#

L'ecosistema MCP si sta espandendo, e questo significa che la tua app non è più solo un servizio stand-alone: è parte di una rete più ampia e connessa.

Per fornire un contesto ricco e utile agli LLM, i tuoi agenti potrebbero dover:

• Accedere a più server MCP

  Esempio: Immagina un project manager AI che recupera aggiornamenti sui compiti da Jira, disponibilità del team da Google Calendar, e dati di vendita da Salesforce e ognuna di queste potrebbe essere gestita da un server MCP diverso. Per generare un riepilogo settimanale, l'agente deve interagire in modo sicuro con più fonti di dati. È qui che entrano in gioco l'autenticazione e l'autorizzazione, per proteggere ogni connessione e controllare come i dati vengono condivisi.

• Connettersi con API e strumenti esterni

  Esempio: Un agente di supporto ai clienti potrebbe dover recuperare la cronologia degli ordini da Shopify, aggiornare i ticket in Zendesk e attivare flussi di lavoro in Slack. Senza integrazioni, l'agente diventa isolato e inefficace.

Mentre gli agenti assumono più responsabilità, l'integrazione diventa la chiave dell'utilità. Il tuo prodotto AI non riguarda solo ciò che può fare da solo, ma riguarda ciò a cui può accedere, orchestrare e ragionare in un ecosistema connesso. Ecco perché costruire per l'interoperabilità, in modo sicuro e flessibile, è più importante che mai.

Devi abbracciare standard aperti: OAuth/OIDC sono più importanti che mai#

Nell'era AI, la necessità di integrazioni sicure e flessibili sta crescendo. Questo rende OAuth 2.0 e OIDC più importanti che mai.

I casi d'uso chiave includono:

• Server MCP remoti: Consenti agli agenti di terze parti di accedere in modo sicuro al tuo prodotto utilizzando token delegati.
• Integrazioni di terze parti: Consenti ad altri strumenti o agenti di connettersi alla tua app (ad esempio, una piattaforma di gestione dei progetti) senza necessità di credenziali grezze.
• Sviluppo di agenti: Crea agenti AI che agiscano in modo sicuro per conto degli utenti attraverso servizi.
• Dispositivi intelligenti: Usa OAuth/OIDC per cose come gli appunti potenziati dall'AI per autenticare gli utenti e connettersi al cloud — specialmente con un'interfaccia minima.

Questi protocolli forniscono accesso sicuro, basato su token e con consenso dell'utente.

Questo è fondamentale in un mondo di sistemi agentici e connessi. Consulta questo articolo per vedere perché OAuth e OIDC sono importanti

Progettazione per la fiducia e la scala nell'era dei software agentici#

Mentre i prodotti agentici evolvono, i principi di base dell'identità e dell'autorizzazione rimangono gli stessi, ma il contesto sta cambiando. Gli agenti introducono nuove superfici per delega, consenso e accesso. Ecco perché attenersi agli standard aperti come OAuth, costruire un'architettura chiara e applicare pratiche di sicurezza solide non sono solo best practices, ma sono fondamentali. Progettare con cura ora significa che il tuo sistema scalerà con fiducia, flessibilità e fiducia in un futuro potenziato dall'AI.