Passwords & Credentials

Most useful automations live behind a login. Passwords is the workspace credential store that makes that safe: credentials are stored by website, and when an agent reaches a sign-in page it checks Passwords for that site. No secrets pasted into chat, no credentials baked into a workflow.

How credentials get in

Step 1

Automatically, while building. When the Builder agent hits a login it raises a secure Save website credentials form. What you enter is saved to Passwords under that site and reused on every future run. Usually you never visit this page at all.

Step 2

Manually. Use Add Website to register a site, then Add Credentials for each login it needs. The dialog has three tabs (Login, Secret, 2FA) so the same site can hold a username-and-password pair, a standalone secret, and a TOTP seed side by side.

Step 3

One-time import. Bring in saved logins from a browser export, a 1Password export file, or a compatible CSV.

Step 4

Live sync. Connect 1Password keeps Passwords in step with your vault: Sync Now for an immediate refresh, Disconnect to stop.

What you can store

Each website can hold multiple credentials, and each credential can carry:

• Logins. Username and password pairs.
• Secrets. API keys, PINs, and other standalone values.
• TOTP codes. Store the 2FA seed once and the platform generates a fresh time-based code at the moment of sign-in, every run. Sites with authenticator-app 2FA stop needing a human.
• Custom fields. Anything else a site's sign-in flow asks for.

The life of a credential: from Build to run time

Here is the full journey, using the Limit portal as the example:

Step 1

During Build, the agent hits a login. You've asked it to check an order in the Limit portal; the portal wants a username and password. The agent raises the secure Save website credentials prompt in chat.

Step 2

You fill in the form once. The credential is saved to Passwords under limit.com with a key, say #limit_login. The value never appears in the chat transcript; the agent signs in and carries on with the task.

Step 3

The compiled workflow holds only the reference. When you Save, the sign-in block's instructions say to authenticate with #limit_login. The graph, the editor chat, and every export contain that token and nothing more.

Step 4

At run time, the platform resolves it server-side. When a launch reaches the sign-in step, the secret is looked up and handed to the agent at the moment of sign-in, on that site. It is never written into the run log, the session transcript, or the API response.

You'll also see #key references in the variable store, where a parsed input can be bound to a credential key. A bound field stops being something callers provide: it is excluded from the launch form and the API contract, so people and systems launching the workflow never supply or see credentials.

Rotating a credential

Because workflows hold references, rotation is a one-place change: update the credential on the Passwords page (or let 1Password sync carry it in), and every workflow that references it picks up the new value on its next run. No edits, no republish.

The security model in one paragraph

Credentials are encrypted at rest. The UI shows previews only, never full secret values. Agents receive a credential only when they're on the matching website, and only the credential for that site. Everything a workflow carries around is a #key reference that's worthless outside your workspace.