Credentials

Managed connections to external services: OAuth accounts, API keys, and MCP servers.


Credentials vs. secrets

The vault holds both, and they solve different problems:

CredentialsEnvironment secrets
WhatManaged connections (OAuth sign-ins, provider API keys, MCP authorizations)Raw encrypted key-value pairs
LifecycleThe platform refreshes tokens and tracks statusYou paste and rotate values yourself
Best forGoogle, Slack, Atlassian, model providers, MCP serversAPI keys for services we don't manage

Both live inside a team's vaults. Every team has a default vault, and teams can create more to organize connections by project or environment.


Connection scope

Every credential has a scope that decides who can use it:

ScopeWho can use itWho can create it
userOnly you, in the team where you connected itAnyone
teamEveryone in the teamTeam admins
orgEvery team in the organizationOrg admins

MCP server authorizations default to user scope: connecting Atlassian, for example, authorizes your account, and results follow your permissions in the external service. A teammate can never act through your personal connection — the runtime refuses it.

Shared (team or org) connections are the fallback for service accounts: connect once with --as team or --as org from the CLI, or from the connection page as an admin. When both exist, a personal connection takes precedence over a shared one.

One boundary worth knowing: a personal connection belongs to you in that team. Switching to another team means connecting again there — your live grants never leak across team boundaries.


Connecting

  • Web: open the service under connectors or the vault and click connect; OAuth happens in your browser.
  • CLI: belt mcp connect <slug> for MCP servers, or add keys directly in the vault.

Apps declare the integrations they need in their inf.yml; at run time the platform injects the matching credential, choosing by scope and precedence. If nothing is connected, the run tells you exactly what to connect and where.


Security

Credentials are encrypted at rest, never logged, injected only at runtime into apps that declare them, and revocable at any time from the vault. Revoking on our side does not revoke the grant at the provider — do both when offboarding.

we use cookies

we use cookies to ensure you get the best experience on our website. for more information on how we use cookies, please see our cookie policy.

by clicking "accept", you agree to our use of cookies.
learn more.