Hur Manus hanterar inloggningsstatus och användaruppgifter i Cloud Browsern

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 synsätt: “Logga in en gång, förbli inloggad”#

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:

1. Du loggar in manuellt på en webbplats i Cloud Browser. Detta behöver bara göras en gång per webbplats.
2. Manus fångar din sessionsdata: kakor, lokal lagring, allt som håller dig inloggad.
3. Den datan krypteras två gånger: först lokalt, sedan igen i molnet. Ingenting lagras i klartext.
4. När agenten behöver besöka webbplatsen igen, injicerar Manus automatiskt sessionen i en ny sandbox. Webbplatsen tror att du fortfarande är inloggad.
5. Du kan synka mellan enheter, och manuellt rensa sessionsdata när du vill i inställningarna.

Det är som att ge din agent ett säkert passerkort som fungerar överallt, men bara inuti dess egna låsta rum.

Lokala webbläsare (t.ex. Chrome) och agentdrivna molnwebbläsare#

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.

• Varför det vanligtvis är säkert att ge dina uppgifter till Chrome
• Varför det kan vara riskabelt att ge dem till en agentdriven webbläsare
• Vem som anses vara "förstapart" respektive "tredjepart" i varje sammanhang

Kärnskillnader: Lokal webbläsare vs. Agent-molnwebbläsare#

Varför det är säkrare att ge Chrome ditt användarnamn och lösenord#

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

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

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

Varför agent-molnwebbläsare innebär risker#

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

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

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

Förstapart vs. Tredjepart#

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.

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:

• Kakor
• Lokal lagring

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.

Vad Manus gör rätt (och vad som kan gå fel)#

Det som fungerar:#

• Verkligt sömlösa sessioner: Du behöver inte logga in varje gång, även på andra enheter.
• Användarförst säkerhet: Allt är krypterat från början till slut, och du bestämmer vad som lagras.
• Transparens och respekt: Manus använder inte dina inloggningsdata för träning eller analys.

Det som fortfarande kräver försiktighet:#

• Replay-attacker: Om någon lyckas stjäla din sessionsfil kan de utge sig för att vara dig.
• Fingeravtrycksproblem: Vissa webbplatser använder avancerad fingeravtrycksteknik som kopplar inloggning till enheter, vilket kan orsaka att sandboxes inte fungerar.
• Kan inte kringgå CAPTCHA: För vissa tredjepartswebbplatser med stark säkerhet och CAPTCHA kan användaråtgärder i Cloud Browser flaggas som botar och misslyckas vid CAPTCHA-verifiering.
• Datakompatibilitet: Om sessioner korsar landsgränser eller enheter kan det leda till integritets- eller regulatoriska problem.
• Förtroende för systemet: Krypteringsnycklarna som skyddar din data måste vara stenhårda och välbevakade.

Andra sätt agenter hanterar inloggning#

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:

Skriva in uppgifter#

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.

OAuth-token#

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.

Andra programmatiska metoder (t.ex. API-nycklar)#

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.

Vart detta är på väg: Agenter som betrodda proffs#

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:

• API-först-tillgång: Istället för att klicka på knappar anropar agenter säkra API:er med tokens.
• Kortlivade, precist avgränsade rättigheter: Inga fler "gud-läge"-token. Endast tillgång till det som behövs, under begränsad tid.
• Hårdvarubaserad säkerhet: Sessionsdata lagras i säkra enclaver, inte bara i mjukvarulås.
• Användarägda credential-vaults: Du förvaltar en säker plånbok med token, nycklar och sessioner – som bara delas med agenter du litar på.

Kort sagt: agenter kommer avancera från "hjälpsamma botar" till "auktoriserade operatörer" – med legitim identitet.

Vad är vault och varför spelar det roll?#

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:

• Lagra token, API-nycklar och autentiseringsuppgifter säkert
• Skapa kortlivade, dynamiska uppgifter på begäran
• Styra vem som får åtkomst, med fullständiga loggar
• Roterar credentials och återkallar åtkomst automatiskt
• Koppla ihop med CI/CD-flöden och molnappar

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.

Avslutande tankar#

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.