What goes wrong when a password is in the prompt?
Browser agents stall at logins, six-digit codes, "check your email" steps and new-device prompts. The usual workaround is pasting the password into the prompt. That puts it in the model's context, its transcripts and its logs. OWASP lists security credentials among the sensitive information an LLM application can expose, and notes that instructions telling the model not to repeat data may not always be honored [1].
Four ways to keep it out
Some agent frameworks let you pass secrets separately from the task. In Browser Use, you give sensitive_data and write placeholders such as x_user and x_pass in the task. The model sees only the placeholders, and the real values are put into the form fields after the model call [2]. Browser Use also suggests turning vision off so screenshots do not show the values, and limiting the sites the browser may visit [2].
The secret still lives in your script or its environment, so treat that file like a password file.
If you sign in once and save the browser's state, later runs start signed in and need no password at all. Playwright saves cookies and local storage to a file for this [3]. The saved state is as sensitive as the password while it is valid, so keep it out of the repository.
A password manager can fill the page for the agent. 1Password Secure Agentic Autofill does this inside partner browsers such as Browserbase, and says credentials never enter the LLM context [4]. Bitwarden's Agent Access SDK lets an agent request one credential with human approval and passes it to a process you run [5].
runnerID puts the pieces of a login in one identity: a vault of logins that it types into the page, authenticator codes, its own inbox for emailed codes and sign-in links, saved sessions, site rules with owner approval, and an append-only log with revoke.
- ›1. Add the login and the authenticator key in the owner console at https://api.runnerid.torchrunner.ai/console. Neither is shown back.
- ›2. In the prompt, name the site, not the password: "Sign in to example.com."
- ›3. The agent calls fill_login over MCP, or login(site) in a helper. The password is typed into the page, and the tool result does not include it.
- ›4. Save the session after the first login, so the next run starts signed in.
- ›If runnerID can reach the browser (a hosted browser or one on your own server): Agents that drive a browser runnerID can reach, such as a hosted browser (Browserbase, Steel) or one on your own server, get the strongest mode: runnerID types the password itself.
- ›If the browser is on your own laptop: When the browser runs on your own laptop, the helper uses its local route: the password passes through your own code once to be typed, and still never reaches the model.
- ›If a hosted agent's browser is out of runnerID's reach: Hosted agents that connect over MCP get authenticator and emailed codes returned to them, and approvals and the log work the same. Typing a password into the page needs the runnerID helper next to the browser (Stagehand, Playwright or Browser Use), on a laptop or in a cloud container.
Some sites tell owners never to share their login. Shopify [6], Amazon [7] and the IRS [8] are examples. Use the staff seat, user permissions or authorization they offer instead. runnerID is not for bank accounts.
When should the agent stop and ask a person?
When a step moves money, sends something in your name, or changes an account, have the agent ask first. With runnerID, that is approval by email link. Passkeys are coming; until then, a site that only offers passkeys needs a person.
Questions
How do I log an AI agent into a website without sharing my password?
Keep the password outside the prompt and let something outside the model fill the page. Where the site offers a staff or delegate seat, give the agent its own seat and save that login, not yours. With runnerID by Torchrunner, you save the login once in the owner console, and the agent asks for it by site name. The password is typed into the page, and the model never receives it. Banks, Shopify, Amazon and the IRS tell owners not to share their login, so use the seat or authorization they offer.
Are Browser Use placeholders enough?
They keep the password out of what the model sees, and Browser Use documents that. The value still sits in your script or environment, so store it like any other secret.
Is a saved session safer than a password?
It avoids typing the password at all on later runs. The session file is sensitive while it is valid, so keep it private.
What if the site asks for a code too?
runnerID generates and types authenticator (TOTP) codes, and catches emailed codes in the identity's own inbox. A phone number for SMS codes is coming.
Sources, checked October 24, 2026
- ›1. OWASP LLM02:2025 Sensitive Information Disclosure: https://genai.owasp.org/llmrisk/llm02-insecure-output-handling/
- ›2. Browser Use, Sensitive Data: https://docs.browser-use.com/open-source/examples/templates/sensitive-data and Authentication: https://docs.browser-use.com/open-source/customize/browser/authentication
- ›3. Playwright, Authentication: https://playwright.dev/docs/auth
- ›4. 1Password: https://1password.com/blog/closing-the-credential-risk-gap-for-browser-use-ai-agents
- ›5. Bitwarden, Agent Access SDK: https://bitwarden.com/blog/introducing-agent-access-sdk/
- ›6. Shopify Help Center, Account security: https://help.shopify.com/en/manual/privacy-and-security/account-security
- ›7. Amazon Seller Forums, staff post "User Permissions Guide for Amazon Sellers": https://sellercentral.amazon.com/seller-forums/discussions/t/c63f8fc4-c813-4ba2-a864-ff4eef117223
- ›8. IRS, Online account for individuals FAQ: https://www.irs.gov/payments/online-account-for-individuals-frequently-asked-questions
Steel belongs to its owner. OWASP is a trademark of the OWASP Foundation. Browser Use, Playwright, Stagehand, Browserbase and Bitwarden belong to their owners. 1Password is a trademark of AgileBits. runnerID and Torchrunner are independent and are not affiliated with, endorsed by or sponsored by any of them.