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.

Managed Agents API requests require the managed-agents-2026-04-01 beta header, except memory store endpoints, which use agent-memory-2026-07-22 instead. The SDK sets the correct beta header automatically. See Beta headers.

Create a vault

Vaults and credentials are workspace-scoped, meaning anyone with an API key for the same workspace can reference them when creating a session. To revoke access, delete the vault or credential.

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.

cURL

vault_id=$(curl --fail-with-body -sS http://localhost:38080/v1/vaults \
  -H "x-api-key: $OMA_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: managed-agents-2026-04-01" \
  -H "content-type: application/json" \
  --data @- <<'EOF' | jq -r '.id'
{
  "display_name": "Alice",
  "metadata": {"external_user_id": "usr_abc123"}
}
EOF
)
echo "$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 an mcp_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 a secret_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.

Environment variable credentials (environment_variable) are not yet supported with self-hosted sandboxes.

MCP OAuth

Use mcp_oauth when the MCP server uses OAuth 2.0. If you supply a refresh block, OMA 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 client
• client_secret_basic: HTTP Basic authentication with the client secret
• client_secret_post: client secret in the POST body

cURL

credential_id=$(curl --fail-with-body -sS "http://localhost:38080/v1/vaults/$vault_id/credentials" \
  -H "x-api-key: $OMA_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: managed-agents-2026-04-01" \
  -H "content-type: application/json" \
  --data @- <<'EOF' | jq -r '.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.access",
      "client_id": "1234567890.0987654321",
      "scope": "channels:read chat:write",
      "refresh_token": "xoxe-1-...",
      "token_endpoint_auth": {"type": "client_secret_post", "client_secret": "abc123..."}
    }
  }
}
EOF
)

MCP static bearer

Use static_bearer when the MCP server accepts a fixed bearer token (API key, personal access token, or similar). No refresh flow is needed.

cURL

curl --fail-with-body -sS "http://localhost:38080/v1/vaults/$vault_id/credentials" \
  -H "x-api-key: $OMA_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: managed-agents-2026-04-01" \
  -H "content-type: application/json" \
  --data @- <<'EOF'
{
  "display_name": "Linear API key",
  "auth": {
    "type": "static_bearer",
    "mcp_server_url": "https://mcp.linear.app/mcp",
    "token": "lin_api_your_linear_key"
  }
}
EOF

Environment variable

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.

networking.allowed_hosts on a vault credential controls which requests use the secret, not which requests are allowed. For the agent to actually reach a domain, it must also be allowed at the environment level. Both levels must include the domain (either through unrestricted networking or by explicitly listing the domain in allowed_hosts) for a secret-substituted request to succeed.

The optional injection_location field scopes where the secret is substituted; the full semantics follow the example.

cURL

curl --fail-with-body -sS "http://localhost:38080/v1/vaults/$vault_id/credentials" \
  -H "x-api-key: $OMA_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: managed-agents-2026-04-01" \
  -H "content-type: application/json" \
  --data @- <<'EOF' | jq '.auth.injection_location'
{
  "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}
  },
  "display_name": "Notion API key for sandbox"
}
EOF

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

Credentials created in the Console enable header injection only. If your client sends the secret in the request body, such as a form-encoded token request, the placeholder passes through literally and the service rejects it with its own authentication error. Enable body injection in the Console form when you create the credential, or update the credential with {"injection_location": {"body": true}}.

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.

Scope the API key to only the permissions the agent needs. The agent can do anything the key allows, so a key with broader permissions than necessary increases the blast radius if the agent behaves unexpectedly.

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) and secret_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_url or secret_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:

cURL

session_id=$(curl --fail-with-body -sS http://localhost:38080/v1/sessions \
  -H "x-api-key: $OMA_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: managed-agents-2026-04-01" \
  -H "content-type: application/json" \
  --data @- <<EOF | jq -r '.id'
{
  "agent": "$agent_id",
  "environment_id": "$environment_id",
  "vault_ids": ["$vault_id"],
  "title": "Alice's Slack digest"
}
EOF
)

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.

cURL

curl --fail-with-body -sS \
  "http://localhost:38080/v1/vaults/$vault_id/credentials/$credential_id" \
  -H "x-api-key: $OMA_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: managed-agents-2026-04-01" \
  -H "content-type: application/json" \
  --data @- <<'EOF' > /dev/null
{
  "auth": {
    "type": "mcp_oauth",
    "access_token": "xoxp-new-...",
    "expires_at": "2099-12-31T23:59:59Z",
    "refresh": {"refresh_token": "xoxe-1-new-..."}
  }
}
EOF

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

This is a non-exhaustive list of webhooks; see Subscribe to webhooks for the complete list.

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.

cURL

curl --fail-with-body -sS -X POST \
  "http://localhost:38080/v1/vaults/$vault_id/credentials/$credential_id/mcp_oauth_validate?beta=true" \
  -H "x-api-key: $OMA_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: managed-agents-2026-04-01"

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=true to 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_url or secret_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.