We market Kerno as "your data, your server." This page shows exactly what that means — what stays on your machine, what leaves it, and why.
Where your data actually lives
When you run Kerno on your infrastructure, the following all stay on your server and never reach us:
- Your inbox index, calendar data, Slack history, Linear issues, Notion pages, and anything else your connectors have read.
- Your conversation history with Kerno.
- Your learned preferences (the SOUL.md system).
- Encrypted OAuth tokens for connected services.
- Vector embeddings of all of the above.
We have no access to any of this. We don't run a database on your behalf; we don't back your data up to our cloud; we don't ship telemetry containing your data.
What leaves your server (and why)
Three things leave your server in the normal course of operation:
- LLM API calls.Unless you configure a fully local model (Ollama, llama.cpp, vLLM), each prompt is sent to the LLM provider you chose (Mistral, OpenAI, Groq, Anthropic, etc.) for inference. The provider's data-handling policy applies — all major providers operate no-retention modes under commercial API plans. Kerno sends only the prompt and relevant context for that specific request. Choose a local model and this becomes zero.
- Licence verification. Your instance contacts our licence server once per day to confirm the key is valid. The request contains the licence key and a minimal request identifier. It does not contain your prompts, your connector data, or any operational content.
- Outbound connector calls.When Kerno acts on your behalf — sending an email, posting to Slack, creating a Linear issue — it calls the relevant service's API using the credentials you provided. That's a direct call from your server to, say, Google; it does not pass through us.
Secrets at rest
- All OAuth tokens, API keys, and configuration secrets are encrypted with AES-256-GCM before being written to disk or Postgres.
- The encryption key is either supplied via environment variable or auto-generated to a permission-0600 file inside your memory volume on first boot. We never transmit or store it.
- Secrets are masked in the admin UI. Saved values display as
••••••••and are never returned by any GET API. - Kerno's own internal API uses a random 256-bit key shared only between the engine and the web UI. The key is auto-generated on first boot when a database is available.
Authentication
- Kerno uses Google OAuth as the sign-in mechanism. Only email addresses on your allowlist can log in.
- Sessions are signed with an auto-generated auth secret. JWT tokens never leave your server.
- There is no "Kerno-operated login" — we do not hold any of your user credentials.
What we log on our servers
The marketing site at getkerno.ai logs:
- Aggregated, cookieless page views via Plausible Analytics (no personal data).
- Contact-form submissions you explicitly send us.
- Licence verification requests (see above — no personal or operational data).
We do not log anything from running Kerno instances. If we ship crash reporting or opt-in telemetry in the future, it will be clearly disclosed and disabled by default.
Network posture
- The Kerno web UI is designed to run behind HTTPS. A reverse proxy (Caddy, nginx, Railway's built-in proxy) is assumed to terminate TLS.
- Kerno itself performs input size limits (10 MB request cap), path sanitisation on uploads, and constant-time comparison on API key checks to guard against timing attacks.
- The licence-verification endpoint and the contact form have rate limits to prevent abuse.
Dependencies and supply chain
- Kerno pins dependency versions in lockfiles and rebuilds Docker images on each release.
- Major dependencies (Next.js, Node, Postgres, pgvector) are tracked for security advisories.
- We don't use dynamic remote code loading; everything Kerno runs is baked into the image you pulled.
Reporting a vulnerability
If you find a security issue, please email security@getkerno.ai with details. We'll acknowledge within 72 hours and work with you on disclosure timing. We don't run a formal bug bounty yet, but genuine findings get a thank-you, a public credit (if you want it), and we'll credit you in the changelog.
What we haven't formalised yet (honest list)
- SOC 2 / ISO 27001 audit — not done. Kerno is a solo-maintained product; enterprise compliance frameworks will come if and when we have enterprise customers who need them.
- Penetration test — not independently audited yet. We'll publish findings once that happens.
- Formal bug bounty program — see above, not yet.
If these gaps are blockers for your organisation, please get in touch — a consulting engagement can include custom security work and formal documentation.