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.
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
loginitem 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.