AI-agent-authenticatie: gebruiksscenario's en identiteitsbehoeften
2025 is het jaar van AI. Naarmate LLM's en agentervaringen evolueren, ontstaan er nieuwe uitdagingen op het gebied van authenticatie en autorisatie. Dit artikel onderzoekt interacties met AI-agenten en belicht belangrijke veiligheid- en authenticatiescenario's.
GuamianProduct & Design
Stop met weken verspillen aan gebruikersauthenticatie
Lanceer veilige apps sneller met Logto. Integreer gebruikersauthenticatie in minuten en focus op je kernproduct.
2025 vormt zich tot het jaar van AI. Met de snelle groei van LLM's en agentervaringen wordt ons vaak gevraagd: Hoe omarmen we dit nieuwe tijdperk? En wat zijn de nieuwe gebruiksscenario's voor AI-agentauthenticatie en -autorisatie? In dit artikel zullen we de typische agentervaring verkennen en wijzen we op de veiligheids- en auth-scenario's onderweg.
Ik heb onlangs de ChatGPT Operator gekocht en een aantal veelvoorkomende workflows verkend. Een voorbeeld was het boeken van een verblijf in Tokio, Japan. De Operator maakte het ongelooflijk eenvoudig om een geschikte kamer te vinden op basis van mijn prompt.
Tijdens het afrekenen vroeg het me om in te loggen en gaf het de controle weer aan mij.
Deze ervaring maakte me ongemakkelijk. Hoewel ik de controle had en de agent niet voor mij kon inloggen, moest ik nog steeds mijn e-mail en wachtwoord invoeren in de browser van de Operator. Dit betekent dat als je inlogt op je e-mail (of een andere dienst) via de Operator, je inloggegevens worden opgeslagen in cookies.
De Operator van OpenAI stelt dat het nooit gebruikersgegevens opslaat en voldoet aan nalevingsnormen zoals SOC II. Echter, wanneer derden tussenpersonen zijn die namens jou met externe diensten communiceren, nemen de veiligheidsrisico's aanzienlijk toe.
Over het algemeen is het direct geven van je accounttoegang en -gegevens aan een agent een slecht idee.
Er is nog veel ruimte voor verbetering. In de volgende sectie ga ik dieper in op verschillende benaderingen van authenticatie en credential management, met het afwegen van hun voor- en nadelen.
Bij deze benadering voert de AI namens jou platte tekst-inloggegevens (zoals e-mail en wachtwoord) in. Een AI-agent kan bijvoorbeeld je inloggegevens opvragen en ze voor je invoeren.
Deze methode brengt echter veiligheidsrisico's met zich mee, aangezien het gevoelige informatie kan blootstellen. Als implementatie noodzakelijk is, is het veiliger om een wachtwoordbeheerder of geheimbeheeringssysteem te integreren. Bovendien kan het beperken van hoelang inloggegevens worden opgeslagen, helpen bij het minimaliseren van het risico op datalekken.
In plaats van platte tekst-inloggegevens, bieden Personal Access Tokens (PATs) een veiligere manier om toegang te verlenen zonder een wachtwoord of interactieve inlog te vereisen. PATs zijn nuttig voor CI/CD, scripts en geautomatiseerde applicaties die programmeerbaar toegang nodig hebben tot bronnen. Om de veiligheid te verhogen, is het het beste om PAT-scope te beperken, vervaltijden in te stellen, en herroeping toe te staan om lekken en accountkaping te voorkomen.
OAuth (Open Authorization) is een veelgebruikt standaard voor gedelegeerde autorisatie op het web. Het stelt gebruikers in staat om een derde partij-applicatie beperkte toegang te geven tot hun gegevens op een andere dienst zonder hun inloggegevens te delen.
In wezen lost OAuth het probleem van veilige toegangsdelegatie op: je kunt bijvoorbeeld een reisapplicatie machtigen om je Google Agenda in te zien zonder de app je Google-wachtwoord te geven. Dit wordt bereikt door de gebruiker te laten verifiëren bij de dataleverancier (bijvoorbeeld Google) en vervolgens tokens uit te geven aan de derde partij-app in plaats van de inloggegevens van de gebruiker bloot te stellen.
Een betere manier om dit scenario te benaderen is door de ChatGPT Operator (of een andere agent) te machtigen om op Airbnb te lezen en te schrijven zonder je wachtwoord of inloggegevens te delen. In plaats van de Operator direct te laten inloggen, kun je toegang verlenen via een veilig autorisatieproces.
Naar mijn mening, als de Operator van OpenAI vertrouwen en identiteitsveiligheid wil verbeteren, zijn er verschillende manieren om dit te bereiken.
Plaats het inlogproces buiten de Operator: Handel het gebruikersinlogproces buiten de ChatGPT Operator af. Dit betekent dat je misschien op een 'Inloggen met [Dienst]'-knop klikt en wordt doorverwezen naar de veilige loginpagina van de dienst om jezelf te verifiëren, volledig buiten de chat of ChatGPT Operator. Als er bijvoorbeeld een Airbnb-plug-in was, zou je naar de website van Airbnb worden gestuurd om je inloggegevens in te voeren en ChatGPT te machtigen, waarna de plug-in een token zou ontvangen. ChatGPT ontvangt alleen een tijdelijk toegangstoken of sleutel, die beperkte toegang verleent (bijvoorbeeld 'lees mijn reisschema'), in plaats van ooit je daadwerkelijke wachtwoord te zien.
Laat de gebruiker de toestemmingsflow voltooien voordat de AI-agent enige taken uitvoert. Deze benadering is vergelijkbaar met hoe veel producten omgaan met integraties, marktplaatsen en verbonden diensten.
Notion-verbindingspagina's
Hier is nog een voorbeeld, net zoals een integratie van de Slack-marktplaats met Notion. Slack vraagt toegang tot de specifieke werkruimte van Notion, kan de artikelen lezen en presenteren ze in je Slack-kanalen.
Tegelijkertijd biedt Slack ook een toestemmingspagina om Notion te machtigen om toegang tot de werkruimte te krijgen tijdens dit proces.
ChatGPT Operator zou een vergelijkbare benadering moeten volgen door OAuth te integreren, zodat de agent veilig toegang kan krijgen tot meerdere diensten van derden. Op deze manier kan het toegangstokens verkrijgen met de benodigde toestemmingen om veilig taken uit te voeren.
Een AI-agent kan routinetaken zelfstandig en autonoom afhandelen, maar voor risicovolle acties, zoals het verzenden van geld of het wijzigen van beveiligingsinstellingen, is extra verificatie vereist om de veiligheid te waarborgen. De gebruiker moet zijn identiteit verifiëren via multi-factor authenticatie (MFA), wat kan worden gedaan via pushmeldingen, eenmalige wachtwoorden (OTPs) of biometrische bevestiging.
Frequent verhoogde authenticatie kan echter leiden tot frustratie bij gebruikers, vooral als het te vaak wordt geactiveerd. Daarom is het belangrijk dat een agent-specifieke ervaring rekening houdt met de gebruikerservaring binnen dit nieuwe paradigma.
Om de veiligheid te verbeteren zonder in te boeten aan de gebruikerservaring, moet adaptieve authenticatie en MFA worden gebruikt om te bepalen wanneer extra verificatie nodig is. Risicogebaseerde triggers, zoals IP-wijzigingen of ongewoon gedrag, helpen onnodige authenticatieverzoeken te minimaliseren.
Gefedereerde identiteit en Single Sign-On (SSO) voor multiaagentsystemen#
In een multiaagentenbedrijfssysteem moeten AI-agenten vaak interactie hebben over verschillende platforms. Om authenticatie te stroomlijnen, authentiseren gebruikers eenmaal via een identiteitsprovider (IdP) zoals Okta, Azure AD of Google Workspace. De agenten authenticeren vervolgens met gebruik van SAML, OpenID Connect (OIDC), met toegang beheerd via rolgebaseerde (RBAC) of attribuutgebaseerde (ABAC) toegangscontrole.
Deze aanpak elimineert de noodzaak voor gebruikers om meerdere keren in te loggen en verbetert de veiligheid en naleving door centraal identiteitsbeheer. Het maakt ook dynamische toegangsbeleid mogelijk, zodat agenten binnen gedefinieerde toestemmingen werken.
Aangezien Operators en Agenten kunnen handelen namens gebruikers, is het belangrijk mensen voldoende controle te geven en AI-agent-permissies zorgvuldig te definiëren. Twee belangrijke principes om te volgen zijn:
Minimaal privileges – Alleen de toestemmingen verlenen die nodig zijn voor de taak.
Tijdgevoelige toegang – Beperk de duur van toegang om beveiligingsrisico's te verminderen.
Rolgebaseerde toegangscontrole (RBAC) helpt de reikwijdte van een agent te beheren door specifieke rollen toe te wijzen voor bepaalde taken. Voor meer gedetailleerde controle staat attribuutgebaseerde toegangscontrole (ABAC) dynamisch, contextafhankelijk toestemmingsbeheer toe, waardoor AI-agenten alleen toegang hebben tot wat ze nodig hebben wanneer ze het nodig hebben.
MCP is steeds populairder geworden voor het verbeteren van AI-agenten door meer contextuele informatie te bieden en hun algehele prestaties en gebruikerservaring te verbeteren.
Waarom is de MCP-server gerelateerd aan authenticatie en waarom is dit belangrijk?#
Een MCP-server is een sleutelonderdeel van het Model Context Protocol en fungeert als een brug tussen AI-modellen en externe gegevensbronnen. Het maakt realtime query's en gegevensopvragingen mogelijk van diensten zoals Slack, Gmail en Google Agenda. Door een MCP-server te bouwen, kun je deze externe diensten verbinden met LLM's, waardoor je AI-aangedreven applicaties worden verbeterd met betere context en slimmere taakuitvoering.
In tegenstelling tot Retrieval-Augmented Generation (RAG)-systemen, die vereisen dat embeddingen worden gegenereerd en documenten worden opgeslagen in vectordatabases, heeft een MCP-server toegang tot gegevens rechtstreeks zonder voorafgaande indexering. Dit betekent dat de informatie niet alleen preciezer en actueler is, maar ook wordt geïntegreerd met een lagere rekenkundige overhead en zonder afbreuk te doen aan de veiligheid.
Voor AI-agenten die een MCP-server gebruiken, vinden er meerdere interacties plaats tussen de MCP-server, LLM, agent en user.
In de hedendaagse AI-gedreven wereld, waar agenten meerdere taken op verschillende diensten beheren, wordt het steeds meer gevraagd om ze te integreren met meerdere MCP-servers.
Agentauthenticatie is in opkomst — je product moet zich aanpassen#
Een goed voorbeeld is Composio.dev, een ontwikkelaargericht integratieplatform dat vereenvoudigt hoe AI-agenten en LLM's verbinding maken met externe apps en diensten. Dubbed “Auth for AI Agents to Act on Users’ Behalf,” het biedt in wezen een verzameling MCP-servers (connectoren) die eenvoudig kunnen worden geïntegreerd in AI-aangedreven producten.
Als iemand in de auth-ruimte, maar in werkelijkheid is het slechts een klein onderdeel van het bredere CIAM (Customer Identity and Access Management) veld. Wat ze hebben gebouwd is eigenlijk een verzameling MCP-servers (connectoren) - nuttig, maar slechts een fractie van wat volledige CIAM-oplossingen omvatten.
Als we kijken naar de eerdere voorbeelden, als we Google Drive (externe diensten) als een MCP-server beschouwen in plaats van Airbnb, dan wordt het meer dan alleen een derde partij-integratie—het fungeert als een externe gegevensbron. Dit stelt de agent in staat toegang te krijgen tot contextuele informatie, te communiceren met de LLM en mogelijk machtigingen te krijgen om bestanden te creëren, lezen, bijwerken en verwijderen (CRUD).
De kernvereisten voor authenticatie en autorisatie blijven echter hetzelfde.
Gebruik Logto voor het afhandelen van authenticatie voor je agentproducten#
Logto is een veelzijdige CIAM-oplossing die SaaS- en AI-agentproducten ondersteunt en maakt authenticatie en autorisatie naadloos. Hier is waarom:
Beheerde authenticatie voor AI-agentproducten – Logto ondersteunt OAuth 2.0, SAML, API-sleutels, Personal Access Tokens en JWT, waardoor eenvoudige integratie met meerdere MCP-servers mogelijk is. Je kunt zelfs je eigen MCP-server bouwen en deze aan Logto koppelen dankzij de basis van open standaarden.
Identity provider (IdP) mogelijkheden – Zodra je product gebruikers heeft opgebouwd, kan Logto fungeren als een IdP, je dienst transformeren tot een MCP-server en deze integreren in het AI-ecosysteem.
Geavanceerde autorisatie
Rolgebaseerde toegangscontrole (RBAC) voor het beheren van gebruikersrollen
Aangepaste JWT-gebaseerde ABAC voor gedetailleerde, dynamische toegang
Verhoogde beveiliging – Functies zoals multi-factor authenticatie (MFA) en verhoogde authenticatie helpen bij het beveiligen van kritieke acties en het verbeteren van de veiligheid van agenten.
Heb je vragen? Neem contact op met ons team om te leren hoe Logto je AI-agentervaring kan verbeteren en aan je beveiligingsbehoeften kan voldoen.
Notion-verbindingspagina's
Referentie: