Security
Last updated: continuously — this page tracks the deployed configuration
Kubently Cloud gets read access to production Kubernetes clusters, so the honest version of how that works belongs on one page you can send to a security reviewer. Everything below describes what the deployed system does today, not what is planned.
How we reach your cluster
You install an executor with one helm install. The executor opens an outbound connection to the control plane and holds it open. Your cluster accepts no inbound connection from us, and you never upload a kubeconfig — the executor uses a ServiceAccount that lives in your cluster and that you control.
The executor is the open-source Kubently executor, pinned by version. You can read every command it is able to run before you install it. Nothing proprietary runs in your cluster.
Commands are read-only. The executor validates each command against an allow-list, and the ServiceAccount's RBAC is the second, independent limit — even a control plane that asked for a write would be refused by your own cluster.
Tenant isolation
Every API key is scoped to one workspace and resolves only to that workspace's clusters. Records in our database are protected by Postgres row-level security keyed to your authenticated identity, so isolation is enforced by the database itself rather than by application code remembering to filter.
What we store, and for how long
Diagnoses are the sensitive part: they contain pod names, namespaces, events and log excerpts from your cluster. These are never written to our database. They live only in short-lived conversation memory so that follow-up questions in a thread have context, and they expire 7 days after the last message in that conversation.
Postmortems are generated on request from that conversation memory and returned to you. We do not keep a copy.
What we do store, for the life of your account:
- Account and organization records (via our authentication provider).
- Workspace records: cluster names, cluster identifiers, and the API keys and executor tokens you were issued.
- Integration configuration — for example a Slack installation or a connected monitoring tool. Credentials for these are encrypted.
- Subscription and billing state.
All of it is hosted in US East (Ashburn, Virginia). Data is encrypted in transit (TLS) and at rest by our infrastructure providers.
What the model provider sees
Diagnosis is performed by a large language model, which means the cluster output gathered during an investigation — the same pod names, events and log lines described above — is sent to a model provider. There is no way to run this product without that being true, so here is the detail rather than a reassurance:
- The request reaches the model through a routing layer rather than a direct integration with one vendor, and we do not publish which provider serves any given request. The provider can change; what a reviewer is actually buying is the data-handling policy a provider has to satisfy before a request may reach it, which is the next point.
- We do not publish a retention or training commitment for that provider, because we have not verified the configuration that would let us stand behind one — and a security page is the wrong place to state an intention as a fact. Until we can, assume the provider's standard API terms apply. This is worth asking us about before you connect a sensitive cluster: write to security@kubently.io and we will tell you exactly what is in place today.
- On the Team plan and above you can supply your own model API key, in which case the request is billed to and governed by your agreement with the provider rather than ours.
Tool descriptions and results returned by third-party integrations are treated as untrusted input by the agent, on the assumption that anything reaching a model through them may be an injection attempt.
Sub-processors
These are the third parties that process customer data on our behalf. Entries marked optional are engaged only if you connect that integration.
| Provider | Purpose |
|---|---|
| Fly.io | Control-plane hosting and compute |
| Supabase | Account, workspace and cluster records (Postgres) |
| Upstash | Conversation memory and short-lived diagnosis state (Redis) |
| Clerk | Authentication, organizations and subscription management |
| Stripe | Payment processing |
| PostHog | Product analytics and error reporting |
| Cloudflare | DNS and inbound email routing |
| Slack | Diagnosis deliveryoptional |
| Nango | OAuth brokering for BYO-MCP integrationsoptional |
A data processing agreement is available on request — write to hello@kubently.io.
Certifications
We do not hold a SOC 2 report or any other third-party security certification today. We would rather say that plainly than let a badge-shaped gap imply otherwise. If a certification is a hard requirement for your team, tell us — it affects what we prioritise.
Reporting a vulnerability
Send security reports to security@kubently.io. We aim to acknowledge within two business days. Please do not open a public GitHub issue for a vulnerability. We will not pursue legal action against researchers who report in good faith and give us reasonable time to fix the issue before disclosing it.