English

agent
ai
login

How Manus handles login state and user credentials in the Cloud Browser

This article covers how Manus manages login sessions in its cloud browser, the security risks of agent-based authentication, and alternatives like OAuth and credential vaults.

Guamian

Product & Design

6/27/20257 min read

Stop wasting weeks on user auth

Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.

Get started

Imagine this: you ask your AI agent to book a flight, check your emails, or update your CRM. To do that, it needs access to your online accounts. But how can it log in securely without constantly bugging you for passwords?

Agents can handle many tasks on behalf of users. To do this, they often need access to third-party services like websites, databases, or external APIs. While agents can sometimes connect to these services programmatically, many tasks still require traditional login methods and user interaction.

In the previous article, we discussed the security risks involved, especially when browsers manage user credentials, which can introduce vulnerabilities. https://blog.logto.io/agent-auth#chatgpt-operator-agent-auth-experience

While this flow raises valid security concerns, as we discussed earlier, it’s hard to ignore the convenience it brings to end users. That tension between usability and security makes it a compelling area for further technical investigation.

In this article, I’ll explore how some agents are already tackling the challenge I’d call “browser-based login and authentication.”

We’ll take a closer look at how Manus approaches this issue, the risks that still remain, and what the future might hold for authentication in agent-powered environments.

Manus’s approach: “Log in once, stay logged in”

Manus designed a feature called the Cloud Browser, which acts like a remote, sandboxed computer that runs entirely in the cloud. Think of it as your agent’s private web browser, with one key feature: it can remember your logged-in state, even across devices and tasks.

Here’s how it works:

You log in manually to a website inside the Cloud Browser. This only needs to happen once per site.
Manus captures your session data: cookies, local storage, anything that keeps you logged in.
That data is encrypted twice: first locally, then again in the cloud. Nothing is stored in plain text.
When the agent needs to revisit that site, Manus automatically injects the session into a new sandbox. The website thinks you’re still logged in.
You can sync across devices, and manually clear session data at any time via settings.

It’s like handing your agent a secure keycard that works wherever it goes but only inside its own locked room.

Local browsers (e.g., Chrome) and agent-powered cloud browsers

You might ask: “Isn’t this just like using Chrome? Why does an agent-powered cloud browser seem riskier?” Let’s break it down and explain why.

Why it’s generally safe to give your credentials to Chrome
Why giving them to an agent-powered browser can be risky
Who is considered a “first-party” vs. “third-party” in each context

Core differences: Local browser vs. Agent cloud browser

Aspect	Local browser (e.g., Chrome)	Typical agent cloud browser
Location	Runs on your personal device	Runs remotely in the cloud
Control	Fully under your control	Controlled by code or AI agent
UI feedback	You interact directly (visible form fields, autofill prompts)	It has a UI and allows user control, but most interactions are still handled silently by the agent programmatically.
Storage	Credentials stored securely via OS-level encryption (e.g., macOS Keychain)	Credentials or cookies may be stored in memory or logs, which increases the exposure risk.
Security boundary	Protected by your OS + browser sandbox	Needs custom isolation; vulnerable if the agent misbehaves or leaks data
Trust model	You trust Chrome because it runs with you, and it’s designed for direct human use	You trust the agent’s developers, who may or may not apply rigorous safeguards

Why it’s safer to give Chrome your username and password

You’re the operator Chrome is a first-party interface, you control it, you see what it’s doing, and it belongs to your computing environment. You enter passwords with intent, and the browser offers visible, auditable prompts.
Tightly integrated security Browsers like Chrome store passwords using the OS’s secure storage, often requiring biometrics or device login to unlock them. Autofill also works only in expected contexts (e.g., matching domains).
Minimal delegation You don’t “give” Chrome your password permanently it just remembers what you typed, with your explicit permission. You are the actor, not a third party.

Why agent cloud browsers pose a risk

They operate on your behalf, but not in your sight Cloud browsers are typically controlled programmatically. When you give them credentials, they log in for you, often without any UI or direct feedback. That introduces a gap in visibility and accountability.
Storage risks If you pass your credentials to an agent in plaintext, they might be logged, cached, or even retained in memory. Without strict access control, this becomes a liability.
Unclear trust boundary You may trust the agent service provider, but unlike Chrome, you don’t have OS-level or physical protections. If the server gets compromised or the agent is poorly implemented, your credentials can leak.

First-party vs. Third-party

Let’s break down what First-Party vs. Third-Party really means and why Chrome is seen as first-party, while an agentic cloud browser is not.

Role	Chrome	Agent Cloud Browser
You (User)	First-party operator	Credential owner
Browser/App	First-party interface (you interact directly)	Third-party delegate acting on your behalf
Credential handler	OS + Chrome (tightly coupled, local trust chain)	External agent service (loose trust boundaries)
Storage	Stored locally with OS-level protection	Stored remotely on cloud servers or backend infrastructure

Giving Chrome your password feels safe because it’s you entering it, into an app you control, with your operating system providing layers of protection. Google also does not store your password on its servers.

However, as Manus explains:

We save your login information as a set of encrypted files and securely upload them to our storage servers. This information includes:

Cookies
Local Storage

This means your login information is stored on Manus’s backend servers. As a user, you have to trust the agent’s developers, something that doesn’t fully align with standard security best practices.

Giving your credentials to a cloud browser controlled by an agent is a form of delegation. Even if you take manual control and use the browser yourself, it’s still considered a third party by the service you’re logging into. You’re relying on someone else’s infrastructure, security practices, and ethical standards, which introduces trust and safety risks.

In these situations, security should be enforced through programmatic protocols, not just trust in the brand or promises from the company.

What Manus get right (and what could go wrong)

What’s working:

Truly seamless sessions: You don’t have to log in every time, even on a different device.
User-first security: Everything is encrypted end-to-end, and you have full control over what’s stored.
Transparent and respectful: Manus doesn’t use your login data for training or analytics.

What still needs care:

Replay attacks: If someone somehow stole your session file, they could impersonate you.
Fingerprint mismatches: Some websites use advanced fingerprinting to tie logins to devices, which can break replays in sandboxes.
Cannot bypass CAPTCHA: For some third-party websites with strong security mechanisms that include CAPTCHA, user actions in the Cloud Browser may be flagged as bots and fail the CAPTCHA verification.
Data compliance: If sessions cross borders or devices, it can raise privacy or regulatory concerns.
Trust in the system: The encryption keys protecting your data need to be rock-solid and well-guarded.

Manus offers a smart approach but it’s not the only one. Let’s explore other common methods agents use to log in on behalf of users:

Typing credentials

The most straightforward method is for the agent to type your username and password just like a human. It’s simple to implement but highly insecure if those credentials are ever leaked, anyone could access your account. Because of these risks, most developers avoid this approach altogether.

When this method is used, it’s often paired with tools like vaults or secret managers to handle cookies or credentials more securely and add an extra layer of protection.

OAuth tokens

The gold standard for delegated access. You authorize the agent through an OAuth flow, and it receives a token with limited, revocable permissions. It’s secure, fine-grained, and easy to revoke but only works if the website supports OAuth.

Other programmatic methods (e.g., API Keys)

Some services offer API keys or other access credentials for programmatic use. These can be more secure than typing passwords but often come with broad permissions and require careful key management.

Each method represents a trade-off between usability and security. Manus’s session replay sits somewhere in the middle more flexible than OAuth in many cases, but not as inherently secure.

Ideally, in this browser-based scenario, Manus could pre-integrate with specific websites (e.g., a numbered list of supported sites). Users would grant consent in advance, allowing the agent to operate securely using OAuth tokens instead of storing credentials or replaying sessions.

Where this is going: Agents as trusted professionals

As agents become more capable, they’ll need more sophisticated ways to authenticate without pretending to be human.

We’re moving toward:

API-first access: Instead of clicking buttons, agents will call secure APIs with tokens.
Short-lived, tightly scoped permissions: No more “god mode” tokens. Access only what’s needed, for just long enough.
Hardware-based security: Session data stored in secure enclaves, not just software vaults.
User-owned credential vaults: You’ll manage a secure wallet of tokens, keys, and sessions—shared only with the agents you trust.

In short: agents will graduate from “helpful bots” to “authorized operators,” with credentials to match.

What’s vault, and why does it matter?

If all of this sounds like a lot to manage… I believe that as browser-based automation continues to grow, it must be paired with a dedicated professional companion tool something built to handle credentials, security, and session management safely and transparently.

That’s why tools like Vault or Encryption Key Management (EKM) systems are important.

Vault is a secrets management solution that allows teams to:

Store tokens, API keys, and credentials safely
Issue short-lived, dynamic credentials on demand
Control who can access what, with full audit logs
Rotate secrets automatically, and revoke access instantly
Integrate with CI/CD pipelines and cloud apps

In an agent-powered world, Vault becomes the “brain” behind credential security. Your agents can request access from Vault without ever storing passwords themselves. Even if something leaks, the token expires quickly and your real keys stay safe.

Final thoughts

Manus is pioneering a usable, thoughtful approach to agent login: secure session replay across devices, controlled entirely by the user. It’s a great step forward but also a reminder that login flows are delicate. Replay attacks, sandbox quirks, and key management all need serious attention.

The future is clear: agents will handle more for us but they’ll need credentials to do it safely. Tools like Vault will play a critical role, not just in managing secrets, but in enabling trust.

When your AI has the keys to your digital life, you want to know: who gave them out, how long they last, and what door they actually open.

Logto is introducing Vault to securely store third-party API tokens, enabling safe agent access to external services, such as social accounts like Google or remote MCP servers. In the future, we plan to support storing a wider range of sensitive data, including user credentials, keys, and other secrets.

At the same time, Logto is a complete authentication, authorization, and identity management platform. If you’re building an AI agent from scratch, Logto is purpose-built for AI developers offering the security, flexibility, and infrastructure needed to manage identity in agent-powered environments.

Manus’s approach: “Log in once, stay logged in”#

Local browsers (e.g., Chrome) and agent-powered cloud browsers#

Core differences: Local browser vs. Agent cloud browser#

Why it’s safer to give Chrome your username and password#

Why agent cloud browsers pose a risk#

First-party vs. Third-party#

What Manus get right (and what could go wrong)#

What’s working:#

What still needs care:#

Other ways agents handle login#

Typing credentials#

OAuth tokens#

Other programmatic methods (e.g., API Keys)#

Where this is going: Agents as trusted professionals#

What’s vault, and why does it matter?#

Final thoughts#

Manus’s approach: “Log in once, stay logged in”#

Local browsers (e.g., Chrome) and agent-powered cloud browsers#

Core differences: Local browser vs. Agent cloud browser#

Why it’s safer to give Chrome your username and password#

Why agent cloud browsers pose a risk#

First-party vs. Third-party#

What Manus get right (and what could go wrong)#

What’s working:#

What still needs care:#

Other ways agents handle login#

Typing credentials#

OAuth tokens#

Other programmatic methods (e.g., API Keys)#

Where this is going: Agents as trusted professionals#

What’s vault, and why does it matter?#

Final thoughts#

Manus’s approach: “Log in once, stay logged in”

Local browsers (e.g., Chrome) and agent-powered cloud browsers

Core differences: Local browser vs. Agent cloud browser

Why it’s safer to give Chrome your username and password

Why agent cloud browsers pose a risk

First-party vs. Third-party

What Manus get right (and what could go wrong)

What’s working:

What still needs care:

Other ways agents handle login

Typing credentials

OAuth tokens

Other programmatic methods (e.g., API Keys)

Where this is going: Agents as trusted professionals

What’s vault, and why does it matter?

Final thoughts

Manus’s approach: “Log in once, stay logged in”

Local browsers (e.g., Chrome) and agent-powered cloud browsers

Core differences: Local browser vs. Agent cloud browser

Why it’s safer to give Chrome your username and password

Why agent cloud browsers pose a risk

First-party vs. Third-party

What Manus get right (and what could go wrong)

What’s working:

What still needs care:

Other ways agents handle login

Typing credentials

OAuth tokens

Other programmatic methods (e.g., API Keys)

Where this is going: Agents as trusted professionals

What’s vault, and why does it matter?

Final thoughts