Cosa è cambiato e cosa non è cambiato in Auth e Identità per le app agentiche
Con l'aumentare delle capacità e delle connessioni degli agenti AI, la creazione di prodotti agentici sicuri e scalabili richiede una solida base in autenticazione e identità. Questa guida divide ciò che è cambiato, ciò che non è cambiato, e ciò che ogni costruttore deve sapere per navigare il nuovo panorama.
GuamianProduct & Design
Smetti di sprecare settimane sull'autenticazione degli utenti
Lancia app sicure più velocemente con Logto. Integra l'autenticazione degli utenti in pochi minuti e concentrati sul tuo prodotto principale.
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.
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.
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 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.
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:
SSO per clienti aziendali
Separazione a livello di spazio di lavoro o tenant
Politiche di delega degli agenti a livello organizzativo (ad esempio, controllare cosa possono fare gli agenti su team diversi)
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:
Effettuare l'accesso con il proprio SSO esistente
Controllare a cosa possono accedere gli agenti (ad esempio, strumenti interni, sistemi di documenti)
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.
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.
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.
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.
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.
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.
