Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can an AI Agent Set Up a SaaS Account Without Seeing the Password?

Yes, if a credential manager generates the password and fills the signup form outside the agent's view, with a person approving the fill, the path credential managers now document for agent logins. Check what the agent reads after signup, because the welcome screen and any API key on it reach the model as plain text.

A credential reference travels from a browser record through a bounded route to a separate API destination.

A signup form asks for an email address and a password, and an agent that fills it holds both unless something keeps the password out of its context. Credential manager vendors have documented a way to do that for logins: the manager fills the field, the person approves, and the model directs the action without reading the value. The same mechanism serves a signup form when the manager generates the password. What those vendors do not describe is the page that follows. A new account opens on a welcome screen, a settings page or a console that displays an API key, and the agent reads all of it. This page follows one record type, a new SaaS tenant created by an agent, from the signup form through the pages that come after it. The finding is that a credential manager can keep the password out of the model, while no fill mechanism keeps out the values on the pages that follow, and that gap decides who answers for the new account's keys. Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool? covers an account that already exists; this page covers the account the agent creates.

Key findings

  • 1Password and Browserbase describe Secure Agentic Autofill as a way for "AI agents to authenticate with web services without ever exposing credentials," which covers the fill and not the page that follows it (1Password and Browserbase, 2025).
  • 1Password's design for browser agents states that "the AI agent and underlying LLM never need to see nor handle the credentials," which are injected "if, and only if, the human approves the access," a mechanism for a value the vault holds rather than one a page displays (1Password, Closing, 2025).
  • Browserbase's authentication guidance says to "log in once, then reuse the saved authentication state" through Contexts that store cookies, session tokens and local storage, which keeps the password out of later runs and leaves the session in the agent's hands (Browserbase, Authentication, 2026).
  • GitLab documents that a masked variable's value is replaced with [MASKED] in the job log and that masking "is not a guaranteed way to prevent malicious users from accessing variable values," so a key an agent copied from a first-login page cannot be relied on to stay hidden (GitLab, 2026).
  • A governed environment that replaces values with consistent tokens before any model reads the screen keeps the API key on a welcome page out of the model's context, the gap the fill mechanisms leave open (What Is Least Exposure?).
  • In that environment real values resolve only at the approved destination at the moment of an approved action, so the generated password and the welcome-page token can be stored without the model ever holding either (Can a Credential Vault Protect What an AI Agent Reads?).

What does an agent read on a signup page?

Everything the form shows and everything the agent types into it. A browser agent works from the rendered page, as a DOM extract, a screenshot or both, and chooses the next action from that input. If the agent is told to pick a password, the password is its own output and sits in its context from the moment it is composed. If a person pastes a password into the prompt, the same thing happens. The only way the model directs a fill without holding the value is for a component outside the model to generate the value and type it, which is the design the vendor section describes.

The scope of this page is that rendered page and the pages after it. A governed browser environment covers what the agent reads and does on a rendered page, including dashboards, consoles, settings pages and sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. An account created with a command-line tool or an API call is a different route, with its own controls, and no browser control governs a shell.

For the example record, a new tenant on a monitoring service, the form has four fields: work email, password, organization name and a plan selection. The email and organization name are not credentials. The password is, and so is the session the service opens once the form is accepted. The session is where least privilege stops helping. Least privilege governs which actions an identity may take and which credentials it holds, and it does not govern the content of the screen the agent reads once it is inside (What Is Least Exposure?). An agent that never saw the password still reads every page the password unlocked.

What do the vendors themselves say?

1Password and Browserbase announced Secure Agentic Autofill in October 2025 as a way for "AI agents to authenticate with web services without ever exposing credentials," with credentials "not shared with the LLM or exposed in Browserbase logs and repos" and "real-time approval prompts via 1Password mobile or desktop," and the release describes authentication rather than the account page that opens after it (1Password and Browserbase, 2025). The password manager's own post on browser agents states that "the AI agent and underlying LLM never need to see nor handle the credentials," which are injected "if, and only if, the human approves the access," a design for a value the vault holds and not for a value the page displays (1Password, Closing, 2025).

Browserbase's authentication guidance recommends Contexts that "store cookies, session tokens, and local storage to prevent repeated logins," and for "an authentication flow requiring some level of security" suggests creating an app password, which narrows what the stored session can do and does not describe how a username and password are handled inside an automated session (Browserbase, Authentication, 2026).

1Password's documentation for its OpenShell integration, in beta, states that "secret values never enter the agent process or context" and that "requests to any other host don't receive the credential," which governs credentials an agent sends to a host and not what a page shows it (1Password, Connect, 2026). The architecture page for that sandbox states that the sandbox component "shares the boundary with the untrusted agent, so it never makes policy decisions," a statement about where policy runs rather than about page content (NVIDIA, Architecture, 2026).

What does the account page show once signup is done?

Whatever the service decides a new customer should see, and the agent reads all of it. For the example record, the monitoring service lands the new tenant on a getting-started page with the admin email and a project token for the first integration, shown once. The page is the agent's input, so the token reaches the model as text, and from there it can go into a configuration file, a commit message or a reply. The signup mechanism kept the password out; nothing on this page is covered by it.

Settings pages are the same. As What Can an AI Agent See in Your GitHub Settings? records, GitHub tells users to treat access tokens like passwords, so token pages carry password-equivalent material. Can a Browser Agent Read an API Key It Just Generated? takes the generated key as a class; a signup flow produces one without being asked.

Hiding the value after the fact has a documented limit. GitLab states that "when a job outputs the value of a masked variable, the value is replaced with [MASKED] in the job log," and on the same page that "masking a CI/CD variable is not a guaranteed way to prevent malicious users from accessing variable values" (GitLab, 2026). Masking matches a value in output after the value exists, and no equivalent mask runs on a browser agent's context.

Page in the flow What the agent reads Covered by the fill mechanism
Signup form Email, organization, plan, the password field Yes, when a manager fills the password with approval
Welcome or getting-started page Admin email, first project token No
Settings and API pages Tokens, webhooks, billing contact No
Later runs with a saved session Every page the session unlocks No; the session is the agent's

What does the research record say about a credential the agent holds?

That the credential is what an attacker asks for, and that the defenses are not yet dependable. A study of prompt injection against agentic coding editors reports that "attack success rates can reach as high as 84% for executing malicious commands" (Liu et al., Your, 2026). The editors in that study are not browser agents; the figure is cited for the principle that an agent reading untrusted content can be steered, and a browser agent reads documentation and support pages after signup.

The benchmark record points the same way. One evaluation covers "5 prompt injection attacks and 10 defenses with 10 LLMs and 7 tasks" and offers "a common benchmark for quantitatively evaluating future prompt injection attacks and defenses" (Liu et al., Formalizing, 2024). An agent-level benchmark that followed reports "critical vulnerabilities in different stages of agent operation" and "limited effectiveness shown in current defenses" (Zhang et al., 2025). Neither abstract names a best defense; the point for this page is that an agent cannot be assumed to refuse an instruction to repeat what it holds.

The breach record adds the frame. Verizon's 2026 report states that software vulnerabilities now beat stolen passwords as the top way attackers get in, and that attackers are shifting from tricking people to exploiting systems (Verizon, 2026). An agent that holds a password is a system an attacker can exploit without tricking anyone. The agent is tethered to the person who set it up, with that person's authority and none of the hesitation (What Is a Tethered Agent?), so a credential in its context is a credential in a place that acts at machine speed.

How should a team set up the account so the password stays outside the agent?

Decide where each value lives before the agent opens the form: the password in the manager, generated there and filled with approval; the session in a stored context scoped to an app password where the service offers one; the first token in the credential store, not in the agent's reply. Arcade's authorization question, "can this agent, acting for this user, perform this action on this resource," with its example that an agent "should only get read access unless deletion is explicitly needed," governs what the agent may do once inside and not what it reads there (Arcade, 2025).

Dimension What the vendor pages document What a buyer should verify
Password at signup Manager fills with human approval; model never handles it Whether generation on a new form is covered, not only a stored login
Session after signup Stored and reused; app password where possible Which pages the saved session unlocks
First token on the welcome page Not addressed What the model received from that page
Record of what the model saw Not addressed A per-run record of each screen

The agent should hold a scoped credential and not the administrator's login, the rule Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool? draws from Google's guidance that the super admin account be used only when needed. Does Claude in Chrome Use Your Saved Logins and Open Sessions? finds that a consumer agent can request logins from a password manager, while its use of sessions already open in the browser is not described in the pages reviewed. The cloud version of the decision is in Is It Safe to Let an AI Agent Set Up Your Cloud Environment?.

What does a governed environment change?

A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on placeholders. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For the signup flow it closes the page the fill mechanisms leave open. The manager still generates and fills the password, and the model still never holds it. Then the welcome page renders, and before the model reads it the project token is TOKEN_001. The agent can copy TOKEN_001 into the credential store's form, and the real value resolves there, at the destination the policy approved, when the person approves the submission. A later page that carries an injected instruction to send the token somewhere finds a model holding only the token. Every page the saved session unlocks arrives the same way.

The record is the other change. The vendor pages describe how a value is kept from the model and do not describe what the model saw; the governed environment holds each screen as the model received it, so a reviewer can confirm that the token page reached the model as a placeholder. Its scope is the rendered page and not the terminal, the IDE, the local filesystem, direct API calls or MCP; an account created from a shell keeps the controls of that route.

Methodology and limitations

This page rests on the public documentation and announcements of 1Password, Browserbase, NVIDIA, Arcade and GitLab, three research preprints, the landing page of Verizon's 2026 breach report and existing RedactSure research pages. Sources were read as of October 20, 2026. Quoted facts are cited to the page that states them, and the preprints are cited for what their abstracts state. The 1Password and Browserbase release describes authentication and gives no technical detail on how injection is implemented and no general availability date; the OpenShell integration is in beta.

RedactSure did not test the products hands-on. "Not described in the pages reviewed" means the pages reviewed and nothing broader. The tables summarize the documentation as read and are not configuration guides. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. Examples describe record types, such as a new SaaS tenant created by an agent, and not organizations. The breach figures describe reported incidents in general and are not a measurement of any agent product.

Determinations about whether a signup flow meets a legal, contractual or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test of the organization's own agent against a throwaway account on the service in question, repeated after each release of the agent or the credential manager, since a change to either would change the answer. The date on this page marks when the documents were read, and a later release should be treated as unreviewed.

What the record shows

The vendor pages answer the title question for the form and not for the account. A credential manager can generate and fill the password with a person's approval, and the model never handles it. The page that opens after signup is a different matter: the welcome screen, the first project token and every settings page the session unlocks are the agent's input, and no fill mechanism touches them. The research record shows that an agent holding a credential can be asked for it, and the masking record shows that hiding a value after it exists is not guaranteed. Only one approach, at most one clause of which concerns RedactSure, replaces values before the model reads the page. The quickest proof is a throwaway test account: create one with the agent, then read the run log and ask which values from the welcome page appear in it.

Frequently asked questions

Can an AI agent set up a SaaS account without seeing the password?

Yes, when a credential manager generates the password and fills the signup form, with a person approving the fill, so the model directs the action without holding the value. The vendors who document this describe it for authentication, and a signup form uses the same fill. What they do not cover is the page after the form: the welcome screen and any token on it reach the model as text. Treat the form and the account page as two different questions.

What if the agent is told to choose the password itself?

Then the password is the agent's own output and sits in its context for the whole run, along with every page it reads afterward, including any page that carries an injected instruction. The research record shows that current defenses against such instructions have limited effectiveness, so a password the model composed should be treated as exposed. Rotate it from a session the agent does not control, and move generation into a manager before the next account is created.

Is a saved browser session safer than a stored password?

It is different, not safer. The session keeps the password out of later runs, which is why vendors recommend logging in once and reusing the saved state. The session still unlocks every page the account can reach, and the agent reads each of those pages in full. Where a service offers an app password, use it to narrow what the stored session can do, and store the session with the same care as a credential.

Does the API key on the welcome page stay hidden if the agent never saw the password?

No. The fill mechanism acts on the password field and ends when the form is submitted. The welcome page is rendered afterward and read in full, so a project token shown there reaches the model as plain text, and from the model it can travel into a file, a commit or a reply. Keeping the password out of the context does nothing for the token. If the agent saw the token, rotate it, and ask the service whether first-login tokens can be suppressed.

Can log masking protect a token the agent copied?

Only partly. GitLab's documentation shows what masking does: it replaces a known value in job output with a placeholder, and the same page says masking is not a guaranteed way to stop access to the value. Masking works after the value exists and only where the mask runs. A browser agent's context has no equivalent mask, so a token that reached the model before any log was written is outside the mask's reach, and a log is not the only place a context goes.

What should a security team ask a vendor to put in writing?

Ask whether password generation on a new signup form is covered, or only the fill of a stored login. Ask which pages a saved session can open, and whether an app password can narrow it. Ask what the model received from the welcome page, and whether any record shows each screen as the model saw it. Ask who approves the storage of the first token. An answer that covers the form and is silent on the account page has answered half the question.

About the author

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

How RedactSure Keeps the Welcome-Page Token Out of the Model

A signup produces a password on the form and a token on the welcome page, and the fill mechanisms reviewed above cover only the password.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before: the agent creates the monitoring tenant, lands on the getting-started page, and the project token enters its context, where an injected page can request it. Inside the governed environment: the welcome page renders with TOKEN_001 in place of the key, the agent pastes TOKEN_001 into the credential store and the real value resolves there on a named person's approval.

RedactSure is deploying now with enterprise and government customers. Injection against agentic coding editors succeeds up to 84 percent of the time.

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

The welcome page after signup often shows a project token the agent then carries for the whole run. Bring an account setup your team repeats and see, with test values, what the model reads on that page. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.