AI-agentautentisering: användningsfall och identitetsbehov

2025 formar sig till att bli AI:s år. Med den snabba tillväxten av LLM:er och agentupplevelser får vi ofta fråga: Hur omfamnar vi denna nya era? Och vilka är de nya användningsfallen för AI-agentautentisering och auktorisation? I den här artikeln kommer vi att utforska den typiska agentupplevelsen och peka ut säkerhets- och autentiseringsscenarier längs vägen.

ChatGPT-operatörens autentiseringsupplevelse#

Jag köpte nyligen ChatGPT Operatör och utforskade några vanliga arbetsflöden. Ett exempel var att boka en vistelse i Tokyo, Japan. Operatören gjorde det otroligt enkelt att hitta ett lämpligt rum baserat på min prompt.

Vid utcheckning bad den mig att logga in och överlämnade sedan kontrollen tillbaka till mig.

Denna upplevelse gjorde mig obekväm. Trots att jag hade kontroll och agenten inte kunde logga in åt mig, var jag ändå tvungen att ange min e-post och lösenord i operatörens webbläsare. Detta innebär att om du loggar in på din e-post (eller någon tjänst) genom operatören lagras dina uppgifter i cookies.

OpenAI:s operatör anger att den aldrig lagrar användaruppgifter och följer efterlevnadsstandarder som SOC II. Men när tredje parts agenter interagerar med externa tjänster å dina vägnar ökar säkerhetsriskerna avsevärt.

Generellt sett är det en dålig idé att direkt ge en agent åtkomst till ditt konto och dina uppgifter.

Det finns fortfarande mycket utrymme för förbättring. I nästa avsnitt kommer jag att dyka in i olika autentiserings- och hanteringsmetoder för uppgifter och väga deras för- och nackdelar.

Som den här X-trådar diskuterade.

Hur hanteras uppgifter, och vilka säkerhetsrisker finns det?#

Direkta uppgifter till AI-agenten#

I denna metod anger AI-agenten plaintext-uppgifter (som e-post och lösenord) å dina vägnar. Till exempel kan en AI-agent begära dina inloggningsuppgifter och ange dem åt dig.

Men denna metod innebär säkerhetsrisker, eftersom den kan exponera känslig information. Om implementering är nödvändig är det säkrare att integrera en lösenordshanterare eller ett hanteringssystem för hemligheter. Dessutom kan begränsning av hur länge uppgifter lagras hjälpa till att minimera risken för läckor.

Istället för plaintex-uppgifter erbjuder Personliga Åtkomsttoken (PATs) ett säkrare sätt att bevilja åtkomst utan att kräva ett lösenord eller interaktiv inloggning. PATs är användbara för CI/CD, skript och automatiserade applikationer som behöver åtkomst till resurser programmatiskt. För att förbättra säkerheten är det bäst att begränsa PAT-omfång, ställa in utgångstider och tillåta återkallelse för att förhindra läckor och kontokapningar.

Användardelegation via OAuth#

OAuth (Open Authorization) är en allmänt använd standard för delegerad auktorisation på webben. Det låter användare bevilja en tredje parts applikation begränsad åtkomst till sina data på en annan tjänst utan att dela sina inloggningsuppgifter.

I princip löser OAuth problemet med säker åtkomstdelegering: till exempel kan du auktorisera en reseapp att läsa din Google Kalender utan att ge appen ditt Google-lösenord. Detta uppnås genom att låta användaren autentisera sig med dataleverantören (t.ex. Google) och sedan utfärda tokens till tredje parts app istället för att exponera användarens uppgifter.

Ett bättre sätt att hantera detta scenario är att auktorisera ChatGPT Operatör (eller någon annan agent) att läsa och skriva på Airbnb utan att dela ditt lösenord eller dina uppgifter. Istället för att låta operatören logga in direkt kan du bevilja åtkomst genom en säker auktorisationsprocess.

Enligt mig finns det flera sätt som OpenAI Operatör kan förbättra tillit och identitetssäkerhet.

1. Flytta inloggningsprocessen utanför operatören: Hantera användarinloggningen utanför ChatGPT Operatör. Detta innebär att du kanske klickar på en “Logga in med [Tjänst]”-knapp och omdirigeras till tjänstens säkra inloggningssida för att autentisera dig själv, helt utanför chatten eller ChatGPT-operatören. Till exempel, om det fanns en Airbnb-plugin, skulle du skickas till Airbnbs webbplats för att ange dina uppgifter och auktorisera ChatGPT, och sedan skulle pluginen få en token. ChatGPT får endast en tillfällig åtkomsttoken eller nyckel, som ger begränsad åtkomst (t.ex. “läs min resväg”), istället för att någonsin se ditt faktiska lösenord.

2. Låt användaren genomföra samtyckesflödet innan AI-agenten utför några uppgifter. Detta tillvägagångssätt är liknande hur många produkter hanterar integrationer, marknader och anslutna tjänster.

   Anslutningssidor för Notion

   Här är ett annat exempel, precis som Slacks marknadsintegrering med Notion. Slack begär åtkomst till Notions specifika arbetsyta, det kan läsa artiklarna och presentera dem i dina Slack-kanaler.

Samtidigt ger Slack också en samtyckessida för att auktorisera Notion att få tillgång till arbetsytan under denna process.

ChatGPT Operatör bör anta ett liknande tillvägagångssätt genom att integrera OAuth, vilket gör det möjligt för agenten att säkert få åtkomst till flera tredje parts tjänster. På så sätt kan den erhålla åtkomsttokens med de nödvändiga behörigheterna för att utföra uppgifter säkert.

Stega upp autentisering för känsliga åtgärder#

En AI-agent kan hantera rutinuppgifter självständigt och autonomt, men för högriskan åtgärder krävs ytterligare verifiering för att säkerställa säkerhet — som att skicka medel eller ändra säkerhetsinställningar — användaren måste verifiera sin identitet genom flerfaktorsautentisering (MFA). Detta kan göras via push-notifikationer, engångslösenord (OTPs), eller biometrisk bekräftelse.

Men frekvent stega upp autentisering kan leda till användarfrustration, speciellt om det utlöses för ofta. Så agent-specifik upplevelse behöver tänka på användarupplevelsen längs vägen inom detta nya paradigm.

För att förbättra säkerheten utan att kompromissa med användarupplevelsen bör adaptiv autentisering och MFA användas för att avgöra när ytterligare verifiering är nödvändig. Riskbaserade utlösare, såsom IP-ändringar eller ovanligt beteende, hjälper till att minimera onödiga autentiseringsförfrågningar.

Federerad identitet och single sign-On (SSO) för multi-agent ekosystem#

I ett multi-agent företagsekosystem behöver AI-agenter ofta interagera över olika plattformar. För att förenkla autentisering autentiserar användare en gång via en identitetsleverantör (IdP) såsom Okta, Azure AD, eller Google Workspace. Agenterna autentiserar då med SAML, OpenID Connect (OIDC), med åtkomst hanterat genom rollbaserad (RBAC) eller attributbaserad (ABAC) åtkomstkontroll.

Detta tillvägagångssätt eliminerar behovet för användare att logga in flera gånger medan det förbättrar säkerhet och efterlevnad genom centraliserad identitetshantering. Det möjliggör också dynamiska åtkomstpolicys, vilket säkerställer att agenter verkar inom definierade behörigheter.

Omfångs- och rättighetshantering#

Eftersom operatörer och agenter kan verka på användares vägnar är det viktigt att ge människor tillräcklig kontroll och noggrant definiera AI-agenters behörigheter. Två viktiga principer att följa är:

1. Minimala rättigheter – Ge endast de rättigheter som är nödvändiga för uppgiften.
2. Tidkänslig åtkomst – Begränsa åtkomstens varaktighet för att minska säkerhetsriskerna.

Rollbaserad åtkomstkontroll (RBAC) hjälper till att hantera en agents omfång genom att tilldela specifika roller för vissa uppgifter. För mer detaljerad kontroll tillåter Attributbaserad Åtkomstkontroll (ABAC) dynamisk, kontextmedveten rättighetshantering, vilket säkerställer att AI-agenter endast har tillgång till vad de behöver när de behöver det.

Anslut MCP-servrar med Auth#

MCP har blivit alltmer populärt för att förbättra AI-agenter genom att tillhandahålla mer kontextuell information, vilket förbättrar deras övergripande prestation och användarupplevelse.

Varför är MCP-servern relaterad till autentisering och varför spelar det roll?#

Vi skrev tidigare en artikel för att hjälpa dig förstå vad en MCP-server är.

En MCP-server är en nyckelkomponent i Modell Kontext Protokoll, agerar som en bro mellan AI-modeller och externa datakällor. Den möjliggör realtidsförfrågningar och datahämtning från tjänster såsom Slack, Gmail och Google Kalender. Genom att bygga en MCP-server kan du ansluta dessa externa tjänster till LLM:er, vilket förbättrar dina AI-drivna applikationer med bättre kontext och smartare uppgiftsutförande.

Till skillnad från Retrieval-Augmented Generation (RAG)-system, som kräver generering av inbäddningar och lagring av dokument i vektordatabaser, en MCP-server åtkommer data direkt utan tidigare indexering. Detta innebär att informationen är inte bara mer exakt och aktuell utan också integrerar med lägre beräkningskostnader och utan att kompromissa med säkerheten.

Referens: https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained

För AI-agenter som använder en MCP-server sker flera interaktioner mellan MCP-server, LLM, agent, och användare.

I dagens AI-drivna värld, där agenter hanterar flera uppgifter över olika tjänster, blir integrationen med flera MCP-servrar alltmer efterfrågad.

Agentautentisering växer fram — ditt produkt bör anpassa sig#

Ett bra exempel är Composio.dev, en utvecklarfokuserad integrationsplattform som förenklar hur AI-agenter och LLM:er ansluter till externa appar och tjänster. Kallat “Auth för AI-agenter att agera på användares vägnar,” tillhandahåller det i princip en samling av MCP-servrar (kontakter) som lätt kan integreras i AI-drivna produkter.

Som någon i autentiseringsområdet, men i verkligheten är det bara en liten del av det bredare CIAM (Customer Identity and Access Management)-fältet. Det de har byggt är faktiskt en samling av MCP-servrar (kontakter) — användbara, men bara en bråkdel av vad fullständiga CIAM-lösningar omfattar.

Om vi bygger vidare på de tidigare exemplen, om vi betraktar Google Drive (externa tjänster) som en MCP-server istället för Airbnb, blir det mer än bara en tredje parts integration—det fungerar som en extern datakälla. Detta möjliggör att agenten får tillgång till kontextuell information, interagerar med LLM:n, och potentiellt får åtkomstbehörigheter att skapa, läsa, uppdatera och ta bort (CRUD) filer.

Men de grundläggande autentiserings- och auktorisationskraven förblir desamma.

Använd Logto för att hantera autentisering för dina agentprodukter#

Logto är en mångsidig CIAM-lösning som stödjer SaaS och AI-agentprodukter, vilket gör autentisering och auktorisation sömlös. Här är varför:

1. Hanterad autentisering för AI-agentprodukter – Logto stödjer OAuth 2.0, SAML, API-nycklar, Personliga Åtkomsttoken och JWT, vilket möjliggör enkel integration med flera MCP-servrar. Du kan till och med bygga din egen MCP-server och ansluta den till Logto, tack vare dess öppen standard bas.
2. Identitetsleverantörens (IdP) kapaciteter – När din produkt har etablerade användare kan Logto fungera som en IdP, förvandla din tjänst till en MCP-server och integrera det i AI-ekosystemet.
3. Avancerad auktorisation
   1. Rollbaserad åtkomstkontroll (RBAC) för hantering av användarroller
   2. Anpassad JWT-baserad ABAC för detaljerad, dynamisk åtkomstkontroll
4. Förbättrad säkerhet – Funktioner som flerfaktorsautentisering (MFA) och stega upp autentisering hjälper till att säkra kritiska åtgärder och förbättra agentsäkerhet.

Har du frågor? Kontakta vårt team för att lära dig hur Logto kan förbättra din AI-agentupplevelse och möta dina säkerhetsbehov.