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, what we read on your behalf from the services you connect, 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.
  • Data read from the services you've connected — cached API responses and the reports and recommendations derived from them.

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.

Google data: sign-in vs. business data

On Belay asks for two completely different kinds of Google access, and it's worth keeping them apart.

Sign-in data is about you as a person. When you sign in with Google, we receive your Google account identifier, email address, name, and profile photo — the openid, userinfo.email, and userinfo.profile scopes. That's used only to create your On Belay account, sign you in, identify you to your teammates inside your organization, and send transactional email you asked for.

Business data is about your organization's Google properties. This is separate, optional, and always initiated by an admin of your organization — never by signing in. An admin connects Google Analytics, Google Ads, Search Console, or YouTube from Dashboard → Integrations, and consents on Google's own consent screen. On Belay then reads that data on your organization's behalf to produce the analyses and recommendations you've enabled.

The Google APIs we read

Every Google business scope On Belay uses is read-only. On Belay does not create, write, modify, publish, or delete anything in your Google properties through any of them.

  • Google Analytics — analytics.readonly — reads Google Analytics 4 property data (sessions, traffic channels, funnels, e-commerce events) via the Analytics Data API. Powers the Website Optimization Agent, the Advertising fieldset's daily brief, Customer Analytics, and Visibility.
  • Google Ads — adwords — reads campaign performance (cost, impressions, clicks, conversions, conversion value, cost-per-click, impression share) via the Google Ads API. Powers the Advertising fieldset's channel views and the BI Dashboard. Google Ads doesn't publish a separate read-only variant of this scope; On Belay uses it on a read-only basis and does not create, edit, pause, or spend against any campaign.
  • Google Search Console — webmasters.readonly — reads organic search performance (clicks, impressions, click-through rate, average position, top queries and pages) for the Website Optimization Agent's SEO analysis. On Belay does not submit sitemaps or change property settings.
  • YouTube — youtube.readonly — reads channel and video metadata for your organization's channel, on demand, when someone in your org asks their AI agent for it. On Belay does not upload, edit, or delete videos or channel settings.
  • YouTube Analytics — yt-analytics.readonly — reads YouTube Analytics metrics (views, watch time, traffic sources, engagement), on demand, for the same purpose.

Data returned by these APIs is used only to deliver the service to the organization that authorized the connection. It's scoped to that organization, never pooled or combined across customers, and never made available to another customer.

What we never do with Google data

On Belay's use of information received from Google APIs — sign-in data and business data alike — is limited to what's disclosed here. We do not use Google user data to build surveillance systems, make creditworthiness determinations, sell or rent data to third parties, transfer it to data brokers or information resellers, or serve advertising.

We do not use Google user data to train, fine-tune, retrain, or otherwise develop or improve any AI or machine-learning model — not our own, and not any third-party or generalized model.

That distinction matters because On Belay is an AI platform, so it's worth being precise about what happens. When a report or recommendation is generated, On Belay sends the relevant Google data to Anthropic's Claude API at that moment, and the output comes back only to the organization that owns the underlying data. That is inference on your behalf, not model training. On Belay does not retain Google user data for model development, does not use it to build datasets, and does not permit any sub-processor to use it for training.

On Belay's use and transfer of information received from Google APIs to any other app adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Disconnecting and revoking access

You can disconnect a Google integration at any time from Dashboard → Integrations, or revoke On Belay's access directly from your Google Account permissions page. Either way, disconnecting stops all further data collection immediately and deletes the stored credential.

How long we keep data

We keep data for as long as your account is active or as needed to run the service:

  • Integration credentials — deleted immediately when you remove an integration from your organization.
  • MCP Bearer tokens — expire automatically after 90 days of inactivity. You can revoke tokens at any time from Dashboard → Settings.
  • Organization and group data — kept for the lifetime of the organization account, then deleted within 30 days of an account deletion request.
  • User account data, including Google sign-in data — deleted within 30 days of an account deletion request. To request deletion, contact privacy@onbelay.ai.
  • Google API data (Analytics, Ads, Search Console, YouTube, YouTube Analytics) — cached API responses and the reports derived from them are kept for the lifetime of the organization account, so period-over-period analysis stays possible. Disconnecting the integration stops collection and deletes the credential immediately. All retained Google API data for an organization is deleted within 30 days of an account or data deletion request to privacy@onbelay.ai.
  • Integration call logs — kept for 30 days, then deleted automatically.

Who else processes your data

On Belay runs on a small set of sub-processors, each handling data under its own privacy policy:

  • Supabase — PostgreSQL database hosting.
  • Railway — cloud application hosting.
  • Anthropic (Claude API) — the AI model API. Data reaches Anthropic two ways: when Claude makes an MCP tool call at your request, and when On Belay's own scheduled agent and fieldset runs send data to the Claude API on a recurring server-side schedule with no user present, in order to generate the analyses you've enabled — including data read from services you've connected, such as your Google properties. Either way the output returns only to the organization that owns the underlying data, and Anthropic does not use it to train its models.
  • Google — sign-in identity provider, and the source of the read-only business data described above. We do not sell Google user data, and we don't share it with anyone outside the sub-processors named in this section as required to run the service. Concretely, Google API data reaches: Supabase and Neon (encrypted storage and the per-organization cache), Railway (hosting), Inngest (durable job state), Anthropic (to generate a report you asked for), LangSmith (the trace of that AI run), Sentry (only if a run errors), and Slack (only if you've connected it and the report is delivered there). It is never used to train any model, ours or anyone else's.
  • Resend — transactional email delivery (team invitations).
  • Shopify — subscription billing and payment processing through Shopify Managed Pricing. Shopify handles plan selection and all payment data; On Belay never stores card numbers.
  • Neon (a Databricks company) — per-organization PostgreSQL cache branches. Neon was acquired by Databricks, and the linked privacy notice is published by Databricks. On Belay keeps a working copy of the business data your organization connects — orders, customers, products, and search and analytics metrics — so reports render without re-querying your source systems on every page load. Each organization's cache is a separate database branch, and it is deleted when the organization is deleted.
  • Inngest — background job orchestration. On Belay's scheduled runs execute as durable, resumable jobs; the intermediate state Inngest persists to make a job resumable can include the data being analyzed.
  • LangSmith (LangChain) — AI run tracing and cost observability. This one is worth stating plainly: LangSmith receives the full conversation of a traced AI run, not just the model's answer. That includes the results of any data the agent looked up along the way — rows read from your cache such as orders, products, marketing metrics, and search-performance data. In other words, for a traced run LangSmith sees roughly what the model sees. It is used to debug runs and account for their cost.
  • DataForSEO — AI answer-engine and search-results data. On Belay sends your probe questions and your brand and competitor names, and receives back what the AI answer engines and search results say. This is how Visibility measures your presence without holding an account on each engine.
  • Upstash — Redis hosting for short-lived agent conversation context and rate-limit counters.
  • Sentry — application error monitoring. Receives error reports and the diagnostic context attached to them.
  • Slack — where your organization connects it, On Belay delivers reports, alerts, and analyses into your own Slack workspace.

Your rights over your data

Wherever you're located, you can access, correct, or delete your personal data at any time, and you can request restriction of processing or a portable copy of your data. Contact privacy@onbelay.ai and we'll respond within 30 days. Admins can also delete integrations, remove members, and delete the organization directly from the dashboard.

If you're in the European Economic Area or the United Kingdom, you additionally have rights under GDPR/UK GDPR, including the right to object to processing and the right to lodge a complaint with a supervisory authority.

Deleting your organization

To permanently delete your organization and everything associated with it, contact us at privacy@onbelay.ai. Deletion is irreversible and removes your members, groups, integrations, and stored credentials. Retained data is deleted within 30 days of the request.

More questions

If you're evaluating On Belay and have specific security or compliance questions, reach us at hello@onbelay.ai.