Hoe Manus de inlogstatus en gebruikersgegevens beheert in de Cloud Browser

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.

De aanpak van Manus: “Eén keer inloggen, ingelogd blijven”#

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:

1. Je logt handmatig in op een website binnen de Cloud Browser. Dit hoeft maar één keer per site.
2. Manus slaat je sessiedata op: cookies, local storage, alles wat je ingelogd houdt.
3. Die data wordt twee keer versleuteld: eerst lokaal, daarna nogmaals in de cloud. Niets wordt in platte tekst opgeslagen.
4. Wanneer de agent die site opnieuw moet bezoeken, injecteert Manus automatisch de sessie in een nieuwe sandbox. De website denkt dat je nog steeds ingelogd bent.
5. Je kunt synchroniseren over apparaten, en op elk moment handmatig je sessiedata wissen via de instellingen.

Het is alsof je jouw agent een veilige sleutelkaart geeft die overal werkt, maar alleen binnen zijn eigen afgesloten kamer.

Lokale browsers (zoals Chrome) en agent-gestuurde cloudbrowsers#

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.

• Waarom het meestal veilig is om je gegevens aan Chrome toe te vertrouwen
• Waarom het riskanter is om ze aan een agent-gestuurde browser te geven
• Wie als “first-party” of “third-party” wordt gezien in elke situatie

Kernverschillen: Lokale browser vs. agent cloudbrowser#

Waarom het veiliger is om je gebruikersnaam en wachtwoord aan Chrome te geven#

1. 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.

2. 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).

3. 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.

Waarom agent cloudbrowsers een risico vormen#

1. 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.

2. 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.

3. 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.

First-party vs. Third-party#

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.

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.

Wat Manus goed doet (en wat mis kan gaan)#

Wat werkt:#

• Echt naadloze sessies: Je hoeft niet telkens opnieuw in te loggen, zelfs niet op een ander apparaat.
• Gebruikersgerichte beveiliging: Alles is end-to-end versleuteld en je hebt volledige controle over wat wordt opgeslagen.
• Transparant en respectvol: Manus gebruikt je inlogdata niet voor training of analyse.

Waar nog aandacht nodig is:#

• Replay-aanvallen: Als iemand je sessiebestand steelt, kan hij zich voordoen als jij.
• Vingerafdruk-mismatches: Sommige websites gebruiken geavanceerde fingerprinting om logins aan apparaten te koppelen. Dat kan replays in sandboxes blokkeren.
• Kan CAPTCHA niet omzeilen: Sommige websites met sterke beveiliging (inclusief CAPTCHA) herkennen Cloud Browser-acties als bots, waardoor CAPTCHA kan mislukken.
• Data compliance: Als sessies landsgrenzen of apparaten overschrijden, kan dat privacy- of regelgevingsproblemen opleveren.
• Vertrouwen in het systeem: De encryptiesleutels die je data beschermen moeten ijzersterk en goed beveiligd zijn.

Andere manieren waarop agents login aanpakken#

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:

Wachtwoorden invoeren#

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.

OAuth-tokens#

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.

Andere programmeermethoden (zoals API Keys)#

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.

Waar gaat dit naartoe: Agents als vertrouwde professionals#

Naarmate agents krachtiger worden, zullen ze geavanceerdere manieren moeten hebben om zich te authenticeren zonder zich als mens voor te doen.

We bewegen richting:

• API-first toegang: In plaats van knoppen aanklikken, roepen agents beveiligde API's aan met tokens.
• Kortdurende, scherp afgebakende rechten: Geen 'god-modus'-tokens meer. Alleen toegang wat nodig is, zo kort als nodig.
• Hardware-gebaseerde beveiliging: Sessie-data opgeslagen in veilige enclaves, niet alleen software-vaults.
• Gebruikersbeheer van credential vaults: Je beheert een eigen beveiligde wallet met tokens, sleutels en sessies — gedeeld met alleen agents die je vertrouwt.

Kortom: agents groeien van 'handige bots' naar 'bevoegde operators' met bijpassende toegangsrechten.

Wat is een vault, en waarom is het belangrijk?#

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:

• Tokens, API-sleutels en inloggegevens veilig kunnen opslaan
• Kortdurende, dynamische credentials on demand kunnen uitgeven
• Kunnen bepalen wie toegang krijgt tot wat, met volledige logging
• Geheimen automatisch kunnen roteren en toegang direct kunnen intrekken
• Kunnen integreren met CI/CD-pijplijnen en cloudapps

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.

Tot slot#

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.