Nothing changes without you.

What we never do

• Refund, charge, or change prices in Stripe. Money actions are outside the product.
• Edit provider settings, environment variables, or DNS on your behalf.
• Merge anything on our own unless you turned it on, or run a database migration ever. Repairs are proposed as pull requests and verified on a preview — or, where no preview can be checked, reviewed on GitHub by a named person first; a merge happens only when a named person presses Approve, and only against the exact revision that was checked. The one exception is auto-merge for security updates: off for every app until an owner turns it on for that app and accepts the warning, it merges only Dependabot security updates Keelnest has verified on a preview with every check passing, and it can be turned off at any time. Autopilot can prepare and check a fix on its own for an app whose owner turned that on; it never merges one.
• Ask for your passwords. Access uses read-only tokens and restricted keys you create, GitHub App installations, and provider sign-in where a provider offers it — every one revocable at any time. The one password Keelnest keeps is a test account’s, when you give a journey one to sign in with; it is encrypted at rest, typed only into your own sign-in form, and never shown again.

What each connection can read

• Stripe

  CredentialA restricted key you create. You can also connect by signing in to Stripe: a read-only sign-in your client grants.

  ReadsEvents, webhook endpoints, charges and checkout sessions. Card numbers are never requested. Of a charge, Keelnest keeps the amount, currency, time and the domain of the email, for matching, and discards the rest. When a Stripe key has leaked, the account's failed charges, refunds, payouts and transfers since then are counted from events; never a customer.

• Vercel

  CredentialAn access token, plus deploy webhooks.

  ReadsProjects and deployments. Environment variable names are compared between publishes; values are never stored. The same holds for every host below.

• Netlify

  CredentialA personal access token.

  ReadsSites and deploy notifications.

• Cloudflare

  CredentialAn API token.

  ReadsWorkers and Pages projects, their deploys, builds and variable names (never values), and the list of accounts.

• Render

  CredentialAn API key.

  ReadsServices, deploys, custom domains and variable names.

• Fly.io

  CredentialAn access token.

  ReadsApps, releases, certificates and secret names. Fly sends no deploy webhook, so releases are found on the five-minute poll.

• Railway

  CredentialAn account token.

  ReadsProjects, services, deployments, domains and variable names.

• Supabase

  CredentialA personal access token for the Management API. You can also connect by signing in to Supabase, with four read scopes and no write scope.

  ReadsProject health, security advisors, logs and auth URL configuration, and the names of the project's tables for the data exposure check. With a personal access token, when a secret key has leaked: the project's secret-key list, then each of those keys by id, without their values, the legacy JWT secret's status and whether legacy keys are on. Supabase's list also carries the legacy anon and service_role keys in full; Keelnest drops them as the answer arrives and never stores, logs or uses them.

• OpenAI and Anthropic

  CredentialOrganization admin keys, stored with the strictest scope the provider offers.

  ReadsUsage and cost. When a key has leaked, also the API key list (for OpenAI, only if you allowed it): names, the start and end of each key, and whether it is still active. Nothing is ever changed.

• OpenRouter

  CredentialA management key. OpenRouter has no read-only kind, so it could also create or delete keys; Keelnest only ever reads with it.

  ReadsThat the key is a management key, every six hours. While a key from your site is leaked: your key list (names, the start and end of each key, whether it is on, its credit limit) and that key's daily spend. Only the default workspace.

• Sentry

  CredentialAn organization auth token.

  ReadsIssue summaries, error frequency and affected-user counts.

• Error capture

  CredentialA script tag or package you add to your own app.

  ReadsUncaught errors and unhandled rejections, which it sends; never form values, request bodies, headers or cookies.

• GitHub

  CredentialA GitHub App on the repositories you choose.

  ReadsCode, commits and pull requests, plus push, pull-request and Dependabot alert webhooks. It also reads the Dependabot alerts on those repositories: whether they are on, how many are open and which have a fix. It never changes or dismisses one. To prepare a fix it writes to a branch of its own and opens the pull request; nothing reaches your default branch until a named person approves it, except a verified security update on an app whose owner turned on auto-merge. When somebody presses Teach your builder on a verified fix, it opens one pull request that adds Keelnest's rules to the files your AI coding tools read, on a branch it creates, and never merges it. With the config check on for an app, it also reports a check named Keelnest on that app's pull requests, or a comment when the Checks permission was not accepted. It never merges them. The check fails a pull request only when an owner on Studio or above turns on blocking, and it stops the merge only when the repository requires it.

How secrets are stored

Provider credentials are encrypted at rest with a key that lives only in the runtime secret store, never in the database or in logs. Short-lived provider tokens are used wherever a provider supports them. If a key you connected is found in your site’s public code, Keelnest stops using it at once and asks you to connect a new one. Secrets are redacted from logs, screenshots, traces and from every prompt sent to a model. Text from outside Keelnest — error reports sent from visitors’ browsers, commit messages, provider answers — reaches a model only as quoted evidence it is told never to obey. A builder prompt that repeats that text at length, and any step or prompt that links to a web address that is not your app’s or a known provider’s, is held back.

Signing in to Keelnest

Every account can turn on two-step sign-in with an authenticator app and add passkeys. Workspace owners can require two-step sign-in for everyone in their workspace, and we email you when two-step sign-in is turned on or off, backup codes are replaced, or a passkey is added. Workspaces on the Agency and Scale plans can connect their own identity provider over OpenID Connect and require single sign-on for their email domain. The identity provider’s client secret is encrypted like every other credential, and Keelnest keeps none of its sign-in tokens.

Journeys and screenshots

Browser journeys run in isolated, short-lived browsers with no access to your infrastructure. Test accounts are stored as secret references. A payment journey stops before the pay step: nothing is charged, and there is no stored test payment method. When a run fails, the browser keeps one screenshot of the page it failed on, sanitized for credentials and personal data and readable only by a signed-in member of that workspace. Failure screenshots are kept for 30 days. One attached to an incident is evidence: it is kept for as long as that incident is open, and for 30 days after it closes. After each publish, the same kind of browser opens your key public pages, each application in its own isolated browser context, and reads them without signing in, clicking or typing. It keeps one screenshot of each, sanitized the same way. After each publish Keelnest reads your key public pages in a browser and keeps one sanitized screenshot of each. A reading is kept for 30 days after a newer reading of the same page replaces it; the newest one of each key page is kept, because the next publish is compared with it.

The free health check

The free health check performs passive checks only: it fetches public pages and headers the way a browser would. When the site’s own public code names Supabase tables, it asks only those tables, with the public key the site itself ships, for their row counts, and never reads a row. For apps you watch, the same count-only check runs on every publish, with the public key the site ships, on the tables its code or your connected Supabase account names and a few common names such as orders and payments; it never reads a row. Run it only on sites you own or are authorized to test.

Activity and retention

• Connecting or revoking a provider, approving or rejecting a repair, publishing or revoking a client report, changing or archiving an app and adding or removing a client go into the workspace activity feed, with who did it and when. It is the feed your team reads in the app, not a separate audit log, and it is kept for 365 days.
• Acknowledging, assigning and dismissing an incident are recorded on the incident the same way, and a dismissal keeps the reason given for it.
• Observation data is kept for a fixed window per kind — payments, AI usage and daily spend for 62 days, HTTP, SSL and header checks for 62 days, journey runs for 62 days, error events for 15 days — then deleted. The window is the same on every tier.
• Archiving an app stops the watching and keeps what it gathered, which then ages out on the same windows. Deleting one app is not self-serve yet: ask at privacy@keelnest.com. An owner can delete the whole workspace under Settings › General. It is gone 7 days later with every credential Keelnest held, and we hand back the access we were granted where the provider lets us and email you anything you must remove by hand.

Reporting a vulnerability

Email security@keelnest.com with the details. We acknowledge reports within two business days and never take action against good-faith research.