Dit artikel behandelt hoe Manus omgaat met inlogsessies in zijn cloudbrowser, de beveiligingsrisico's van authenticatie door agents en alternatieven zoals OAuth en credential vaults.
Stel je het volgende voor: je vraagt je AI-agent om een vlucht te boeken, je e-mails te checken of je CRM bij te werken. Daarvoor heeft hij toegang tot je online accounts nodig. Maar hoe kan hij veilig inloggen zonder je constant lastig te vallen om wachtwoorden?
Agents kunnen veel taken namens gebruikers uitvoeren. Hiervoor hebben ze vaak toegang nodig tot externe diensten zoals websites, databases of externe API's. Hoewel agents soms programmatically verbinding kunnen maken met deze diensten, vereisen veel taken nog steeds traditionele inlogmethoden en gebruikersinteractie.
In het vorige artikel bespraken we de beveiligingsrisico's, vooral wanneer browsers gebruikersgegevens beheren, wat kwetsbaarheden kan introduceren. https://blog.logto.io/agent-auth#chatgpt-operator-agent-auth-experience
Hoewel deze flow terechte beveiligingszorgen oproept, zoals eerder besproken, is het moeilijk om het gemak voor eindgebruikers te negeren. Die spanning tussen bruikbaarheid en veiligheid maakt het een interessant onderwerp voor verder technisch onderzoek.
In dit artikel verken ik hoe sommige agents de uitdaging aangaan die ik “browsergebaseerd inloggen en authenticatie” zou noemen.
We kijken hoe Manus dit probleem aanpakt, welke risico's er nog zijn en wat de toekomst zou kunnen brengen voor authenticatie in agent-gestuurde omgevingen.
Manus heeft een functie ontwikkeld genaamd de Cloud Browser, die fungeert als een externe, sandboxed computer die volledig in de cloud draait. Zie het als de privé-webbrowser van je agent, met één belangrijk kenmerk: hij kan je ingelogde status onthouden, zelfs over apparaten en taken heen.
Zo werkt het:
Het is alsof je jouw agent een veilige sleutelkaart geeft die overal werkt, maar alleen binnen zijn eigen afgesloten kamer.
Je vraagt je misschien af: “Is dit niet gewoon zoals Chrome gebruiken? Waarom lijkt een agent-gestuurde cloudbrowser riskanter?” Laten we het uitleggen en onderbouwen.
| Aspect | Lokale browser (bijv. Chrome) | Typische agent cloudbrowser |
|---|---|---|
| Locatie | Draait op je eigen apparaat | Draait extern in de cloud |
| Controle | Volledig onder jouw controle | Bestuurd door code of AI-agent |
| UI feedback | Je bedient direct (zichtbare formuliervelden, autofillprompts) | Heeft een UI en staat gebruikerscontrole toe, maar de meeste interacties gebeuren stilletjes door de agent |
| Opslag | Inloggegevens veilig opgeslagen via OS-encryptie (bijv. macOS Keychain) | Inloggegevens of cookies kunnen in geheugen of logs staan, wat het risico op blootstelling verhoogt |
| Beveiligingsgrens | Beschermd door je OS + browsersandbox | Vereist aangepaste isolatie; kwetsbaar als de agent zich misdraagt of data lekt |
| Vertrouwensmodel | Je vertrouwt Chrome omdat het met jou draait en ontworpen is voor direct menselijk gebruik | Je vertrouwt de ontwikkelaars van de agent, die mogelijk niet dezelfde beveiligingsmaatregelen toepassen |
Jij bent de operator Chrome is een first-party interface, je bestuurt het, je ziet wat er gebeurt en het draait in jouw computeromgeving. Je voert wachtwoorden bewust in en de browser biedt zichtbare, controleerbare prompts.
Sterk geïntegreerde beveiliging Browsers zoals Chrome slaan wachtwoorden op via de veilige opslag van het OS, vaak met biometrie of apparaatlogin om ze te ontsluiten. Autofill werkt enkel op verwachte plekken (bijvoorbeeld, bij overeenkomstige domeinen).
Minimale delegatie Je “geeft” Chrome niet permanent je wachtwoord — hij onthoudt alleen wat je hebt ingevoerd, met jouw expliciete toestemming. Jij bent de actor, niet een derde partij.
Ze werken namens jou, maar buiten je zicht Cloudbrowsers worden vaak programmatically bestuurd. Als je ze gegevens geeft, loggen ze voor jou in, zonder UI of directe feedback. Dat creëert een gat in zichtbaarheid en verantwoordelijkheid.
Opslagrisico's Als je je gegevens in platte tekst aan een agent geeft, kunnen ze worden gelogd, gecached of zelfs in het geheugen blijven staan. Zonder strikte toegangscontrole wordt dit een zwakke plek.
Onduidelijke vertrouwensgrens Je vertrouwt waarschijnlijk de agent service provider, maar in tegenstelling tot Chrome heb je hier geen OS- of fysieke bescherming. Wordt de server gehackt of is de agent slecht geïmplementeerd, dan kunnen je gegevens lekken.
Laten we verduidelijken wat First-Party vs. Third-Party precies betekent en waarom Chrome als first-party wordt gezien, terwijl een agent-cloudbrowser dat niet is.
| Rol | Chrome | Agent Cloudbrowser |
|---|---|---|
| Jij (Gebruiker) | First-party operator | Credential eigenaar |
| Browser/App | First-party interface (je bedient direct) | Third-party uitvoerder namens jou |
| Credential-verwerker | OS + Chrome (sterk gekoppeld, lokale vertrouwensketen) | Externe agentservice (losse vertrouwensgrenzen) |
| Opslag | Lokaal opgeslagen met OS-bescherming | Extern opgeslagen op cloudservers of backend-infrastructuur |
Je je wachtwoord aan Chrome geven voelt veilig omdat jij het invoert in een app die jij bestuurt, met jouw besturingssysteem als extra laag beveiliging. Google slaat je wachtwoord ook niet op zijn servers op.
Maar zoals Manus uitlegt:
We slaan je inloginformatie op als een set versleutelde bestanden en uploaden die veilig naar onze opslagservers. Deze informatie omvat:
- Cookies
- Local Storage
Dit betekent dat je inloginformatie op de backendservers van Manus wordt opgeslagen. Als gebruiker moet je vertrouwen op de agent-ontwikkelaars, wat niet helemaal overeenkomt met standaard beveiligingspraktijken.
Je gegevens aan een cloudbrowser toevertrouwen die bestuurd wordt door een agent is een vorm van delegatie. Zelfs als je handmatige controle neemt en de browser zelf gebruikt, wordt hij door de dienst waar je op inlogt als een derde partij beschouwd. Je vertrouwt op iemand anders zijn infrastructuur, beveiliging en ethische normen, wat vertrouwens- en veiligheidsrisico's introduceert.
In deze situaties moet beveiliging worden afgedwongen via programmeerbare protocollen, niet alleen door vertrouwen in het merk of beloften van het bedrijf.
Manus biedt een slimme aanpak, maar het is niet de enige. Dit zijn andere gebruikelijke methoden die agents gebruiken om namens gebruikers in te loggen:
De meest eenvoudige methode is dat de agent je gebruikersnaam en wachtwoord intypt als een mens. Dit is makkelijk te bouwen, maar erg onveilig — als de gegevens uitlekken, kan iedereen toegang krijgen tot je account. Om die reden vermijden de meeste ontwikkelaars deze aanpak volledig.
Wordt deze methode toch gebruikt, dan vaak samen met tools zoals vaults of secret managers om cookies of credentials veiliger op te slaan en een extra beveiligingslaag toe te voegen.
De gouden standaard voor gedelegeerde toegang. Je autoriseert de agent via een OAuth-flow, waarna hij een token krijgt met beperkte, herroepbare rechten. Het is veilig, fijnmazig en makkelijk te herroepen, maar werkt alleen als de website OAuth ondersteunt.
Sommige diensten bieden API-sleutels of andere toegangsgegevens voor programmatic gebruik. Die zijn veiliger dan wachtwoorden intypen, maar hebben vaak brede rechten en vragen om zorgvuldige sleutelbeheer.
Elke methode is een compromis tussen bruikbaarheid en veiligheid. Manus' sessie-replay zit daar ergens tussenin: flexibeler dan OAuth in veel gevallen, maar niet zo intrinsiek veilig.
Idealiter zou Manus in deze browser-gebaseerde scenario's vooraf kunnen integreren met bepaalde websites (bijvoorbeeld een genummerde lijst van ondersteunde sites). Gebruikers geven dan op voorhand toestemming, waarmee de agent veilig kan werken via OAuth-tokens in plaats van inloggegevens of sessies op te slaan.
Naarmate agents krachtiger worden, zullen ze geavanceerdere manieren moeten hebben om zich te authenticeren zonder zich als mens voor te doen.
We bewegen richting:
Kortom: agents groeien van 'handige bots' naar 'bevoegde operators' met bijpassende toegangsrechten.
Als dit allemaal veel om te beheren klinkt... Ik geloof dat browser-gebaseerde automatisering moet worden gecombineerd met een professionele metgezel: een tool die is gebouwd om credentials, beveiliging en sessiebeheer veilig en transparant te managen.
Daarom zijn tools zoals Vault of Encryption Key Management (EKM) belangrijk.
Vault is een oplossing voor geheimenbeheer waarmee teams:
In een wereld met agenten wordt Vault het 'brein' achter credential-beveiliging. Je agents kunnen toegang aanvragen bij Vault zonder ooit zelf je wachtwoorden op te slaan. Mocht er toch iets lekken, verloopt het token snel en blijven je echte sleutels veilig.
Manus is pionier in een bruikbare, goed doordachte aanpak voor agentinlog: veilige sessie-replay over apparaten, volledig onder controle van de gebruiker. Het is een goede stap voorwaarts, maar ook een herinnering dat inlogflows gevoelig blijven. Replay-aanvallen, sandboxproblemen en sleutelbeheer verdienen serieuze aandacht.
De toekomst is duidelijk: agents gaan meer voor ons doen, maar hebben daarvoor wel credentials nodig om dat veilig te kunnen. Tools als Vault zullen een sleutelrol spelen, niet alleen in geheimenbeheer, maar ook in het opbouwen van vertrouwen.
Wanneer jouw AI de sleutels tot je digitale leven heeft, wil je weten: wie heeft ze uitgedeeld, hoelang zijn ze geldig, en welke deuren gaan er eigenlijk mee open?
Logto introduceert Vault om veilig API-tokens van derden op te slaan, zodat agents veilig toegang krijgen tot externe diensten, zoals sociale accounts of externe MCP-servers. In de toekomst willen we ondersteuning bieden voor het opslaan van meer soorten gevoelige data, inclusief gebruikersgegevens, sleutels en andere geheimen.
Tegelijkertijd is Logto een compleet platform voor authenticatie, autorisatie en identiteitsbeheer. Als je een AI-agent from scratch bouwt, is Logto speciaal gemaakt voor AI-ontwikkelaars — en biedt het de beveiliging, flexibiliteit en infrastructuur om identiteit te beheren in agent-gestuurde omgevingen.