Vault Overview

Secrets and credentials for connecting external services, organized in vaults.

Overview

inference shell provides two ways to give your agents access to external services:

Both live in your workspace's vault. Every workspace has a default vault, and workspaces can create more to organize connections by project or environment.

Concepts

Four things work together. Each one answers a different question.

Provider

A provider is the external service. Each has a slug (acme, openai, google) that everything else points to. The platform lists the common ones with their logo and docs.

A provider the platform doesn't list works too. The first time a key is saved for it, it becomes your workspace's own provider. It takes the name you give it and the logo from its website. Only your workspace sees it. The shared list grows through platform admins, including when a platform app declares a new provider.

Credential

A credential is your connection to one provider. It always belongs to a provider, and it has:

• a type: api_key for keys you paste, oauth for a sign-in, service_account, mcp
• a scope: who can use it (user, team, org)
• a status: connected once it holds what it needs, pending before that

The platform keeps OAuth credentials fresh by refreshing their tokens. An API key credential holds its keys as secrets linked to it.

Secret

A secret is one encrypted key-value pair, such as ACME_API_KEY. It is either:

• linked to a credential: the key belongs to that provider, and apps that ask for the provider receive it
• plain: an environment variable that belongs to no provider, such as a webhook signing token

A plain secret can be attached to a provider later. It then becomes that provider's credential under the same key name, so apps still read it the same way.

Vault

A vault groups credentials and secrets. Every workspace has a default vault, and new workspace credentials and secrets are added to it automatically. Extra vaults let you organize connections by project or environment.

Which one should I use?

• The key belongs to a service (an API key for Acme, OpenAI, fal): add it as an API key credential for that provider. It gets a logo, a scope and a status, and apps that ask for the provider find it.
• The value belongs to no service (a webhook token, a feature flag): add a plain secret.
• The service uses a sign-in (Google, Slack, Notion): connect it as an OAuth credential.

Security

Both secrets and credentials are:

• Encrypted at rest using AES-256-GCM
• Never logged or exposed in task outputs
• Scoped to your workspace: other workspaces cannot access them
• Injected only at runtime — only to apps that require them and only to apps that are verified or user-owned

How they work with apps

Apps declare what they need in inf.yml. Keys that belong to a provider go under credentials:. Values that belong to no provider go under secrets:.

1# inf.yml2credentials:3  acme:                           # the credential slug whose credential supplies the keys4    secrets: [ACME_API_KEY]       # the keys the app reads5    provider:                     # shown if the platform doesn't list acme6      name: Acme CRM7      website: acme.com           # where its logo comes from89  google:10    capabilities: [google.sheets] # OAuth: the capability the app needs11    description: Read sales data1213secrets:14  - key: WEBHOOK_SECRET15    description: Signs outgoing webhooks16    optional: true

When you run the app:

1. We check your credentials and secrets against the list.
2. If something is missing, the run stops and shows what to add. You can paste an API key right there, and it is saved as that provider's credential.
3. Once everything is there, the keys are passed to the app as environment variables.

→ Declaring credentials in inf.yml

Vault in the web app

Secrets and credentials are managed from Vaults in the web app sidebar (/vaults).

Vault list

/vaults lists the workspace's vaults with their credential and secret counts. new vault creates a named vault. Row actions rename or delete a vault. The default vault is created automatically on first access and cannot be renamed or deleted in the web app.

Vault detail

A vault opens at /vaults/{id} with two tabs:

On the default vault's credentials tab, workspace admins see add credential with four options:

The scope column shows who can use each connection (only you, workspace, org, or everyone). Change it from the scope menu when your role allows. See Credential scope.

On the secrets tab, workspace admins can reveal a value (audit-logged), update or delete a secret, and add secret. The link icon on a plain secret attaches it to a provider, making it that provider's credential. The broken-link icon detaches it. Other members see the list without those controls.

Workspace- and user-scoped credentials and workspace-scoped secrets are linked to the default vault when they are created. Platform- and org-scoped credentials are not vault members. Workspaces reach them through scope inheritance. A custom vault holds links to credentials and secrets that already exist in the workspace (see the Vaults API). Deleting a custom vault removes the links and keeps the underlying records.

Legacy deep links such as /vaults?tab=secrets redirect to the default vault's secrets tab, preserving other query parameters. add opens the add-secret dialog prefilled on that key. Optional return must resolve to a path on the app origin (the same rules as post-logout redirects — https://…, //host, and similar values are ignored). After you save the key named in add, the workspace navigates to return when it is valid. The secrets tab reads add and return once on load and removes them from the address bar so a reload does not reopen the dialog.

Credential detail pages

Each provider has a connect and manage page at /credentials/{slug}, for example /credentials/google. Legacy /settings/integrations/{slug} paths redirect there.

→ Credentials overview

Managing Secrets

You can manage secrets via the web UI, CLI, or REST API:

→ Secrets API — GET/POST /secrets, create, update, reveal, delete

→ Vaults API — group secrets and credentials into named vaults

1# List all secrets2belt secrets list34# Set a secret (prompts for the value without echo; or pipe it on stdin)5belt secrets set OPENAI_API_KEY67# Save as a provider credential, or attach an existing key8belt secrets set GRAFANA_API_KEY --provider grafana9belt secrets attach GRAFANA_URL grafana1011# Delete a secret12belt secrets delete OPENAI_API_KEY

Quick Links

Secrets

Store your own API keys and credentials:

→ Environment Secrets

Credentials

Managed connections, their scopes, and how apps receive them:

→ Credentials

Provider guides

Connect to external services with managed OAuth:

→ Credentials overview

Available providers:

• Google Service Account — Sheets, Docs, Drive
• Google OAuth — Gmail, Calendar, personal Drive
• X.com — Twitter API

Next

→ Environment Secrets