---
title: "AI agent login: 4 walls between an agent and a signed-in session"
description: "How an AI agent signs in to websites and stays signed in: the second factor, the emailed code, the passkey and the lost session, each with what we measured."
canonical: "https://scalebrowser.net/blog/ai-agent-login"
last_modified: "2026-09-25"
published: "2026-09-25"
author: "davide"
category: "sign-in"
---
> ## Documentation Index
> Fetch the complete documentation index at: https://scalebrowser.net/llms.txt
> Use this file to discover all available pages before exploring further.
# AI agent login: 4 walls between an agent and a signed-in session
> How an AI agent signs in to websites and stays signed in: the second factor, the emailed code, the passkey and the lost session, each with what we measured.
Your agent reached the login page, filled in the password and stopped: a six-digit code on a phone, a link in an inbox it does not have, a passkey prompt, or a session that expired overnight. Each of these is a separate wall, and each has a separate answer. This guide takes them in the order a run meets them and names what we measured on each.
## What does an AI agent login involve?
An AI agent login is a sign-in in which the agent decides which field is which and never holds the secret itself. The agent names the username field, the password field and the code field; the layer below it types the stored values into the page. That keeps the password out of the model's context, out of its logs and away from the model provider.
The common alternative is a person. Browserbase's [website authentication guide](https://docs.browserbase.com/platform/identity/authentication) calls it the best practice to "log in manually once using Session Live View" and then reuse the stored state in later sessions. That works until the state expires or a second factor asks again, and then the person is needed again.
## Which 4 walls stop an agent at sign-in?
Four walls stop an agent at sign-in, and they appear in this order during a run:
1. **The second factor.** A TOTP code under [RFC 6238](https://datatracker.ietf.org/doc/html/rfc6238) changes with a "default value X = 30 seconds", so no code can be stored in advance.
2. **The emailed or texted code.** The code arrives at an address or a number, and the agent needs one of its own that no other profile shares.
3. **The passkey.** The site asks the machine for a platform authenticator, and the browser has to answer the way a real machine answers.
4. **The lost session.** Cookies, passkeys and the device identity have to survive the end of the run, or the next run starts at the login page again.
We tested each wall with an acceptance bench that drives a real engine through the agent's own tools.
| Wall | What the bench checked | Result |
| --- | --- | --- |
| Emailed code | two profiles on one catch-all folder, one mail addressed to the second, 21 Aug 2026 | the first profile received the second profile's code; fixed since |
| Passkey | register, survive a killed engine, withdraw through the agent, on webauthn.io with the Windows engine, 14 and 18 Aug 2026 | 8 of 8 checks passed |
| Lost session | cookies, session export and import through the daemon, 18 Aug 2026 | 26 of 26 checks passed, 5 of them counter-proofs |
The first row is a result that went against us, and it is the one worth reading first. A catch-all folder is every profile's mailbox at once, and the reader did not filter by the address it was bound to. It now asks the mail server for the bound address and checks it again locally.
## How does an agent get past each wall?
An agent gets past each wall when the answer is kept in the profile rather than in a person's hands. The four sections below take the walls in the same order.
### How does an agent handle 2FA codes?
An agent handles a TOTP code by letting the profile compute it from the stored setup key, the string behind the QR code. The agent names the code field and never sees the seed or the digits. Browserbase's guide describes the alternative for [its cloud browser](/blog/browserbase-alternative): two-step verification "usually require[s] human intervention in the loop", and its two strategies are "Disable 2FA or create an app password" or handing control back to a person through a live view. Turning off the second factor protects the automation and removes the account's protection.
### Where do email verification codes arrive?
Email verification codes arrive at an address that belongs to one profile and to no other. A domain with a catch-all gives each profile its own random address without creating a mail account, and the code is read over IMAP outside the browser, so no second login opens inside the session the site is watching.
### Can an agent use passkeys?
Yes, when the passkey lives in the engine and the machine answers like a real one. The site first asks whether a platform authenticator exists, and that answer describes the machine: Microsoft reported on 1 May 2025 that ["more than 99% of people who sign into their Windows devices with their Microsoft account do so using Windows Hello"](https://www.microsoft.com/en-us/security/blog/2025/05/01/pushing-passkeys-forward-microsofts-latest-updates-for-simpler-safer-sign-ins/). Browserbase's guide takes the other route for its sessions: "you'll often want to disable or bypass them since the required user interactions aren't supported in automated sessions."
### How does the session survive the run?
The session survives when the profile keeps its cookies, passkeys and device identity on disk between runs. A profile that also runs on a second machine travels there encrypted, at every stop and every 15 minutes, and only one machine may hold it at a time, because two machines signing in with the same identity is exactly the pattern a site looks for.
### What about prompts the browser draws next to the page?
A sign-in can end with a prompt the browser draws beside the page, a permission bubble or a device picker. An ordinary automation tool cannot see these prompts, because they are not part of the page, so the run stops without an error.
## Where do you start with your own agent?
Start with the wall your runs hit most often, and keep the secret in [an agent's own browser](/blog/ai-agent-browser), never in the model. The [credentials page of the documentation](/docs/credentials) shows how a login and its setup key are stored against a profile, the [inbox page](/docs/inboxes) how an address is bound, and the [passkeys page](/docs/passkeys) how a key survives a browser that dies badly.