The Four Places an Agent's Credential Can Live

When you build an AI agent that acts on behalf of a real user, you eventually hit a question that determines your architecture, your compliance posture, and whether your users will trust you with their accounts:

Where does the credential live?

There are exactly four places. Each has legitimate use cases. And understanding which one fits your platform — before you've already built around the wrong one — is one of the more useful decisions you can make early.

Why this question matters

Most agent security discussions focus on what the agent does: scope, prompt injection, data handling. Those matter. But there is a prior question that shapes all of them:

When your agent authenticates as your user, who sees the password?

The answer determines your breach blast radius. It determines your legal exposure. It determines whether your terms of service with third-party sites hold up. And it determines whether your users will hand you access to their most sensitive accounts in the first place.

Here are the four options.

Model 1 — Profile sync / BYO vault

The mechanism: The developer logs in once on their own machine. The browser profile — cookies, session tokens, saved credentials — gets synced to wherever the agent runs. The agent inherits an already-authenticated session.

Where it works: Solo developers building agents for themselves. Personal automations. Internal tooling where the developer is also the user. This is how most agent prototypes start, and it's the right choice at that stage.

Where it breaks: The moment your agent operates on behalf of someone else. You can sync your own browser profile. You cannot sync your customers'. Their cookies aren't yours to capture. Their session tokens aren't yours to forward. This model doesn't generalize past the person who built it.

Credential location: The developer's machine, or a synced profile store they control.

Model 2 — Cloud-browser handoff

The mechanism: The user accesses a vendor's cloud browser over remote control — a live browser tab running on vendor infrastructure, streamed to the user's screen. The user types their credentials into the vendor's browser. The resulting session persists on vendor infrastructure; the agent can then operate within it.

Where it works: Platforms where the user experience of remote-controlling a browser is acceptable. Some enterprise use cases with explicit consent. Situations where the vendor relationship and data handling are clearly disclosed.

Where it breaks: The password passes through the vendor's browser. The vendor's infrastructure is the system the user typed into. Even if the vendor never explicitly logs or stores the password, it transited their system. For users logging into banks, healthcare portals, payroll platforms, or professional networks, this is a custody question that's difficult to answer cleanly.

There is also a deeper issue: the ToS agreements between your users and the sites they log into often prohibit credential sharing or third-party access. A cloud-browser handoff may technically comply, or may not, depending on how narrowly those terms are written.

Credential location: The vendor's cloud-browser infrastructure.

Model 3 — Server-side vault

The mechanism: The platform stores encrypted user credentials and injects them at runtime when the agent needs to authenticate. Designed with strong cryptographic hygiene — encrypted at rest, access-controlled, audit-logged.

Where it works: Platforms where users explicitly consent to credential storage with full understanding of the implications. Enterprise deployments with contractual authorization. Internal tools where the platform IS the credential owner (e.g., a company managing its own service accounts).

Where it breaks: You become a credential custodian for every user in your system. That means:

Every stored password is your legal and contractual responsibility
A breach at your platform exposes every credential in your vault
Your ToS agreements with the sites your agent visits may prohibit this arrangement
Most users, once they understand what they're agreeing to, will not hand over their banking or healthcare passwords to a third party — regardless of encryption quality

The vault model isn't wrong. It's a valid pattern for the right use case. But it requires explicit user consent, regulatory clarity, and an honest internal conversation about what a breach looks like.

Credential location: A platform-operated credential vault.

Model 4 — End-user-device handoff

The mechanism: When the agent hits an authentication wall, instead of attempting to pass it automatically, the platform delivers a session link to the user. The user opens it on their own device and resolves the challenge themselves. The authenticated session flows back to the agent. The agent resumes.

Where it works: Multi-tenant platforms where users are logging into accounts the platform doesn't own, wasn't explicitly authorized to hold credentials for, and shouldn't be asking for passwords from.

What it actually does — and doesn't do: The password never transits the platform's infrastructure or the auth vendor's infrastructure. The user types it on their own hardware, into an end-to-end encrypted stream. No vendor in the chain sees it.

What does flow downstream is the resulting authenticated session — cookies, tokens, session state. Those can, and typically do, end up in the cloud browser or agent runtime where the task continues. That's expected and unavoidable; the agent needs an authenticated context.

The distinction is important: credential custody (holding the password) and session custody (holding the resulting cookie) are different things. End-user-device handoff eliminates credential custody. It doesn't claim to eliminate session custody — and any framing that implies otherwise is overclaiming.

Credential location: The user's own device. Nowhere in the vendor chain.

Why models 1–3 fail for multi-tenant platforms

The common thread across the first three models: at some point, someone other than the user holds or sees the credential.

For solo-developer tools, that's often fine — the developer is the user. But for a platform where your customers are the agents' end users:

Your users are logging into their banks, their healthcare portals, their payroll systems, their professional networks
You cannot ask for those passwords (your users won't give them, and shouldn't)
You cannot store them (your ToS with those platforms often prohibits it; regulations in healthcare and finance may too)
You cannot route them through a vendor's browser and call it clean

The pattern you need is one where the credential never leaves the user's control — only the session does.

Choosing the right model

Use this as a starting-point framework, not a checklist. The right model depends on your use case, your user base, and your compliance context.

	Model 1	Model 2	Model 3	Model 4
Solo developer, personal agent	✅	✅	✅	✅
Multi-tenant platform	❌	⚠️	⚠️	✅
Vendor sees the password	No	Transiently	No (injected)	No
Operator holds the credential	No	No	Yes	No
Works with any auth wall type	❌	Partial	Partial	✅
User consent complexity	Low	Medium	High	Low

The question to ask before you build

Before you architect your agent's authentication flow, ask one question:

When my agent authenticates as my user, who sees the password — and am I comfortable with that answer?

For most solo-dev tools and internal automations, the answer is uncomplicated. For most multi-tenant platforms operating on accounts users care about — their money, their health records, their professional identity — the answer determines whether users will trust you with those accounts at all.

Most platforms that end up needing Model 4 started with Model 1 or 2. They hit the trust question when they tried to onboard their first paying users. Getting ahead of it early is worth the architectural thought.

AuthLoop is an implementation of Model 4. See the integration → or read the HITL authentication primer → if you want the pattern explained before the implementation.