Authenticate with vaults
Register per-user credentials when creating sessions.
Vaults and credentials are authentication primitives that let you register credentials for third-party services once and reference them by ID at session creation. This means you don't need to run your own secret store, transmit tokens on every call, or lose track of which end user an agent acted on behalf of.
The vault reference is a per-session parameter, so you can manage your product at the agent resource granularity and your users at the session resource granularity.
Create a vault
A vault is the collection of credentials associated with an end user. Give it a display_name and optionally tag it with metadata so you can map it back to your own user records.
vault = client.beta.vaults.create(
display_name="Alice",
metadata={"external_user_id": "usr_abc123"},
)
print(vault.id) # "vlt_01ABC..."The response is the full vault record:
{
"type": "vault",
"id": "vlt_01ABC...",
"display_name": "Alice",
"metadata": { "external_user_id": "usr_abc123" },
"created_at": "2026-03-18T10:00:00Z",
"updated_at": "2026-03-18T10:00:00Z",
"archived_at": null
}Add a credential
Two credential categories are supported:
- MCP credentials (
mcp_oauth,static_bearer): each credential is keyed by anmcp_server_url. When the agent connects to a server at that URL at session runtime, the token is injected automatically. - Environment variables (
environment_variable): each credential is keyed by asecret_name(the environment variable name) and stored in the sandbox as an opaque placeholder. When the agent initiates an outbound request, the opaque placeholder is substituted with the real secret at egress. The agent never sees the secret value. Use this for any service that authenticates through an environment variable, such as CLIs, SDKs, or direct API calls.
The actual credential values you supply (token, access_token, refresh_token, client_secret, secret_value) are treated as sensitive, write-only fields and never returned in API responses.
Use mcp_oauth when the MCP server uses OAuth 2.0. If you supply a refresh block, Anthropic refreshes the access token on your behalf when it expires.
The refresh.token_endpoint_auth.type field indicates how to authenticate the refresh call:
none: public clientclient_secret_basic: HTTP Basic authentication with the client secretclient_secret_post: client secret in the POST body
credential = client.beta.vaults.credentials.create(
vault_id=vault.id,
display_name="Alice's Slack",
auth={
"type": "mcp_oauth",
"mcp_server_url": "https://mcp.slack.com/mcp",
"access_token": "xoxp-...",
"expires_at": "2099-12-31T23:59:59Z",
"refresh": {
"token_endpoint": "https://slack.com/api/oauth.v2.user.access",
"client_id": "1234567890.0987654321",
"scope": "channels:read chat:write",
"refresh_token": "xoxe-1-...",
"token_endpoint_auth": {"type": "client_secret_post", "client_secret": "abc123..."},
},
},
)Set refresh.token_endpoint to the token endpoint of the OAuth flow that issued the refresh token, because Anthropic sends every refresh request to that URL and the field can't be changed after the credential is created.
Use static_bearer when the MCP server accepts a fixed bearer token (API key, personal access token, or similar). No refresh flow is needed.
bearer_credential = client.beta.vaults.credentials.create(
vault_id=vault.id,
display_name="Linear API key",
auth={
"type": "static_bearer",
"mcp_server_url": "https://mcp.linear.app/mcp",
"token": "lin_api_your_linear_key",
},
)Use environment_variable to authenticate to external services through an environment variable, such as CLIs, SDKs, or direct API calls. Environment variable credentials work for clients that send the secret value verbatim in an outbound request, so check the client eligibility criteria in this tab before configuring one.
The networking.allowed_hosts array controls which outbound hosts the secret can be substituted for. Use "type": "limited" with a specific list, or "type": "unrestricted" if the caller reaches domains you can't enumerate in advance.
Limiting domains is strongly recommended for security purposes, and prevents your key from ever being shared with unauthorized hosts.
The optional injection_location field scopes where the secret is substituted; the full semantics follow the example.
env_credential = client.beta.vaults.credentials.create(
vault_id=vault.id,
display_name="Notion API key for sandbox",
auth={
"type": "environment_variable",
"secret_name": "NOTION_API_KEY",
"secret_value": "ntn_your-secret-here",
"networking": {
"type": "limited",
"allowed_hosts": ["api.notion.com"],
},
"injection_location": {"header": True},
},
)
if env_credential.auth.type == "environment_variable":
location = env_credential.auth.injection_location
print(f"header: {location.header}, body: {location.body}") # header: True, body: FalseRequest payloads are often assembled from content the agent is working with, so the request body is the broader exposure surface. Most services read an API key from a request header, so enabling only header is the narrower configuration. It scopes substitution to request header values for that credential.
The credential's injection_location controls which parts of an outbound request the secret is substituted into. It is an optional object, a sibling of networking, with two Boolean fields: header (request headers) and body (request body). injection_location is independent of networking.allowed_hosts: allowed_hosts scopes which hosts the secret is substituted for, and injection_location scopes which parts of the request it is substituted into.
injection_location behaves differently on create and on update:
| Operation | injection_location behavior |
|---|---|
| Create credential | If you provide the object, any field you omit inside it defaults to false: {"header": true} creates a header-only credential. Omit the object entirely and both locations are enabled. |
| Update credential | Fields merge individually: {"body": false} disables body substitution and leaves header unchanged. |
A credential must have at least one location enabled, so a create or update that would disable both locations returns a 400 error. Passing an explicit null for the injection_location object or for either field also returns a 400 error ("omit the field instead"). The response always returns both fields with their resolved values.
A placeholder in a disabled location is neither substituted nor stripped. The request is sent to the third party with the literal opaque placeholder string in that location. If a request arrives at the third party containing the literal placeholder string, either that location is disabled for the credential or the destination host is not covered by the credential's networking.allowed_hosts.
The substitution happens at egress, not inside the sandbox. Anything that processes the credential locally sees the opaque placeholder, not the real value: clients that validate the credential format at startup may reject it, and clients that compute a request signature from the secret (for example, AWS SigV4) produce an invalid signature. Environment variable credentials work for clients that send the secret value verbatim in an outbound request, in a location the credential's injection_location enables.
Substitution is outbound only. If a client uses the stored secret to fetch a session token (for example, an OAuth client-credentials grant), the returned token arrives in the sandbox unredacted. For exchange-based flows, perform the exchange yourself and store the resulting token in the vault instead.
Credentials are stored as provided and are not validated until session runtime. An invalid credential surfaces as an authentication or downstream error during the session, which is emitted but does not block the session from continuing.
Constraints:
- Unique key per vault.
mcp_server_url(MCP credentials) andsecret_name(environment variable credentials) must be unique among active credentials in a vault. Creating a duplicate returns a 409. - Keys are immutable. To change
mcp_server_urlorsecret_name, archive the credential and create a new one. - Maximum 20 credentials per vault.
Reference the vault at session creation
Pass vault_ids when creating a session:
session = client.beta.sessions.create(
agent=agent.id,
environment_id=environment.id,
vault_ids=[vault.id],
title="Alice's Slack digest",
)Runtime behavior:
- When no MCP credential matches by
mcp_server_url, the connection is attempted unauthenticated and will error if the server requires authentication. - When multiple vaults contain a matching credential, the first vault with a match wins.
- In multiagent sessions, vault credentials apply to every thread. An agent whose own definition declares the matching MCP server authenticates with these credentials. See Connect agents to MCP servers.
Rotate a credential
Secret values, display_name, and (on environment variable credentials) injection_location can be updated. injection_location updates merge per field, as described in the Environment variable tab of Add a credential. For a running session, an injection_location update propagates the same way as a secret rotation: the session's credentials are re-resolved without a restart, as described in Credential lifecycle, and the updated locations apply to the session's subsequent outbound requests. Structural fields (mcp_server_url, secret_name, token_endpoint, client_id) are locked after creation. To change them, archive the credential and create a new one.
client.beta.vaults.credentials.update(
credential.id,
vault_id=vault.id,
auth={
"type": "mcp_oauth",
"access_token": "xoxp-new-...",
"expires_at": "2099-12-31T23:59:59Z",
"refresh": {"refresh_token": "xoxe-1-new-..."},
},
)Credential lifecycle
Credentials are re-resolved periodically, both during a session and during the vault lifecycle. This ensures that credential rotation, archival, or deletion propagates to running sessions without a restart.
To be notified if a credential is archived, deleted, or fails to refresh, you can subscribe to the vault and credential webhooks associated with those lifecycle changes.
| Event | Trigger |
|---|---|
vault.archived | Vault archived. A vault_credential.archived event is also emitted for each underlying credential. |
vault.deleted | Vault deleted. A vault_credential.deleted event is also emitted for each underlying credential. |
vault_credential.archived | Credential archived, either directly or as a result of vault archival. |
vault_credential.deleted | Credential deleted, either directly or as a result of vault deletion. |
vault_credential.refresh_failed | An mcp_oauth credential cannot be refreshed (invalid refresh token, or irrecoverable error from the OAuth server). |
For mcp_oauth credentials, re-resolution also refreshes the access token if it has expired. If the refresh fails, a vault_credential.refresh_failed event is emitted.
Diagnose an OAuth refresh failure
To diagnose why a refresh failed, call POST /v1/vaults/{vault_id}/credentials/{credential_id}/mcp_oauth_validate (or client.beta.vaults.credentials.mcp_oauth_validate(...) in the SDK). This lets you decide how to handle the failure; the right action depends on the error type.
The top-level status tells you what to do next:
valid: the token works; no action needed.invalid: the grant is gone or the OAuth server rejected the refresh with a 4xx. Prompt the end user to re-authorize.unknown: a transient error (5xx, 429, or network failure). Wait and retry.
validation = client.beta.vaults.credentials.mcp_oauth_validate(
credential.id,
vault_id=vault.id,
)
print(validation.status) # "valid", "invalid", or "unknown"The response is a vault_credential_validation object. mcp_probe includes the failed MCP handshake step; refresh includes the outcome of the attempted refresh.
{
"type": "vault_credential_validation",
"credential_id": "vcrd_01ABC...",
"vault_id": "vlt_01XYZ...",
"validated_at": "2026-04-29T17:12:00Z",
"has_refresh_token": false,
"status": "invalid",
"mcp_probe": {
"method": "initialize",
"http_response": {
"status_code": 401,
"content_type": "application/json",
"body": "{\"error\":\"invalid_token\"}",
"body_truncated": false
}
},
"refresh": {
"status": "no_refresh_token",
"http_response": null
}
}Other operations
- List vaults or credentials: Paginated, newest first. Archived records are excluded by default (pass
include_archived=trueto include them). - Archive a vault:
POST /v1/vaults/{id}/archive. Cascades to all credentials. Secrets are purged; records are retained for auditing. Future sessions referencing this vault fail; running sessions continue. - Archive a credential:
POST /v1/vaults/{id}/credentials/{cred_id}/archive. Purges the secret payload; the credential key (mcp_server_urlorsecret_name) remains visible and is freed for a replacement credential. - Delete a vault or credential: Hard delete. The record is not retained. Use archive if you need an audit trail.
Was this page helpful?