Let preview_type type a request_secret secretRef, so agents can sign in without seeing the password

[Luzivog]

Problem

An agent can't sign in to a site in a T3 browser tab without seeing the password. preview_type takes only literal text, so the value passes through the model and the tool call. Once it's in the page, preview_evaluate can also read it back from .value. We've seen an agent do exactly that.

Since #15328, an environment's tabs run in the server's own Chromium. That makes the gap harder to work around on a remote host. Anything that fills a field through the desktop app's local webview, including the Electron-main design in #7346, can't reach a tab that runs on the server.

Idea

request_secret already produces a one-use secretRef. It's bound to the project, expires after 24 hours, and the server consumes it without the value reaching the transcript or the model. Today only schedule_task's webhook signature accepts one. Let preview_type accept it too, in place of text:

preview_type({ locator: "input[type=password]", secretRef, submit: true })

The server consumes the ref and types the value the same way it types text. The result says only that the field was filled.

Server browser tabs could come first. There, the secret store and the browser live in the same server process, so the value never crosses an RPC contract, a client, or a desktop host. Desktop tabs could follow later, or refuse with a clear error until then.

Guards it probably needs

These follow #7346's prototype findings:

• The value stays in the page after filling. Either fill and submit in one step, or refuse preview_evaluate and recording on that tab until it navigates away or the field is cleared.
• Bind the ref to an origin. request_secret could take an optional origin, so the card says where the value will be typed. preview_type would then refuse if the tab's top-level origin differs at fill time. That stops a prompt-injected agent from typing the user's password into another site.
• Never echo the value. Keep it out of tool results, errors, logs, traces, and action history.

Why this shape

• It reuses what already exists: secretRef, SecretRequests.consume, and the server browser's typing path.
• It's provider-neutral and needs no vault integration. A host-side password-manager source (Reference password-manager items (Bitwarden first) in provider environment variables #14951) or credential profiles (Secure project-scoped credential profiles for preview-browser test logins #7346) could later produce the same kind of reference, so preview_type wouldn't need to change again.
• It's the browser counterpart of Let agents consume request_secret via Shell (secretRef → env/stdin) #17266, which asks for secretRef in shell commands.

Limits

• The user still enters the value in the card each time, since a ref works once. This keeps the agent away from the password, not the user out of the loop. Fully autonomous sign-in needs a reusable host-side source, as in Secure project-scoped credential profiles for preview-browser test logins #7346 or Reference password-manager items (Bitwarden first) in provider environment variables #14951.
• It protects the model/tool boundary, not the host. An agent with shell access on the same machine can still read what the server's user can.

Questions

1. Does this fit T3's direction for agent sign-in?
2. Would you rather take it as a separate small change, or as the first slice of Secure project-scoped credential profiles for preview-browser test logins #7346?