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.
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 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:
It’s like handing your agent a secure keycard that works wherever it goes but only inside its own locked room.
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.
| 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 |
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.
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.
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:
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.
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:
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.
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.
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.
As agents become more capable, they’ll need more sophisticated ways to authenticate without pretending to be human.
We’re moving toward:
In short: agents will graduate from “helpful bots” to “authorized operators,” with credentials to match.
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:
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.
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.