Privacy Policy
Last updated: October 16, 2026
This page describes what CamelHive actually does with your data today. Where something isn't built yet -- an automatic deletion process, for example -- we say so instead of describing a process that doesn't exist.
What we collect
Account and contact information: when you sign up, we collect your company name, email address, and a password (stored as a salted hash, never in plain text). If you sign in with GitHub or Google instead, we store the stable account identifier that provider gives us -- never your password on that provider.
GitHub App installation: when you connect a repository, we store the GitHub App installation ID and the account login it's installed on, so we know which installation to use to read your repository later. We don't store a separate access token for it -- the App mints one on demand from its own credentials.
Contact form submissions: name, email, project URL, description, and budget, sent as an email to our team through our email provider (Resend). We don't write contact-form submissions to our database.
Early-access requests: when you ask for early access, we store your name, work email, company, and the repository you optionally name, in our database, and we email our team about the request through our email provider (Resend). We use them to get in touch with you about access to CamelHive.
Project metadata: the repository URL and default branch you tell us to audit.
What happens to your code during an audit
To audit a repository, we clone it into a temporary, ephemeral environment (a GitHub Actions runner). That clone is destroyed automatically when the audit finishes. We do not upload it to any persistent storage -- there is no copy of your repository sitting in our database or in cloud storage after the run ends.
During the audit, an AI model reads the contents of files it decides are relevant, guided by our published audit rules. Your code goes only to AI providers that do not train their models on what we send them, and we never keep it beyond the audit.
What we keep after an audit
We keep a record of which commit was audited (repository URL, commit hash, file count and size) -- not the code itself.
We keep the audit findings: for each rule, the result (pass, fail, or undetermined) and its severity.
For findings an AI reviewer produced, we keep the specific file and line number cited as evidence, a short excerpt of the code at that location, the reasoning that led to the conclusion, and -- where the finding was reviewed by our adversarial reviewer step -- whether it was disputed and why. The reasoning, the evidence text and the reason a finding was disputed can themselves quote short fragments of your code, and they are kept (see "How long we keep it"). This is what lets you see why a finding was made, not just the final verdict. It's shown in your internal dashboard and is not included in the audit report we can hand to a third party.
The full exported report (the internal, staff-only document that embeds every citation) is deleted 90 days after we first audit that commit. What stays is your signed attestation (its public verification page shows aggregate counts only) and the report view we build live from the stored findings, with the citations already redacted.
Cookies and local storage
CamelHive sets five cookies, all strictly necessary for the service to work and all set only by us (no third party sets a cookie through our pages). "__Host-ch_session" keeps you signed in: it holds a signed session token, can't be read by scripts on the page (HttpOnly), is only sent to our own site (SameSite=Lax, and over HTTPS only in production), and expires after 12 hours -- signing out deletes it. "ch_oauth_nonce" is set only when you start signing in with GitHub or Google, to make sure the response comes back to the same browser that asked for it (HttpOnly, SameSite=Lax, HTTPS only in production); it expires after 10 minutes and is cleared as soon as the sign-in finishes. "ch_install_nonce" is set only when you connect your GitHub account to CamelHive, so the connection is saved only for the browser and the account that started it (HttpOnly, SameSite=Lax, HTTPS only in production, sent only to the GitHub connection pages); it expires after 10 minutes and is cleared as soon as you come back from GitHub. "ch_verify" is set only when you open the link in your account-verification email: it holds that link's code so it doesn't stay in your address bar while you choose your password (HttpOnly, SameSite=Lax, HTTPS only in production, and sent only to the verification step); it expires after 30 minutes and is cleared as soon as you choose your password. "__Host-ch_device" is set when you sign in with your password or finish resetting it, and remembers that this browser belongs to your account, so that someone else's repeated failed attempts against your account can't lock you out of it in this browser (HttpOnly, SameSite=Lax, HTTPS only in production); it holds a signed token, expires after 90 days, is replaced every time you sign in with your password, and is used for nothing else. Signing out of your account stops it from working in every browser, not only the one you signed out from.
We also keep two preferences in your browser's local storage: "camelhive-theme", whether you chose the light or the dark theme, and "camelhive-theme-dir", which visual style (warm or neutral) you chose. They never leave your browser -- they are not sent to our servers.
We don't use advertising, analytics or tracking cookies, and we don't load any third-party tracker. Because every cookie we set is strictly necessary, we don't show a cookie banner. If that ever changes, this section changes first.
Who we share data with
Neon, for database hosting. Vercel, for application hosting. Resend, for sending transactional email (account verification, contact form submissions, and the notice to our team about an early-access request). GitHub, through the GitHub App you install, to read the repository you authorize. Our AI model provider (see above), to produce audit findings.
We don't sell your data, and we don't share it with anyone for advertising.
How long we keep it
Repository clone: destroyed immediately after the audit run. Never retained.
Citation snippets (the literal code fragment our agent quoted as evidence for a finding) and the full exported HTML report (the internal, staff-only version that embeds every citation): purged automatically 90 days after we first audit that commit -- re-auditing the same commit within those 90 days reuses what's stored and doesn't restart the clock; once they've passed, auditing that commit again takes a fresh copy of the repository, and that new audit's citations and full report are purged 90 days after it. A purged citation is replaced with an explicit, dated placeholder -- never silently blanked. Your published attestation keeps verifying after this happens: it checks aggregate scope counts, never citation text.
Audit findings (pass/fail per rule, file and line), the analysis text we write for each finding (its evidence, its reasoning, and the reason it was disputed, if it was), the commit SHA, and the computed score: retained indefinitely as the audit record -- an audit is evidence of what a codebase looked like at a point in time. The analysis text is not purged, and it can include short fragments of your code quoted literally. It is not a copy of your repository.
Early-access requests (name, work email, company, and the optional repository): kept in our database. There is no automatic deletion for them yet; if you want yours removed, tell us through the contact form below.
Internal run records (an archive our worker keeps for each run, including file citations): stored as a GitHub Actions artifact, not in our database. GitHub deletes it automatically 90 days after the run itself -- a separate clock from the one above, run by GitHub's own infrastructure, not our purge process.
Contact
Questions about this policy: reach us through our contact form.
Changes to this policy
If what we actually do changes, this page changes with it. We'll update the date at the top when we do.