TinyFish Vault: Your Web Agent Can Now Log In Without Touching Your Passwords | TinyFish Blog<br>ContactLog InLog In

Products<br>SearchFast, structured web search<br>FetchAny URL to clean content<br>AgentMulti-step web automation<br>BrowserStealth Chromium sessions

Resources<br>DocumentationAPI reference and guides<br>IntegrationsConnect with your stack<br>BlogProduct updates and insights<br>CookbookOpen-source examples

PricingPlans, credits, and billing

Enterprise<br>OverviewEnterprise-grade web data<br>Use CasesWhat teams are building<br>CustomersSee who builds with TinyFish

ContactLog In

Back to Blog<br>Web agents are genuinely useful, until they hit a login screen.

If your agent can't get behind the auth wall, it can't reach your admin dashboards, supplier portals, or distributor sites. And if it can't get there, you're still doing the work yourself. Which kind of defeats the point.

The standard workarounds all have the same problem.

Put the password in the prompt. Works. Until your credential lives in the context window, in your logs, in your traces, and in whatever a prompt injection decides to do with it.

Write a hard-coded login script. Great until the portal adds SSO, shuffles its markup, or throws a redirect. Now you're maintaining per-site brittle scripts; the exact thing you were trying to avoid.

Wrap it in cleanup guardrails. Let the AI log in, then strip the credential afterward. In theory: elegant. In practice: the cleanup logic is exactly what doesn't run when the flow crashes.

The common thread in all of these: the AI has the credential. Every mitigation is damage control around that fact.

Why does the AI need the password at all?

That's the question we started with. Not "how do we safely give the AI a password?" but whether it needed one in the first place.

Password managers solved this a long time ago. You don't copy passwords out of 1Password and paste them into forms. The manager detects the field and fills it. The secret never hits your clipboard.

Same idea applies here. Your web agent is actually really good at the hard part: finding login forms, handling redirects, navigating SSO flows and cookie banners. Typing the password is the easy part. And it's the part that doesn't need AI.

So we separated them. The agent handles the where. The platform handles the what. The password never enters the model's context.

That's TinyFish Vault.

How the credential isolation actually works

Two participants. No shared state about the secret.

TinyFish Web Agent navigates the page. It identifies form fields, handles cookie banners, SSO steps, and redirect chains. It knows a credential exists for this run, but it never knows the username, password, or TOTP seed. Its job is spatial: get to the right field on the right page.

The platform holds the mapping between run-scoped credential labels and actual secrets in your vault. When the agent signals it's found a password field on a matching domain, the platform resolves the credential and injects it at the browser level outside the model's context, excluded from model-facing logs and traces.

The credential exists in the browser runtime just long enough to fill the field. The model can't reference what it never received.

Setup

Connect your existing password manager, 1Password or Bitwarden, using standard API credentials (service account tokens or read-only API keys). TinyFish doesn't store master passwords. Secrets are resolved at fill time and discarded. We keep only what's needed to resolve approved credentials at runtime.

Per-run scoping: Each run gets an explicit credential set chosen before execution. An export job gets what it needs. A monitoring scrape gets nothing. A run can't request credentials that weren't approved for it. The model can request a fill for an approved label, but it can't go browsing the vault.

curl -X POST https://agent.tinyfish.ai/v1/automation/run \<br>-H "X-API-Key: $TINYFISH_API_KEY" \<br>-H "Content-Type: application/json" \<br>-d '{<br>"url": "https://your-service-login-url.com",<br>"goal": "Log in and export last month'\''s report",<br>"credentials": ["supplier-portal"]<br>}'<br>Domain matching: Credentials are bound to domains the same way your password manager binds them. A credential for app.example.com fills on that domain and its subdomains. It does not fill on totally-not-example.com even if the page renders an identical form. Matching is based on the browser's actual URL, not page content or visual appearance.

TOTP: If a credential includes a TOTP seed, we generate the code at fill time and inject it through the same browser-level path. The agent sees the MFA prompt, signals the platform, code is filled — the model never sees the seed or the generated value.

What it looks like end-to-end

Connect your vault. Standard API setup, ~30 seconds.<br>Start a run, pick which credentials are available for it.<br>TinyFish Agent navigates to the site and handles whatever login flow it encounters.<br>On domain match, the platform fills the credential at the browser...