Wie Manus den Login-Status und Benutzeranmeldedaten im Cloud-Browser verwaltet
Dieser Artikel behandelt, wie Manus Login-Sitzungen in seinem Cloud-Browser verwaltet, die Sicherheitsrisiken agentenbasierter Authentifizierung und Alternativen wie OAuth und Zugangsdaten-Tresore.
Stell dir Folgendes vor: Du bittest deine KI-Agenten, einen Flug zu buchen, deine E-Mails zu prüfen oder dein CRM zu aktualisieren. Dazu braucht der Agent Zugriff auf deine Online-Konten. Aber wie kann er sich sicher anmelden, ohne dich ständig nach Passwörtern zu fragen?
Agenten können viele Aufgaben im Namen der Benutzer übernehmen. Dafür benötigen sie oft Zugriff auf Drittanbieterdienste wie Webseiten, Datenbanken oder externe APIs. Während Agenten sich manchmal programmatisch mit diesen Diensten verbinden können, erfordern viele Aufgaben weiterhin traditionelle Anmeldemethoden und Interaktion des Nutzers.
Im vorherigen Artikel haben wir die Sicherheitsrisiken beleuchtet, insbesondere wenn Browser die Anmeldedaten der Nutzer verwalten – dies kann Schwachstellen mit sich bringen. https://blog.logto.io/agent-auth#chatgpt-operator-agent-auth-experience
Auch wenn dieses Vorgehen berechtigte Sicherheitsbedenken aufwirft, wie zuvor diskutiert, lässt sich der Komfort für die Endnutzer schwer ignorieren. Genau dieses Spannungsfeld zwischen Benutzbarkeit und Sicherheit macht das Thema für weitere technische Nachforschungen so spannend.
In diesem Artikel zeige ich, wie einige Agenten bereits versuchen, das Problem zu lösen, das ich als „browserbasierte Anmeldung und Authentifizierung“ bezeichnen würde.
Wir werfen einen genauen Blick darauf, wie Manus dieses Thema angeht, welche Risiken bestehen bleiben und was die Zukunft für die Authentifizierung in agentenbasierten Umgebungen bringen könnte.
Der Ansatz von Manus: „Einmal anmelden, angemeldet bleiben“
Manus hat eine Funktion namens Cloud Browser entwickelt. Dieser arbeitet wie ein entfernter, isolierter Computer, der vollständig in der Cloud läuft. Man kann ihn sich als den privaten Webbrowser des Agenten vorstellen, mit einem entscheidenden Vorteil: Er kann deinen angemeldeten Zustand behalten – selbst geräte- und aufgabenübergreifend.
So funktioniert es:
- Du meldest dich manuell auf einer Website im Cloud Browser an. Das ist nur einmal pro Seite nötig.
- Manus erfasst deine Sitzungsdaten: Cookies, Local Storage, alles, was dich angemeldet hält.
- Diese Daten werden zweifach verschlüsselt: zunächst lokal, dann nochmals in der Cloud. Nichts wird im Klartext gespeichert.
- Wenn der Agent die Seite erneut besuchen muss, injiziert Manus automatisch die Sitzung in eine neue Sandbox. Die Website nimmt an, du wärst noch immer angemeldet.
- Du kannst Geräte synchronisieren und Sitzungsdaten jederzeit über die Einstellungen löschen.
Das ist, als würdest du deinem Agenten eine sichere Schlüsselkarte geben, die überall funktioniert – aber nur in seinem eigenen, verschlossenen Raum.
Lokale Browser (z. B. Chrome) und agentenbasierte Cloud-Browser
Du fragst dich vielleicht: „Ist das nicht wie mit Chrome? Warum scheint ein agentenbasierter Cloud-Browser riskanter?“ Lass es uns aufschlüsseln und erklären.
- Warum es grundsätzlich sicher ist, Chrome deine Anmeldedaten zu geben
- Warum das Weitergeben an einen agentenbasierten Browser riskanter ist
- Wer in welchem Kontext als „First Party“ bzw. „Third Party“ gilt
Zentrale Unterschiede: Lokaler Browser vs. Agentenbasierter Cloud-Browser
Aspekt | Lokaler Browser (z. B. Chrome) | Typischer agentenbasierter Cloud-Browser |
---|---|---|
Standort | Läuft auf deinem persönlichen Gerät | Läuft remote in der Cloud |
Kontrolle | Komplett unter deiner Kontrolle | Von Code oder KI-Agenten gesteuert |
UI-Rückmeldung | Direkte Interaktion durch dich (sichtbare Formularfelder, Autofill-Prompts) | Hat eine UI und erlaubt Nutzerkontrolle, aber die meisten Interaktionen übernimmt weiterhin der Agent im Hintergrund. |
Speicherung | Anmeldedaten sicher per OS-Encryption (z. B. macOS Keychain) | Anmeldedaten oder Cookies können im Speicher/Logs landen – Risiko einer größeren Angriffsfläche. |
Sicherheitsgrenze | Geschützt durch OS + Browsersandbox | Benötigt eigene Isolationsmechanismen; anfällig, wenn Agent fehlerhaft oder unsicher ist |
Vertrauensmodell | Du vertraust Chrome, weil es mit dir läuft und für menschliche Nutzung gebaut ist | Du vertraust den Agentenentwicklern, die evtl. nicht so strenge Sicherheitsmaßnahmen umsetzen |
Warum es sicherer ist, Chrome deinen Benutzernamen und Passwort anzuvertrauen
-
Du bist der Bediener Chrome ist eine First-Party-Schnittstelle, du kontrollierst sie, sie gehört zu deinem System. Du gibst dein Passwort bewusst ein, der Browser bietet sichtbare, nachvollziehbare Hinweise.
-
Integrierte Sicherheitsmechanismen Browser wie Chrome speichern Passwörter in gesichertem OS-Speicher und erfordern oft Biometrie oder Geräte-Login. Autofill funktioniert auch nur in vorgesehenen Kontexten (z. B. passender Domain).
-
Minimale Delegation Du „übergibst“ Chrome das Passwort nicht dauerhaft – es merkt sich lediglich, was du eingegeben hast, mit expliziter Erlaubnis. Du bist der Akteur, kein Dritter.
Warum agentengeführte Cloud-Browser ein Risiko darstellen
-
Sie handeln für dich – aber nicht vor deinen Augen Cloud-Browser werden meist programmatisch gesteuert. Gibst du ihnen deine Anmeldedaten, loggen sie sich für dich ein, oft ohne sichtbare Oberfläche oder Rückmeldung. Das reduziert Transparenz und Kontrolle.
-
Speicherungs-Risiken Übergibst du deine Zugangsdaten im Klartext, können sie geloggt, zwischengespeichert oder im RAM verbleiben. Ohne penible Zugriffssteuerung ist das ein Risiko.
-
Unklare Vertrauensgrenzen Du vertraust dem Agenten-Service, hast aber – anders als bei Chrome – keinen OS- oder physischen Schutz. Wird der Server kompromittiert oder ist der Agent schlecht umgesetzt, drohen Leaks.
First Party vs. Third Party
Lass uns klären, was First Party und Third Party wirklich bedeuten – und warum Chrome als First Party gilt, ein agentenbasierter Cloud-Browser hingegen nicht.
Rolle | Chrome | Agentenbasierter Cloud-Browser |
---|---|---|
Du (Nutzer) | First-Party-Bediener | Eigentümer der Zugangsdaten |
Browser/App | First-Party-Schnittstelle (du interagierst direkt) | Third-Party-Delegat, der in deinem Namen handelt |
Credential Handler | OS + Chrome (nahtlos, lokale Vertrauenskette) | Externer Agentenservice (lose Vertrauensgrenzen) |
Speicherung | Lokal mit OS-Schutz gespeichert | Remote auf Cloudserver/Backend gespeichert |
Chrome dein Passwort zu geben, fühlt sich sicher an, weil du es in deiner App unter Kontrolle von deinem Betriebssystem eintippst. Google speichert dein Passwort zudem nicht auf seinen Servern.
Wie Manus erklärt:
Wir speichern deine Login-Informationen als verschlüsselte Dateien und laden sie sicher auf unsere Speicherserver hoch. Diese Informationen umfassen:
- Cookies
- Local Storage
Deine Logindaten landen also auf den Backend-Servern von Manus. Als Nutzer musst du den Agentenentwicklern vertrauen – das entspricht nicht vollständig den gängigen Sicherheitsstandards.
Die Übergabe deiner Anmeldedaten an einen agentengeführten Cloud-Browser ist eine Delegation. Selbst bei manueller Nutzung gilt der Browser für den Zielservice als third party. Du verlässt dich auf die Infrastruktur, Standards und Ethik anderer – das birgt Vertrauens- und Sicherheitsrisiken.
In solchen Szenarien sollte Sicherheit mit programmatischen Protokollen statt nur Marken- oder Werbeversprechen durchgesetzt werden.
Was Manus richtig macht (und was schiefgehen kann)
Was funktioniert:
- Nahtlose Sitzungen: Du musst dich nicht ständig neu anmelden – auch nicht auf anderen Geräten.
- Nutzerzentrierte Sicherheit: Alles ist durchgängig verschlüsselt, du hast volle Kontrolle über gespeicherte Daten.
- Transparent und respektvoll: Manus nutzt deine Anmeldedaten nicht für Analysen oder Training.
Was weiterhin beachtet werden muss:
- Replay-Angriffe: Wird deine Sitzungsdatei gestohlen, könnte dich jemand nachahmen.
- Fingerprinting-Probleme: Manche Webseiten koppeln Angemeldetsein an Geräte-Fingerabdrücke, was in Sandboxes zu Fehlern führt.
- CAPTCHA können nicht umgangen werden: Auf Websites mit starken Mechanismen wie CAPTCHA können Aktionen aus dem Cloud Browser als Bot erkannt werden und beim CAPTCHA scheitern.
- Compliance & Datenschutz: Wenn Sitzungen Geräte/Grenzen überschreiten, können regulatorische Probleme entstehen.
- Vertrauen ins System: Die Schlüssel zur Verschlüsselung deiner Daten müssen kompromisslos sicher sein.
Wie andere Agenten Anmeldungen handhaben
Der Ansatz von Manus ist clever, aber nicht der einzige. Schauen wir uns gängige Methoden an, mit denen Agenten im Namen von Nutzern Anmeldungen abwickeln:
Zugangsdaten eingeben
Die einfachste Methode: Der Agent tippt Benutzernamen und Passwort wie ein Mensch. Schnell umzusetzen, aber hochriskant: Werden die Zugangsdaten geleakt, hat jeder Zugriff auf das Konto. Daher vermeiden die meisten Entwickler dieses Verfahren.
Kommt es doch zum Einsatz, wird meist ein Tresor oder Secret Manager für Cookies/Zugangsdaten eingesetzt, um Sicherheit zu schaffen.
OAuth-Tokens
Der Goldstandard für Delegation. Du autorisierst den Agenten per OAuth-Flow, dieser erhält ein Token mit begrenzten, widerrufbaren Berechtigungen. Sicher, granular, gut widerrufbar – funktioniert jedoch nur, wenn die Website OAuth unterstützt.
Sonstige programmatische Methoden (z. B. API Keys)
Manche Dienste bieten API-Keys oder andere Zugangscodes für die automatische Nutzung. Sicherer als das Tippverfahren, aber meist mit weitreichenden Rechten versehen, bedürfen sie sorgfältigem Management.
Jede Methode stellt ein Abwägen zwischen Komfort und Sicherheit dar. Die Sessions von Manus sind flexibler als OAuth, jedoch nicht von Grund auf so sicher.
Im Idealfall könnte Manus den Browser vorintegriert mit bestimmten Websites anbieten (z. B. eine Liste unterstützter Seiten). Der Nutzer stimmt im Voraus zu, sodass der Agent mit OAuth-Token statt gespeicherten Zugangsdaten oder Sitzungs-Replays sicher arbeiten kann.
Wohin die Reise geht: Agenten als vertrauenswürdige Profis
Mit zunehmender Agenten-Kapazität braucht es ausgefeiltere Authentifizierungsmethoden, die nicht darauf basieren, menschliches Verhalten vorzutäuschen.
Wir steuern auf folgendes zu:
- API-zentrierter Zugriff: Kein Klick-Marathon mehr – Agenten nutzen sichere APIs per Token.
- Kurzlebige, eng begrenzte Rechte: Keine „Gottmodus“-Tokens mehr. Zugriff nur auf das Notwendige, nur so lange wie nötig.
- Hardwarebasierte Sicherheit: Sitzungsdaten via Secure Enclave statt nur Software-Tresor.
- Benutzereigene Credential-Tresore: Du verwaltest ein sicheres Wallet für Tokens, Schlüssel und Sessions – Freigabe nur für Agenten, denen du vertraust.
Kurz: Agenten werden zu „autorisierten Operatoren“, nicht nur Bot-Gehilfen – ausgestattet mit passenden Zugangsdaten.
Was ist Vault und warum ist es wichtig?
Klingt das alles nach viel Verwaltungsaufwand? Ich glaube: Mit wachsender Automatisierung im Browser braucht es ein dediziertes Profi-Tool – gebaut für sicheren Umgang mit Zugangsdaten, Sicherheit und Sessions.
Darum sind Tools wie Vault oder Encryption Key Management (EKM)-Systeme so wichtig.
Vault ist eine Lösung zur Geheimnisverwaltung, die Teams Folgendes ermöglicht:
- Tokens, API-Keys und Zugangsdaten sicher speichern
- Kurzlebige, dynamische Zugangsdaten bedarfsgerecht generieren
- Zugriffsrechte feingranular vergeben und auditieren
- Secrets automatisch rotieren und Zugänge sofort widerrufen
- Integration mit CI/CD-Pipelines und Cloud-Apps
In einer agentenbasierten Welt ist Vault das „Gehirn“ der Zugangssicherheit. Agenten fordern Zugriff bei Vault an, ohne selbst Passwörter speichern zu müssen. Selbst wenn ein Token kompromittiert wird, ist er nur kurz gültig – die echten Schlüssel bleiben geschützt.
Fazit
Manus weist einen durchdachten, benutzerfreundlichen Weg für Agentenlogins: Sichere Sitzungsübernahme geräteübergreifend, komplett vom Nutzer kontrolliert. Das ist ein großer Fortschritt, aber auch Mahnung – Login-Flows sind sensibel. Replay-Angriffe, Sandbox-Eigenheiten und Schlüsselmanagement brauchen volle Aufmerksamkeit.
Die Zukunft ist klar: Agenten werden mehr für uns übernehmen, brauchen aber Zugangsdaten – sicher verwaltet. Tools wie Vault werden dabei unverzichtbar, nicht nur für Geheimnisse, sondern auch für Vertrauen.
Wenn deine KI den Schlüssel zu deinem digitalen Leben hat, willst du wissen: Wer hat ihn gegeben, wie lange ist er gültig und für welche Tür?
Logto führt Vault zum sicheren Speichern von Drittanbieter-API-Tokens ein – dadurch können Agenten sicher auf externe Dienste zugreifen (z. B. Social Accounts wie Google oder entfernte MCP-Server). In Zukunft soll das Speichern sensibler Daten wie Benutzerdaten, Schlüssel und anderer Geheimnisse unterstützt werden.
Gleichzeitig ist Logto eine komplette Plattform für Authentifizierung, Autorisierung und Identitätsmanagement. Wenn du einen KI-Agenten von Grund auf baust, ist Logto speziell für KI-Entwickler gebaut – es bietet die nötige Sicherheit, Flexibilität und Infrastruktur fürs Identitätsmanagement in agentenbasierten Umgebungen.