Vault: Encrypted Credential Storage for Your Agents

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

Login

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.

API Key

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.

TOTP Secret

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

MCP tools
REST API

# 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 }

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

Pair your computer

Open the Vault page in the dashboard, click Pair a device, and run the pairing command on the computer you want to connect:

bun run connector pair --url https://agent-loadout.com --name "My computer"

Start the connector

Run the connector process on the paired machine. It listens for approved requests from the MCP server:

bun run connector serve

Configure profiles

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

Vault API reference

See the full MCP tool and REST endpoint reference for creating, reading, and rotating credentials.

Get Started

Core Concepts

Guides

Account & Billing

Vault: Encrypted Credential Storage for Your Agents

Credential types

Login

API Key

TOTP Secret

Access scopes

Working with credentials

Credential ownership

Audit history

Local connector

Next steps

Vault API reference

​Credential types

Login

API Key

TOTP Secret

​Access scopes

​Working with credentials

​Credential ownership

​Audit history

​Local connector

​Next steps

Vault API reference

Credential types

Access scopes

Working with credentials

Credential ownership

Audit history

Local connector

Next steps