Vad som har förändrats och vad som inte har det inom Auth och Identity för agentiska appar

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.

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

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.

Vad som inte ändras i den agentiska världen#

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.

Behöver en agent en unik identitet?#

Mycket hype och FOMO-innehåll driver idén att, eftersom agenter blir mer vanliga, vi behöver ett system för hantering av agentidentiteter.

Svaret är: ja och nej.

Ja, eftersom vi introducerar ett nytt lager mellan människor och maskiner. Det finns reella behov av att:

• Hantera och identifiera agenter
• Tilldela unika ID:n
• Spåra loggar
• Granska åtgärder (för att veta om en uppgift utfördes av en människa eller en agent)

Men i de flesta tekniska fall finns det inget behov av att skapa ett formellt koncept av "Agentidentitet".

Agent ≠ Användare, ≠ Tjänstekonto.

Bakom varje agent finns det fortfarande en användare och användarens identitet är vanligtvis tillräcklig.

Idag agerar de flesta agenter:

• Baserat på användarauktorisation (t.ex. OAuth-tokens)
• Utför logik eller gör ett API-anrop
• Utför kortlivade, engångsuppgifter (utan behov av spårning)

I den meningen är agenten bara ett verktyg som en funktion och behöver inte ett globalt unikt ID.

Till exempel:

• En GPT-agent som anropar din kalender-API behöver bara den åtkomst du har gett.
• En LangChain-agent behöver inte en identitet så länge den kan anropa rätt verktyg, det fungerar.

Även före AI hade vi konceptet av maskin-till-maskin (M2M) autentisering.

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:

1. SSO för företagskunder
2. Arbetsplats- eller hyresgästanivåseparation
3. Agente delegeringspolicyer på organisationsnivå (t.ex. kontrollera vad agenter kan göra över team)
4. 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:

1. Logga in med sin befintliga SSO
2. Kontrollera vad agenterna kan komma åt (t.ex. interna verktyg, dokumentsystem)
3. 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.

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

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

Du behöver fortfarande säkerhetslager för att hålla dina agentdrivna appar säkra#

Oavsett om det är en agentapp eller inte, är dessa grundläggande säkerhetslager nödvändiga för att skydda dina användare och system:

• Multifaktorautentisering (MFA)

  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.

• CAPTCHA

  Blockerar automatiserat missbruk som inloggningsbombning eller botdrivna registreringar.

  Exempel: Visa CAPTCHA efter 3 misslyckade inloggningsförsök för att förhindra brute-force-attacker.

• Rollbaserad åtkomstkontroll (RBAC)

  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.

• Lösenordsfritt inloggning

  Förbättrar användarupplevelsen och minskar risken för svaga lösenord.

  Exempel: Låt användare logga in med en magisk länk som skickas till deras e-post eller en biometrisk prompt som Face ID.

Dessa funktioner gäller både traditionella och agentbaserade appar, särskilt eftersom agenter börjar verka över känslig data och system.

Vad som har ändrats i den agentiska världen#

Autentisering är viktigare än någonsin#

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.

Det är kritiskt i en värld av agentiska, anslutna system. Läs denna artikel för att se varför OAuth och OIDC är viktiga

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.