> ## Documentation Index
> Fetch the complete documentation index at: https://docs.agent-loadout.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Vault: Encrypted Credential Storage for Your Agents
> Store logins, API keys, and TOTP secrets in the agent vault. Scoped access keeps values out of chat transcripts, and every read is logged for your org.
The vault is where an agent keeps the secrets it accumulates over time: the login it created when signing up for a service, the API key it uses to update a CRM, the TOTP secret for a portal that requires two-factor authentication. Credentials stored in the vault never appear in chat transcripts or MCP tool responses unless the agent explicitly reads them with the right scope — and every read is recorded.
## Credential types
A username and password pair. The agent can generate a strong password at creation time; the generated value is returned once from the create call and stored encrypted. Use `get_credential` to retrieve it later.
A single secret string, such as a service token or bearer credential. Stored and retrieved the same way as a login, but without a username field.
An authenticator seed. The `get_totp_code` tool returns the current six-digit code without ever exposing the underlying secret — the code rotates on its own schedule.
## Access scopes
Vault access is gated by three distinct scopes. Issue only what the client actually needs.
| Scope | What it allows |
| ---------------- | --------------------------------------------------------------------------------------- |
| `vault:metadata` | List credentials with names and types, but no values |
| `vault:use` | Read the value of credentials explicitly marked agent-readable, and retrieve TOTP codes |
| `vault:write` | Create new credentials and update existing ones owned by the agent |
A token with only `vault:metadata` can tell the agent what accounts exist without ever revealing a password. Add `vault:use` when the agent needs to log in or rotate a secret. Add `vault:write` when the agent is registering new accounts and needs to store what it creates.
## Working with credentials
```
# List all credentials (vault:metadata)
list_credentials
# Read a specific credential's value (vault:use)
get_credential { "credential_id": "cred_abc123" }
# Get the current TOTP code without seeing the secret (vault:use)
get_totp_code { "credential_id": "cred_xyz789" }
# Store a new login with a generated password (vault:write)
create_credential {
"name": "Error tracker",
"kind": "login",
"username": "support@loadout.email",
"generate": true,
"allowed_origins": ["https://app.tracker.example"]
}
# Rotate an existing password (vault:write)
update_credential { "credential_id": "cred_abc123", "generate": true }
```
```bash theme={null}
# List credentials (vault:metadata)
curl -s https://agent-loadout.com/api/v1/vault \
-H "Authorization: Bearer $AGENT_LOADOUT_TOKEN"
# Create a credential with a generated password (vault:write)
curl -s -X POST https://agent-loadout.com/api/v1/vault \
-H "Authorization: Bearer $AGENT_LOADOUT_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "Error tracker",
"kind": "login",
"username": "support@loadout.email",
"generate": true,
"allowed_origins": ["https://app.tracker.example"]
}'
```
When registering a new account, pass `"generate": true` to `create_credential`. The generated password is returned once so the agent can complete the sign-up form — after that, only `get_credential` can read it, and every read is logged.
## Credential ownership
A credential does not have to belong exclusively to the agent whose token is being used. The vault supports three ownership levels:
* **Agent-owned** — only this agent can read the credential's value. The most common case for logins and keys the agent created itself.
* **Shared with all agents** — any agent in the organization can read the value (with `vault:use`). Useful for shared API keys that multiple agents need.
* **Organization-held** — owned at the org level rather than by any specific agent. Visible in the vault page under the organization's entries.
The Vault page in the dashboard shows all three levels together, with icons indicating each credential's owner and sharing status.
## Audit history
Every time a credential's value is read — whether through `get_credential`, `get_totp_code`, or the REST API — the event is written to the organization's audit history. The record includes which agent made the request, which credential was accessed, and when. Audit history is visible to org members in the dashboard and is retained for 30 days on Pro (365 days with the Extended History add-on).
Credential values never appear in the organization's audit log — only the metadata about the access event (who, what, when) is recorded.
## Local connector
For accounts that require browser-based login rather than an API key, you can pair a computer from the Vault page and use the local connector. The connector executes approved browser and app profiles on your machine without returning passwords, cookies, or page contents to the cloud.
Open the Vault page in the dashboard, click **Pair a device**, and run the pairing command on the computer you want to connect:
```bash theme={null}
bun run connector pair --url https://agent-loadout.com --name "My computer"
```
Run the connector process on the paired machine. It listens for approved requests from the MCP server:
```bash theme={null}
bun run connector serve
```
Define trusted website or app profiles in the connector's config. The agent can use these profiles to perform browser-based actions without ever receiving the underlying credentials.
The local connector supports approved browser workflows and CLI profiles. General browser autofill and arbitrary native-app login are not yet supported.
## Next steps
See the full MCP tool and REST endpoint reference for creating, reading, and rotating credentials.