Wat is er veranderd en wat niet in Auth en Identity voor agentische apps
Naarmate AI-agenten capabeler en meer verbonden worden, vereist het bouwen van veilige en schaalbare agentische producten een sterke basis in authenticatie en identiteit. Deze gids legt uit wat er veranderd is, wat niet, en wat elke bouwer moet weten om het nieuwe landschap te navigeren.
GuamianProduct & Design
Stop met weken verspillen aan gebruikersauthenticatie
Lanceer veilige apps sneller met Logto. Integreer gebruikersauthenticatie in minuten en focus op je kernproduct.
Recentelijk heb ik dit artikel beoordeeld en er werd agent-authenticatie genoemd:
We zien aanwijzingen van hoe dit eruit zou kunnen zien. De nieuwste MCP-specificatie bevat bijvoorbeeld een autorisatieraamwerk gebaseerd op OAuth 2.1, wat aangeeft dat er een mogelijkheid is om over te gaan naar het geven van AI-agenten gescoopt, herroepbare tokens in plaats van onbewerkte geheimen. We kunnen ons een scenario voorstellen waarin een AI-agent niet je daadwerkelijke AWS-sleutels krijgt, maar in plaats daarvan een kortstondige inloggegevens of een vaardigheidstoken ontvangt dat het toestaat om een nauwkeurig gedefinieerde actie uit te voeren.
Veel vrienden en mensen buiten het vakgebied van beveiliging of CIAM krijgen de indruk dat dit iets nieuws is, maar dat is het zeker niet. OAuth is een standaard token-gebaseerd autorisatieprotocol dat tokens met gescooptete permissies (toegangstokens) omvat. Deze zijn tijdgevoelig en beperkt qua omvang, wat de beveiliging en juiste toegang tot middelen en diensten waarborgt. Op de wereldwijde SaaS-markt (voor AI) zijn de meeste professionele identiteit's oplossingen hier al op gebouwd.
Wanneer je je Google-account verbindt met een app van een derde partij zoals Notion of Zoom, gebruikt het OAuth om alleen de noodzakelijke permissies op te vragen, zoals toegang tot je agenda of contacten, zonder ooit je Google-wachtwoord bloot te stellen. Je kunt die toegang op elk moment intrekken via de instellingen van je Google-account. Dit gedelegeerde toegangspatroon is precies waarvoor OAuth is ontworpen en het is dezelfde basis die tegenwoordig wordt uitgebreid naar agentische applicaties.
Auth is niet nieuw, nog steeds gebaseerd op OAuth 2.1#
Er verschijnen twee belangrijke protocollen: MCP en A2A.
MCP richt zich op de interactie tussen LLMs en de tools en context van je app.
A2A richt zich op het mogelijk maken van taakuitwisseling tussen agenten.
Maar als het gaat om authenticatie en autorisatie, blijven beide vertrouwen op goed gevestigde industrienormen zoals OAuth.
MCP-autorisatieservers MOETEN OAuth 2.1 implementeren met passende beveiligingsmaatregelen voor zowel vertrouwelijke als openbare cliënten.
De A2A-client is verantwoordelijk voor het verkrijgen van de nodige inloggegevens materiaal (bijv., OAuth 2.0 tokens, API-sleutels, JWT's) via processen die extern zijn aan het A2A-protocol zelf. Dit kan OAuth-flows (autorisatiecode, cliëntcredentials), beveiligde sleutelverdeling, enz. omvatten.
Zoals Google het verwoordt:
In plaats van nieuwe, gepatenteerde standaarden voor beveiliging en operaties uit te vinden, streeft A2A naar naadloze integratie met bestaande bedrijfsinfrastructuur en breed geaccepteerde best practices.
Veel hype en FOMO-inhoud duwt het idee dat, naarmate agenten gebruikelijker worden, we een systeem nodig hebben voor het beheren van agent-identiteiten.
Het antwoord is: ja en nee.
Ja, omdat we een nieuwe laag introduceren tussen mensen en machines. Er zijn echte behoeften aan:
Het beheren en identificeren van agenten
Unieke ID's toekennen
Logs bijhouden
Acties auditen (om te weten of een taak is uitgevoerd door een mens of een agent)
Echter, in de meeste technische gevallen is er geen behoefte aan het creëren van een formeel concept van "Agent Identity."
Agent ≠ Gebruiker, ≠ Service-account.
Achter elke agent is er nog steeds een gebruiker en de gebruikersidentiteit is meestal voldoende.
Vandaag de dag doen de meeste agenten:
Handelen op basis van gebruikersautorisatie (bijv., OAuth-tokens)
Voeren logica uit of maken een API-aanroep
Voeren kortstondige, eenmalige taken uit (zonder behoefte aan tracking)
In die zin is de agent gewoon een functie-als-een-tool en heeft geen wereldwijd unieke ID nodig.
Bijvoorbeeld:
Een GPT-agent die je Calendar API aanroept heeft alleen de toegang nodig die je verleent.
Een LangChain-agent heeft geen identiteit nodig zolang het de juiste tools kan aanroepen, werkt het.
M2M betekent geautomatiseerde gegevensuitwisseling tussen diensten, zonder mens in de lus.
In deze context gebruikt authenticatie vaak een cliëntapp of serviceaccount.
Als je echt wilt dat je agent een identiteit heeft (voor audit, enz.), kun je de app-ID gebruiken en dat is genoeg.
Je moet nog steeds de architectuur van je product definiëren#
Dit is niet veranderd. Of je product nu agents omvat of niet, de architectuur van je identiteitssysteem hangt af van wie je gebruikers zijn en hoe je systeem met hen omgaat.
Als je een consumentgerichte agentische product bouwt:
Je hebt lichte inlogmethoden nodig (e-mail, telefoon, sociale login), en een verenigd gebruikersbestand om individuen te beheren die interactie hebben met je app en zijn agenten. Agenten handelen namens deze gebruikers met gedelegeerde tokens (bijv., via OAuth).
Voorbeeld:
Stel je bouwt een AI-planningsassistent, of een AI-gedreven kalenderbot.
Elke gebruiker logt in met zijn persoonlijke Google-account. Je systeem gebruikt OAuth om toestemming te krijgen om toegang te krijgen tot hun agenda. De agent heeft geen eigen identiteit, het gebruikt het token van de gebruiker om vergaderingen te plannen, beschikbaarheid te controleren, of herinneringen te sturen. De identiteitsarchitectuur is eenvoudig: één wereldwijd gebruikersbestand, tokenopslag en toestemmingsregistratie per gebruiker.
Als je een B2B agentisch platform bouwt:
Je moet ondersteuning bieden voor identiteit op organisatieniveau, niet alleen individuele gebruikers. Dat omvat:
SSO voor zakelijke klanten
Werkruimte- of tenantniveau scheiding
Agent-delegatiebeleid op organisatieniveau (bijv., controle over wat agenten kunnen doen binnen teams)
Admin-niveau zichtbaarheid en logs voor alle agentactiviteit namens werknemers
Voorbeeld:
Stel je bouwt een platform dat AI-agenten biedt om interne workflows te automatiseren — zoals een beveiligingsanalist-bot die logs bewaakt en waarschuwingen stuurt, of een verkoopassistent die e-mails schrijft op basis van CRM-gegevens.
Elk bedrijf dat je platform gebruikt wil:
Inloggen met hun bestaande SSO
Controleren welke agenten toegang hebben (bijv., interne tools, documentensystemen)
Zien welke agent welke taak heeft uitgevoerd, onder welke autorisatie van werknemers
In dit geval moet je identiteitsarchitectuur ondersteuning bieden voor multi-tenant ontwerp, beperkte agentpermissies, en organisatie-specifiek beleid. Agenten handelen nog steeds namens gebruikers, maar de permissies en identiteitsgrenzen worden per zakelijk tenant gehandhaafd.
In beide gevallen definieert het identiteitsmodel hoe agenten werken, wat ze kunnen benaderen, en hoe je systeem zorgt voor verantwoording.
Gebruik deze gids om je identiteit en productarchitectuur te plannen.
Voorkomt ongeautoriseerde toegang, zelfs als inloggegevens zijn gecompromitteerd.
Voorbeeld: Als een agent je helpt bij het uitvoeren van een risicovolle actie, zoals een transactie uitvoeren of identiteitsinstellingen wijzigen, moet het een mens in de lus houden en MFA gebruiken om de actie te bevestigen voordat verder wordt gegaan.
Zorgt ervoor dat gebruikers en agenten alleen toegang krijgen tot wat toegestaan is.
Voorbeeld: Een AI-assistent in een bedrijfswerkruimte kan agenda-evenementen lezen, maar kan geen toegang krijgen tot factureringsgegevens, tenzij expliciet een hogere rol is toegewezen.
Verbetert de gebruikerservaring en vermindert het risico van zwakke wachtwoorden.
Voorbeeld: Laat gebruikers zich aanmelden met een magische link die naar hun e-mail wordt gestuurd of een biometrische prompt zoals Face ID.
Deze functies zijn van toepassing op zowel traditionele als agent-gebaseerde apps, vooral nu agenten beginnen te werken met gevoelige gegevens en systemen.
Naarmate agenten en multi-agent workflows opkomen, zien we nieuwe use cases waarin gebruikers, agenten, API's en MCP-servers allemaal met elkaar interacteren. Het aantal en de verscheidenheid van deze scenario's groeit snel, veel meer dan vroeger.
Telkens wanneer deze verbindingen plaatsvinden, wordt autorisatie meer zichtbaar dan ooit. Gebruikers moeten duidelijke toestemming geven, en permissies moeten zorgvuldig worden beheerd over systemen heen. Daarom praat nu iedereen over het houden van een “mens in de lus” om ervoor te zorgen dat gebruikers voldoende controle en zichtbaarheid hebben over wat agenten kunnen doen en voor welke scopes ze gemachtigd zijn.
Je AI-app moet mogelijk integreren met veel externe diensten#
Het MCP-ecosysteem breidt zich uit, en dat betekent dat je app niet langer slechts een standalone dienst is: het maakt deel uit van een groter, verbonden netwerk.
Om rijke, nuttige context te bieden aan LLMs, moeten je agenten mogelijk:
Toegang krijgen tot meerdere MCP-servers
Voorbeeld: Stel je een AI-projectmanager voor die taakupdates ophaalt van Jira, team beschikbaarheid van Google Calendar, en verkoopgegevens van Salesforce en elk van deze zou kunnen worden aangedreven door een andere MCP-server. Om één wekelijkse samenvatting te genereren, moet de agent veilig interacteren met meerdere gegevensbronnen. Dat is waar authenticatie en autorisatie om de hoek komen kijken, om elke verbinding te beschermen en te controleren hoe gegevens gedeeld worden.
Verbinden met externe API’s en tools
Voorbeeld: Een klantenservice-agent moet mogelijk bestelhistorie ophalen van Shopify, tickets bijwerken in Zendesk, en workflows activeren in Slack. Zonder integraties wordt de agent geïsoleerd en ineffectief.
Naarmate agenten meer verantwoordelijkheden opnemen, wordt integratie de sleutel tot bruikbaarheid. Je AI-product gaat niet alleen over wat het alleen kan doen en het gaat erom waar het toegang toe heeft, wat het kan orkestreren en waarover het kan redeneren in een verbonden ecosysteem. Daarom is bouwen voor interoperabiliteit, veilig en flexibel, belangrijker dan ooit.
Je moet open standaarden omarmen: OAuth/OIDC zijn belangrijker dan ooit#
In het AI-tijdperk groeit de behoefte aan veilige, flexibele integraties. Dat maakt OAuth 2.0 en OIDC belangrijker dan ooit.
Belangrijke use cases omvatten:
Externe MCP-servers: Laat third-party agenten veilig toegang krijgen tot je product met gedelegeerde tokens.
Derde partij-integraties: Sta andere tools of agents toe om verbinding te maken met je app (bijv., een projectmanagementplatform) zonder onbewerkte inloggegevens nodig te hebben.
Agent-ontwikkeling: Bouw AI-agenten die veilig handelen namens gebruikers over diensten heen.
Slimme apparaten: Gebruik OAuth/OIDC voor dingen zoals AI-aangedreven notulisten om gebruikers te authentiseren en verbinding te maken met de cloud — vooral met minimale UI.
Deze protocollen bieden veilige, token-gebaseerde, door gebruikers toegestemde toegang.
Ontwerpen voor vertrouwen en schaal in het tijdperk van agentische software#
Naarmate agentische producten zich ontwikkelen, blijven de kernprincipes van identiteit en autorisatie hetzelfde, maar de context is verschuivend. Agenten introduceren nieuwe oppervlakken voor delegatie, toestemming en toegang. Daarom zijn vasthouden aan open standaarden zoals OAuth, een duidelijke architectuur bouwen, en solide beveiligingspraktijken afdwingen niet zomaar beste practices, ze zijn fundamenteel. Nu zorgvuldig ontwerpen betekent dat je systeem zal schalen met vertrouwen, flexibiliteit, en vertrouwen in een toekomst aangedreven door AI.
