Vad som har förändrats och vad som inte har det inom Auth och Identity för agentiska appar
När AI-agenter blir mer kapabla och anslutna, kräver konstruktion av säkra och skalbara agentiska produkter en stark grund inom autentisering och identitet. Denna guide bryter ner vad som har förändrats, vad som inte har det, och vad varje utvecklare behöver veta för att navigera i det nya landskapet.
GuamianProduct & Design
Sluta slösa veckor på användarautentisering
Lansera säkra appar snabbare med Logto. Integrera användarautentisering på några minuter och fokusera på din kärnprodukt.
Nyligen granskade jag denna artikel, och agentautentisering nämndes:
Vi ser antydningar om hur detta skulle kunna se ut. Den senaste MCP-specifikationen inkluderar till exempel ett auktorisations ramverk baserat på OAuth 2.1, vilket signalerar en möjlighet att gå mot att ge AI-agenter specificerade, återkallbara tokens istället för råa hemligheter. Vi kan föreställa oss ett scenario där en AI-agent inte får dina faktiska AWS-nycklar, utan istället erhåller en kortlivad behörighet eller en kapabilitetstoken som låter den utföra en snävt definierad åtgärd.
Många vänner och personer som inte är inom säkerhets- eller CIAM-området får intrycket att detta är något nytt, men det är det definitivt inte. OAuth är ett standardprotokoll för tokenbaserad auktorisation som involverar tokens med specificerade behörigheter (åtkomsttokens). Dessa är tidskänsliga och begränsade i omfång, vilket garanterar säkerhet och korrekt åtkomstkontroll till resurser och tjänster. På den globala SaaS-marknaden (pre-AI) är de flesta professionella identitetslösningar redan byggda på detta.
När du ansluter ditt Google-konto till en tredje parts app som Notion eller Zoom, använder den OAuth för att begära endast de nödvändiga behörigheterna, såsom åtkomst till din kalender eller kontakter, utan att någonsin exponera ditt Google-lösenord. Du kan återkalla den åtkomsten när som helst från dina Google-kontoinställningar. Detta delegerade åtkomstmönster är precis vad OAuth är utformat för och det är samma grund som idag utvidgas till agentiska tillämpningar.
Autentisering är inte ny, fortfarande baserad på OAuth 2.1#
Det finns två större protokoll som håller på att växa fram: MCP och A2A.
MCP fokuserar på interaktionen mellan LLMs och ditt apps verktyg och sammanhang.
A2A fokuserar på att möjliggöra utbyte av uppgifter mellan agenter.
Men när det gäller autentisering och auktorisation, förlitar sig båda fortfarande på väl etablerade industristandarder som OAuth.
MCP-auktoriseringsservrar MÅSTE implementera OAuth 2.1 med lämpliga säkerhetsåtgärder för både konfidentiella och publika klienter.
A2A-klienten ansvarar för att erhålla de nödvändiga behörighetsmaterialen (t.ex. OAuth 2.0-tokens, API-nycklar, JWTs) genom processer som är externa för själva A2A-protokollet. Detta kan involvera OAuth-flöden (auktoriseringskod, klientreferenser), säker nyckeldistribution, etc.
Som Google säger:
Istället för att uppfinna nya, proprietära standarder för säkerhet och drift, strävar A2A efter att sömlöst integreras med befintlig företagsinfrastruktur och allmänt antagna bästa praxis.
M2M betyder automatiserat datautbyte mellan tjänster, utan att en människa är inblandad.
I detta sammanhang används ofta en klientapp eller ett tjänstekonto för autentisering.
Om du verkligen vill att din agent ska ha en identitet (för granskning, etc.), kan du använda app-ID och det räcker.
Du måste fortfarande definiera arkitekturen av din produkt#
Detta har inte ändrats. Oavsett om din produkt involverar agenter eller inte, beror arkitekturen av ditt identitetssystem på vem dina användare är och hur ditt system interagerar med dem.
Om du bygger en konsumentinriktad agentisk produkt:
Du behöver lätta inloggningsmetoder (e-post, telefon, social inloggning) och en enhetlig användarpool för att hantera individer som interagerar med din app och dess agenter. Agenter agerar på uppdrag av dessa användare med delegerade tokens (t.ex. via OAuth).
Exempel:
Föreställ dig att du bygger en AI-schemaläggningsassistent eller en AI-driven kalenderbot.
Varje användare loggar in med sitt personliga Google-konto. Ditt system använder OAuth för att få tillåtelse att komma åt deras kalender. Agenten har inte sin egen identitet, den använder användarens token för att schemalägga möten, kontrollera tillgänglighet eller skicka påminnelser. Identitetsarkitekturen är enkel: en global användarpool, tokenlagring och samtyckesspårning per användare.
Om du bygger en B2B agentisk plattform:
Du behöver stödja identitet på organisationsnivå, inte bara individuella användare. Det inkluderar:
SSO för företagskunder
Arbetsplats- eller hyresgästanivåseparation
Agente delegeringspolicyer på organisationsnivå (t.ex. kontrollera vad agenter kan göra över team)
Synlighet och loggar på administratörsnivå över all agentaktivitet på uppdrag av anställda
Exempel:
Föreställ dig att du bygger en plattform som tillhandahåller AI-agenter för att automatisera interna arbetsflöden — som en säkerhetsanalytikerbot som övervakar loggar och skickar varningar, eller en säljassistent som skriver utkast till e-postmeddelanden från CRM-data.
Varje företag som använder din plattform vill:
Logga in med sin befintliga SSO
Kontrollera vad agenterna kan komma åt (t.ex. interna verktyg, dokumentsystem)
Se vilken agent som utförde vilken uppgift, under vilket anställdes auktorisation
I detta fall behöver din identitetsarkitektur stödja en multihyrestagsdesign, specificerade agentbehörigheter och organisationsspecifika policyer. Agenter agerar fortfarande på uppdrag av användare, men behörigheter och identitetsgränser är verkställda per företagskund.
I båda fallen definierar identitetsmodellen hur agenter agerar, vad de kan komma åt och hur ditt system garanterar ansvar.
Använd denna guide för att hjälpa dig att planera din identitet och produktarkitektur.
Förhindrar obehörig åtkomst även om inloggningsuppgifter är komprometterade.
Exempel: Om en agent hjälper dig att utföra en högriskåtgärd, som att göra en transaktion eller ändra identitetsinställningar, bör den hålla en människa i loopen och använda MFA för att bekräfta åtgärden innan den fortsätter.
Säkerställer att användare och agenter bara har åtkomst till vad de är tillåtna.
Exempel: En AI-assistent i en företagets arbetsyta kan läsa kalenderhändelser, men kan inte komma åt faktureringsdata om den inte uttryckligen tilldelas en högre roll.
När agenter och multi-agent arbetsflöden växer fram, ser vi nya användningsfall där användare, agenter, API:er och MCP-servrar alla interagerar. Antalet och variationen av dessa scenarion växer snabbt, mycket mer än tidigare.
Närhelst dessa anslutningar sker, blir auktorisation mer synlig än någonsin. Användare måste ge tydligt samtycke, och behörigheter behöver noggrant hanteras över system. Därför talar alla nu om att hålla en "människa i loopen" för att säkerställa att användare har tillräcklig kontroll och synlighet över vad agenter kan göra, och vilka omfång de är auktoriserade för.
Din AI-app kan behöva integreras med många externa tjänster#
MCP-ekosystemet expanderar, vilket innebär att din app inte längre bara är en fristående tjänst: den är en del av ett större, anslutet nätverk.
För att tillhandahålla rik, användbar kontext till LLMs, kan dina agenter behöva:
Åtkomst till flera MCP-servrar
Exempel: Föreställ dig en AI-projektledare som hämtar uppdateringar från Jira, teamets tillgänglighet från Google Kalender, och försäljningsdata från Salesforce och var och en av dessa kan drivas av en annan MCP-server. För att generera en veckorapport måste agenten säkert interagera med flera datakällor. Det är där autentisering och auktorisation kommer in, för att skydda varje anslutning och kontrollera hur data delas.
Anslutning till externa API:er och verktyg
Exempel: En kundsupportagent kan behöva hämta orderhistorik från Shopify, uppdatera biljetter i Zendesk och trigga arbetsflöden i Slack. Utan integrationer blir agenten isolerad och ineffektiv.
Eftersom agenter tar på sig mer ansvar, blir integration nyckeln till nytta. Din AI-produkt handlar inte bara om vad den kan göra på egen hand, den handlar om vad den kan komma åt, orkestrera och resonera över i ett anslutet ekosystem. Därför är det viktigare än någonsin att bygga för interoperabilitet, säkert och flexibelt.
Du behöver omfamna öppna standarder: OAuth/OIDC är viktigare än någonsin#
I AI-eran, växer behovet av säkra, flexibla integrationer. Det gör OAuth 2.0 och OIDC viktigare än någonsin.
Viktiga användningsfall inkluderar:
Fjärr-MCP-servrar: Låt tredje parts agenter säkert få tillgång till din produkt med delegerade tokens.
Tredjepartsintegrationer: Tillåt andra verktyg eller agenter att ansluta till din app (t.ex. en plattform för projektledning) utan att behöva råa behörigheter.
Agentutveckling: Bygg AI-agenter som säkert agerar för användares räkning över tjänster.
Smarta enheter: Använd OAuth/OIDC för saker som AI-drivna anteckningstagare för att autentisera användare och ansluta till molnet — särskilt med minimal användargränssnitt.
Dessa protokoll ger säker, tokenbaserad, användarkonsenterad åtkomst.
Designa för förtroende och skala i en era av agentisk mjukvara#
När agentiska produkter utvecklas, förblir de grundläggande principerna för identitet och auktorisation desamma men kontexten förändras. Agenter introducerar nya ytor för delegering, samtycke och åtkomst. Därför är det att hålla fast vid öppna standarder som OAuth, bygga en tydlig arkitektur, och upprätthålla solida säkerhetspraxis inte bara bästa praxis, de är grundläggande. Att designa med omsorg nu innebär att ditt system kommer att skala med förtroende, flexibilitet och tillit i en AI-driven framtid.
