Skip to main content
Gravity Agents Lite is built around one rule: a credential is never handled over chat, email, or a plaintext document — only through a deliberate, purpose-built path. That’s a narrower claim than “Gravity never holds your credentials” — on the fully customer-managed tier this page describes, a specific, small set of values (documented below and in Getting started) legitimately do reach Gravity once, during initial setup, through the single encrypted channel described here — never informally. Every other secret involved in your deployment stays entirely in your own accounts.
This page describes the trust model in general. For the onboarding conversation and the account-setup steps that generate these secrets in the first place, see Getting started.

​
Categories of secret

​
1. Secrets you generate

Most things you create yourself — a personal access token, a third-party tool’s API key, a database credential — go straight into your own stores and are never sent to Gravity at all:
  • Values you generate as part of account setup are pasted directly into your own repository’s encrypted Actions secrets, or your own hosting provider’s environment variables.
  • For these, Gravity never sees the plaintext value, never asks for it in a message, and never stores a copy anywhere.
  • The golden rule: never put a password, API key, or token into email or Slack — even if asked. If a step ever seems to require this, treat it as unusual and confirm through this documentation or a direct conversation first.
A few specific values are the deliberate exception, because Gravity needs them to stand your fleet up in the first place — most notably your Anthropic API key and your key-value store’s REST credentials (see Getting started’s account-setup steps). These get shared with Gravity exactly once, through the same hosted intake page described next — never informally — and Gravity’s use of them is limited to that one-time provisioning step. For any of these — the provisioning-time values above, or a third-party tool’s API key that a specific module needs but doesn’t have its own pre-built collection step — Gravity provides a dedicated, encrypted, hosted intake page — never a chat message or an email thread — for submitting it. That page:
  • Encrypts every submitted value at rest immediately on write.
  • Never redisplays a previously-submitted value — only confirms that something is set for that field, mirroring how GitHub Actions secrets and most hosting providers’ environment variables already work.
  • Is reached only through your own authenticated setup link, the same mechanism used elsewhere in onboarding — never a public or guessable URL.
  • Is decrypted only by Gravity’s own provisioning process, through an internal endpoint that customer-facing tools and chat sessions never touch.

​
2. Secrets Gravity provides

A small number of values — a Gravity-issued service credential, your deployed agents’ internal identifiers — are generated by Gravity as part of standing up your fleet. On this fully customer-managed tier, Gravity’s only access to your repository is a collaborator account with Write permission — enough to push agent code, but GitHub requires Admin permission to manage a repository’s Actions secrets, which Gravity’s collaborator account deliberately never has. So for these values:
  • Gravity gives you each value securely — through the same hosted intake channel described above, or live on a call — never over chat or email.
  • You set it yourself, pasting it into your own repository’s encrypted Actions secrets, exactly like a secret you generated yourself.
  • You can see the secret’s name under your repository’s own secrets settings at any time, and you can delete or rotate it yourself, whenever you want — Gravity has no standing access to change it later.
(On the Gravity-hosted and hybrid tiers, where Gravity owns the repository outright, its deploy process does write these values in directly, since Gravity holds Admin on its own repository. See the three deployment tiers — this page describes the fully customer-managed tier specifically.)

​
3. Secrets that stay entirely with Gravity

A third category never reaches you at all, on any tier: the enrichment APIs (HarvestAPI, You.com, Findymail) that some modules use for LinkedIn/company-data lookups run entirely on Gravity’s own accounts, including on the fully customer-managed tier. You never generate, hold, or see a key for these, and Gravity never asks you to — usage is simply tracked per customer. This is a separate, permanent exception on top of the per-component defaults described in the three deployment tiers — it applies no matter which of the four infra components you own.

​
One-time logins happen live, never over a message

A few connections — email/calendar access, LinkedIn — require a real OAuth consent screen with your own login. These are always completed live, directly in your own browser, during setup or on a screenshare call:
  • The resulting access token goes straight from the OAuth provider into your own credential store — it never passes through Gravity, a message, or a document at any point.
  • Each of these connections can be revoked instantly, at any time, from your own account settings (Google, Slack, LinkedIn, etc.) — no coordination with Gravity required.

​
What this means in practice

  • Nothing sensitive is ever emailed, Slacked, or pasted into a shared document. Every path above either stays entirely inside your own accounts or moves through an encrypted, purpose-built hosted page.
  • Config changes are separate from credentials. The self-serve config MCP server reads and writes ordinary settings (channel IDs, schedule times, thresholds) — it never handles a credential, and its own onboarding tools explicitly defer every credential to the hosted intake page described above rather than asking for one directly.
  • You can always verify. Repository and hosting secret lists show names, never values. Your change history (via get_change_history) shows every configuration edit made through the config server, accepted or rejected. Nothing about your deployment’s credential state is opaque to you.

​
Next steps