# The vault & login browser

> Credentials agents can use but never read — vaulted API keys, connected accounts, isolated website sign-in, and action approvals.

Choose where a value lives before handing it to a thread.

## Three places a value can live

| Place in Project Settings | What it's for | What an agent can see |
| ------------------------- | ------------- | --------------------- |
| **Dev variables** | Plain values your app needs in every development sandbox | The actual value in `.env` and the sandbox terminal |
| **Production variables** | Values used when your app is deployed | Not in a sandbox; managers can reveal them in settings |
| **Secrets vault** | Credentials an agent should use without reading | Item names and permitted hosts, or a placeholder in `.env` — not the real credential |

Dev and Production variables never fall back to each other. A plain value needed in both must be entered twice; see [secrets & environment](https://darting.dev/docs/secrets-and-environment/).

## The vault

A vaulted API key lives on the server. For a **header** item, `.env` holds `darting-vault:<KEY>` where an SDK expects a key. This is a working placeholder, not a broken key. On a request to the item's registered provider host, sandbox egress injects the real key; requests elsewhere get no credential. Reading `.env` cannot reveal it.

**AWS** items keep the long-lived key server-side; AWS tools use a temporary role session, not an access key in `.env`. An **OAuth** item has a placeholder and a server-refreshed token injected for its API hosts. A website **login** item puts nothing in `.env`. Adding a vault item removes a conflicting plain value from both variable maps.

Managers configure **Secrets vault** in Project Settings. An agent can offer a secure form for a credential you hold, including vault storage for supported API keys. Never paste one into the team-readable chat. Managers can set which actions require approval.

## Connected accounts

For a supported integration, an agent's card opens the provider's OAuth consent screen. A project manager authorizes it; the token goes straight into the vault, not chat. You can also manage accounts in **Project Settings → Connections**. Requests to the integration's API hosts then carry the token without exposing it to the sandbox.

## The login browser

For a website rather than an API, sign-in happens in a **separate, isolated browser**. The agent's shell and file tools cannot enter it or read its cookies. You can open its live view to handle a captcha or sign in yourself.

There are two ways to start:

- **You sign in.** With no saved login or supported connection, the agent opens the site's sign-in page and hands it to you. You enter your password and second factor in the isolated browser and finish the card. The project saves the session; later visits load signed in, unless the site has expired it. Neither password nor cookies enter the transcript or work sandbox.
- **The agent drives a vaulted login.** A `login` item stores a username, password, and optional TOTP seed. The agent points to the fields; the server fills them and computes any TOTP code. First use on a site's origin parks for a **project manager's approval**. Screenshots are withheld between filling and submitting so a visible password cannot enter the transcript.

Saved sessions restore **only into the login browser**. The browser can also capture an API key shown in a supported provider's dashboard directly into the vault without showing it to the agent.

## Approving actions

A connected account is not blanket permission for every action. A reviewed API request stops **before it is sent**. The turn parks on a card showing method, host, path, and body preview, with **Approve** and **Deny**. Approval permits the identical request once; Deny sends nothing.

Login-browser clicks can be reviewed too: the card shows the page and click point, and Approve performs the click. An agent can mark a delete, payment, or send click as irreversible to require review even without a standing rule. A screenshot that could reveal a filled credential is withheld instead. These decisions approve concrete actions, not exposure of credentials.