What if AI could log in without knowing the password?

A browser test reaches a login page. The AI can find the fields, work out which button to press, and check whether the next page opened. Somewhere along the way, a password has to be entered.

The tempting shortcut is to put the password in the instructions. The test works. The credential has also become part of the model's input, with more places to inspect, retain, and accidentally repeat it.

That leaves a small question with a useful answer: does the model need the password, or does the browser need it?

A name for the key, without the key

Think of a hotel reception desk. You can ask a member of staff to open a meeting room without giving them the master key to take home. The request identifies the room; a controlled process decides whether to open it.

The same distinction works in AI automation. The model can say, “fill the password field using this private reference.” A trusted piece of software replaces that reference with the real value immediately before entering it. The model can reason about the action without receiving the credential as text.

A reference is still useful access. It needs limits on where and when it can be used. Renaming a password while leaving every door open would achieve very little.

Move the boundary before the prompt

In the test-automation code I reviewed for this piece, credential handling starts before model input is assembled. Tests refer to named variables. The runner reads the required values from private files supplied separately from the code, replaces recognised credentials with opaque references, and builds the model's instructions from that protected version.

The browser worker receives the private values through a separate process channel. When the model asks to fill a field with a reference, the worker checks that the reference belongs to the current step and that the page is on a destination declared by the test. Only then does it resolve the value. An unavailable reference stops the step.

That gives three responsibilities a clear owner:

• The test author describes the task. Which account role to use, where to sign in, and what successful behaviour looks like.
• The model works out the interaction. Find the field, request the private input, and inspect the result.
• The execution code handles the credential. Resolve the reference, check its scope and destination, and enter the value.

This also makes changing a password less disruptive: update its private source instead of editing every test that uses it. The private files still need proper storage permissions and access control. Keeping a file outside Git is one useful precaution; it does not make the file a vault.

The return journey matters too

Keeping a password out of the first prompt only addresses its first opportunity to leak. A failed tool call can quote the submitted value. A page can echo a username. A screenshot can capture a revealed password. Those observations may become the model's next input.

The implementation therefore also removes known credential values from returned text and model request text, suppresses detailed errors from private input calls, and masks password fields and page elements containing known credentials before taking screenshots. If masking fails, the screenshot operation fails rather than returning an unmasked image.

Each route needs its own check. Replacing text does not clean an image. Masking a password field does not catch every copy elsewhere on a page. Known-value matching can miss transformed values or secrets it was never told about.

What “the AI cannot see it” actually means

The precise claim here is about keeping recognised credentials out of the model's normal input and output path. The execution process and the target application still handle the real value.

There is a further limit in this implementation: the worker can execute Python. The credential protection is not a sandbox against hostile code running in that same process. Stronger isolation would require a separate service with a narrow interface and independently enforced permissions.

Nor does hiding the password remove the power of a logged-in session. An agent might never see the credential and still be able to delete records or send messages. Controlling what it can do after login is a separate requirement. OWASP's guidance on excessive agency makes that distinction practical: limit tool functionality and permissions, and require approval for high-impact actions.

How I would check the boundary

A successful login is useful evidence that the workflow functions. It says little about where the password travelled.

The repository's test cases inspect prompt and dispatch content for dummy credentials, check that a reference cannot be used outside its active step or on another destination, and check redaction of returned text. Those are the right kinds of questions to ask. Reading the tests does not establish that every route is covered or that a deployed version passes them.

For a release, I would also exercise failure paths with dummy secrets: a missing credential, a rejected fill, a page that echoes the value, and a screenshot that cannot be safely masked. Then inspect the actual model requests and retained artifacts. The evidence needs to cover what leaves the worker, including when something breaks.

If a credential has already reached the model

I would treat it as exposed: revoke or rotate it, invalidate affected sessions where applicable, review its use, and remove accessible copies according to the systems' retention procedures. Deleting one chat message cannot establish that every downstream copy is gone. OWASP's secrets-management guidance covers revocation, rotation, auditing, and handling secrets in logs.

For everyday AI-assisted work, the same starting rule applies: give the assistant placeholder values and configuration names; supply real credentials through the authorised runtime path. If the assistant has tools that can read that private source, the boundary still needs work.

Why this belongs in an AI operating model

I come back to the same habit from quality and delivery: define the rule, decide which component owns it, and look for evidence that it survives failure.

“Do not reveal the password” is a useful instruction. A system that supplies credentials outside model context, checks their use, and controls what comes back gives that instruction something concrete to stand on. That is the kind of platform decision I want to make before a convenient prototype becomes a team dependency.

---

Based on a review of credential-handling code and test definitions in a browser test-automation project. Examples are generalised; employer, application, account, and internal system identifiers are omitted. No new live test run or independent security audit was performed for this article.