Data, security & privacy

Your credentials never leave On Belay. That's the whole design. On Belay exists to give Claude the right context and scoped access to your tools — without ever handing Claude, or anyone, your raw keys. This page explains what we store, how it's protected, and what we don't store at all.

What On Belay stores

On Belay stores only what it needs to deliver context to Claude and to enforce your guardrails:

Your organization, people, and functional groups — and which people belong to which groups.
The Claude roles and guidelines you write for each group.
The integrations you've connected, and the encrypted credentials for them.
Governance records: approval requests and an audit log of actions taken through On Belay.

It does not store the content of your Claude conversations. More on that below.

API keys and credentials are encrypted at rest

When you connect an integration, On Belay encrypts its API key or OAuth token before writing it to the database. We use libsodium's authenticated secretbox (XSalsa20-Poly1305), with a per-organization key derived from the master ENCRYPTION_KEY via HKDF-SHA256. That master key lives only in the application environment — it is never stored in the database alongside the data it protects.

What this means in practice:

Credentials are never written in plaintext.
A database snapshot alone can't be decrypted — the key isn't in it.
Each organization's credentials are encrypted under a key derived for that organization.

When Claude needs to use an integration, it calls through On Belay's proxy. The proxy decrypts the credential server-side, makes the request, and returns the result. Claude never receives the raw key.

Access tokens are hashed, not encrypted

There are two kinds of secret in On Belay, and they're protected differently. The third-party integration credentials above are encrypted — they have to be decrypted to call your tools. On Belay's own access tokens are hashed — they only ever need to be verified, never recovered.

On Belay's own access tokens are the MCP OAuth access tokens (onbelay_-prefixed) that browser clients receive when you connect Claude, and the personal access tokens (ob_-prefixed) used by Claude Code. Both are stored as SHA-256 hashes, not as the original value. The plaintext token is shown to you exactly once, at the moment you generate it. On Belay keeps only the hash, which is enough to verify a token but not to reproduce it — the plaintext is never recoverable.

Because tokens aren't recoverable, you don't replace one in place. To rotate a personal access token, you create a new one and separately revoke (delete) the old one — multiple tokens can coexist for the same user, so a new token doesn't invalidate the old until you delete it. See Connecting Claude for where to do that.

Conversation content is not stored

On Belay does not log or store the content of your Claude conversations. The connection between Claude and On Belay is the Model Context Protocol (MCP): Claude calls tools, and On Belay answers with structured data — your context, your permitted operations, the result of a proxied call. On Belay has no window into what you and Claude discuss, or what Claude does with a result once it's returned.

Scoped access is the first guardrail

Security here isn't only encryption — it's least privilege. Every person reaches integrations only through the groups they belong to, and groups can be restricted to a specific allowlist of operations. Actions that exceed what a group is allowed to do are stopped, and can be routed to a human for approval instead of silently going through. That's the point of On Belay: the one irreversible action gets a guardrail in front of it.

Deleting your organization

To permanently delete your organization and everything associated with it, contact us at hello@onbelay.ai. Deletion is irreversible and removes your members, groups, integrations, and stored credentials.