Den här artikeln tar upp hur Manus hanterar inloggningssessioner i sin molnwebbläsare, säkerhetsriskerna med agentbaserad autentisering samt alternativ som OAuth och credentials-vaults.
Föreställ dig det här: du ber din AI-agent boka ett flyg, kolla din e-post eller uppdatera ditt CRM-system. För att göra det, behöver den tillgång till dina onlinekonton. Men hur kan den logga in säkert utan att hela tiden störa dig för att få lösenord?
Agenter kan hantera många uppgifter åt användare. För att göra detta, behöver de ofta åtkomst till tredjepartstjänster som webbplatser, databaser eller externa API: er. Även om agenter ibland kan ansluta till dessa tjänster programmatiskt, kräver många arbetsflöden fortfarande traditionella inloggningsmetoder och användarinteraktion.
I tidigare artikel diskuterade vi de säkerhetsrisker som är förknippade, speciellt när webbläsare hanterar användaruppgifter, vilket kan introducera sårbarheter. https://blog.logto.io/agent-auth#chatgpt-operator-agent-auth-experience
Även om detta flöde medför berättigade säkerhetsrisker, vilket vi diskuterat tidigare, är det svårt att bortse från den bekvämlighet det ger slutanvändarna. Spänningen mellan användarvänlighet och säkerhet gör det här till ett intressant område för vidare teknisk undersökning.
I den här artikeln går jag igenom hur vissa agenter redan försöker lösa utmaningen jag kallar "webbläsarbaserad inloggning och autentisering."
Vi ska titta närmare på hur Manus närmar sig detta, vilka risker som finns kvar samt vad framtiden kan innebära för autentisering i agentdrivna miljöer.
Manus har designat en funktion som heter Cloud Browser, vilket fungerar som en fjärrstyrd, isolerad dator som körs helt i molnet. Tänk på det som din agents privata webbläsare, med en nyckelfunktion: den kan komma ihåg din inloggning, även mellan olika enheter och uppgifter.
Så här fungerar det:
Det är som att ge din agent ett säkert passerkort som fungerar överallt, men bara inuti dess egna låsta rum.
Du kanske frågar: "Är inte detta som att använda Chrome? Varför verkar en agentdriven molnwebbläsare vara riskablare?" Låt oss reda ut varför.
| Aspekt | Lokal webbläsare (t.ex. Chrome) | Typisk agent-molnwebbläsare |
|---|---|---|
| Plats | Körs på din personliga enhet | Körs fjärrstyrt i molnet |
| Kontroll | Helt under din kontroll | Styrs av kod eller AI-agent |
| UI-feedback | Du interagerar direkt (synliga formulärfält, autofyllningsrutor) | Har ett gränssnitt och tillåter användarkontroll, men de flesta interaktioner hanteras tyst av agenten programmatiskt. |
| Lagring | Uppgifter lagras säkert via OS-kryptering (t.ex. macOS Keychain) | Uppgifter eller kakor kan lagras i minnet eller loggar, vilket ökar exponeringsrisken. |
| Säkerhetsgräns | Skyddas av ditt operativsystem + webbläsarens sandbox | Kräver anpassad isolering; sårbar om agenten beter sig fel eller läcker data |
| Förtroendemodell | Du litar på Chrome eftersom det körs med dig, och är utformat för direkt mänsklig användning | Du litar på agentens utvecklare, som kanske eller kanske inte tillämpar rigorösa skydd |
Du är operatören Chrome är ett förstapartsgränssnitt; du styr det, du ser vad det gör, och det tillhör din dator. Du anger lösenord med avsikt, och webbläsaren erbjuder synliga, reviderbara uppmaningar.
Integrerad säkerhet Webbläsare som Chrome lagrar lösenord med operativsystemets säkra lagring, ofta med biometrisk eller enhetsinloggning som krav. Autofyll fungerar också bara i förväntade sammanhang (t.ex. matchande domäner).
Minimal delegering Du "ger" inte Chrome ditt lösenord permanent – den bara kommer ihåg vad du skrev, med ditt uttryckliga tillstånd. Du är aktören, inte en tredje part.
De opererar för dig, men inte under din insyn Molnwebbläsare styrs oftast programmatiskt. När du ger dem uppgifter loggar de in för dig, ofta utan gränssnitt eller feedback. Det skapar en lucka i insyn och ansvar.
Lagringsrisker Om du skickar dina uppgifter i klartext till en agent, kan de loggas, cachas eller stanna kvar i minnet. Utan strikt åtkomstkontroll blir detta en risk.
Otydlig förtroendegräns Du kanske litar på agenttjänsten, men jämfört med Chrome har du varken OS-nivå- eller fysiskt skydd. Om servern blir komprometterad eller agenten är dåligt implementerad kan dina uppgifter läcka.
Låt oss reda ut vad Förstapart vs. Tredjepart verkligen innebär, och varför Chrome betraktas som förstapart medan en agentmolnwebbläsare inte är det.
| Roll | Chrome | Agent-molnwebbläsare |
|---|---|---|
| Du (användare) | Förstapartsoperatör | Uppgiftsägare |
| Webbläsare/App | Förstapartsgränssnitt (du använder direkt) | Tredjepartsdelegerad som agerar å dina vägnar |
| Uppgiftsförvaltare | OS + Chrome (täta lokala förtroendekedjor) | Extern agenttjänst (löst definierade förtroendegränser) |
| Lagring | Lagrat lokalt med OS-skydd | Lagrat fjärrstyrt på molnservrar eller backend |
Att ge Chrome ditt lösenord känns säkert eftersom det är du som matar in det, i en app du kontrollerar, med ditt operativsystem för extra skydd. Google lagrar heller inte ditt lösenord på sina servrar.
Men som Manus förklarar:
Vi sparar din inloggningsinformation som en uppsättning krypterade filer och laddar upp dem säkert till våra lagringsservrar. Denna information inkluderar:
Detta betyder att din inloggningsinformation lagras på Manus backendservrar. Som användare måste du lita på agentens utvecklare, något som inte fullt ut överensstämmer med gängse säkerhetspraxis.
Att lämna dina uppgifter till en agentkontrollerad molnwebbläsare är en form av delegering. Även om du själv tar manuell kontroll och använder webbläsaren direkt, anses det ändå vara en tredjepart av tjänsten du loggar in på. Du förlitar dig på någon annans infrastruktur, säkerhetsrutiner och etiska standarder, vilket innebär förtroende- och säkerhetsrisker.
I dessa situationer bör säkerheten upprätthållas genom programmerbara protokoll, inte bara förtroende för varumärket eller företagets löften.
Manus har en smart metod men är inte den enda. Här är andra vanliga tekniker som agenter använder för att logga in åt användaren:
Det enklaste sättet är att agenten skriver in användarnamn och lösenord som en människa. Det är lätt att implementera men mycket osäkert – om dessa uppgifter läcker kan vem som helst komma åt ditt konto. På grund av dessa risker undviker de flesta utvecklare detta.
När denna metod används, kombineras den ofta med valv eller hemlighetshanterare för att lagra kakor eller uppgifter säkrare och med ett extra skyddslager.
Guldstandarden för delegerad åtkomst. Du godkänner agenten via ett OAuth-flöde, och den får en token med begränsade, återkallningsbara rättigheter. Det är säkert, detaljerat och lätt att återkalla – men fungerar bara om webbplatsen stödjer OAuth.
Vissa tjänster erbjuder API-nycklar eller andra autentiseringsuppgifter för programmatisk användning. Dessa är säkrare än att skriva lösenord men har ofta breda rättigheter och kräver noggrann hantering.
Varje metod innebär ett avvägande mellan användbarhet och säkerhet. Manus session replay ligger någonstans mitt emellan – mer flexibel än OAuth i vissa fall, men inte lika grundläggande säker.
Idealet vore att Manus i detta webbläsarbaserade scenario förintegrerade mot utvalda sajter (t.ex. lista över stödda tjänster). Användare skulle ge samtycke i förväg, så att agenten säkert kan använda OAuth-token istället för att lagra inloggningar eller spela upp sessioner.
När agenter blir mer kapabla kommer de behöva mer sofistikerade sätt att autentisera utan att låtsas vara människor.
Vi är på väg mot:
Kort sagt: agenter kommer avancera från "hjälpsamma botar" till "auktoriserade operatörer" – med legitim identitet.
Om allt detta låter krångligt... Jag tror att webbläsarbaserad automation måste kombineras med en dedikerad professionell följeslagarverktyg – något byggt för att hantera uppgifter, säkerhet och sessionshantering tryggt och transparent.
Det är därför verktyg som Vault eller Encryption Key Management (EKM) är viktiga.
Vault är en hemlighetshanterare som låter team:
I en agentdriven värld blir Vault "hjärnan" bakom credential-säkerheten. Dina agenter kan begära åtkomst från Vault utan att någonsin lagra lösenord själva. Till och med om något läcker löper token snabbt ut, och dina verkliga nycklar förblir säkra.
Manus pionjärar ett användbart och genomtänkt sätt för agentinloggning: säker session replay mellan enheter, helt kontrollerat av användaren. Det är ett stort steg framåt men också en påminnelse om att inloggningsflöden är ömtåliga. Replay-attacker, sandbox-buggar och nyckelhantering kräver alla seriös uppmärksamhet.
Framtiden är tydlig: agenter kommer hantera mer åt oss – men de måste ha rätt uppgifter för att göra det säkert. Verktyg som Vault kommer spela en avgörande roll – inte bara för att hantera hemligheter, utan för att möjliggöra förtroende.
När din AI har nycklarna till ditt digitala liv vill du veta: vem gav ut dem, hur länge de gäller, och vilken dörr de egentligen öppnar.
Logto introducerar Vault för att säkert lagra tredjeparts-API-token, vilket möjliggör säker agentåtkomst till externa tjänster, som sociala konton (t.ex. Google) eller fjärr-MCP-servrar. Framöver planerar vi att stödja lagring av ännu fler känsliga data, inklusive användaruppgifter, nycklar och andra hemligheter.
Samtidigt är Logto en fullständig plattform för autentisering, auktorisering och identitetshantering. Om du bygger en AI-agent från grunden är Logto speciellt byggt för AI-utvecklare – med den säkerhet, flexibilitet och infrastruktur som behövs för att hantera identitet i agentdrivna miljöer.