Privacy

The short version

• The agent reports verdicts about your cluster's objects, not the objects themselves. Secret values, ConfigMap values, environment variables, manifests and application data never leave your cluster.
• An account is an e-mail address and a password — or a GitHub/Google sign-in. We ask for no name, no company, no phone number.
• Card details never reach our servers. Checkout and billing management run on Stripe.
• Nothing reaches an AI provider unless you are on the AI plan and press the button. Ordinary remediation plans are built from fixed templates, with no model involved.
• This website loads analytics only after you accept it, and you can change that below.

1. This website, and cookies

kubegauge.com is a static site. It has no accounts, no forms and no login, so it collects nothing about you directly.

It does load Google Analytics 4, and it loads it with Google Consent Mode set to denied before anything runs. While consent is denied, Google receives a cookieless signal that a page was viewed and sets no analytics cookie. Only after you press Accept does Google Analytics store its cookies (_ga and _ga_<id>) and receive the usual analytics data: pages viewed, referrer, device and browser, and an approximate location derived from your IP address.

Your choice itself is kept in your browser's local storage under the key kg-consent, with the value granted or denied. It never leaves your browser; it exists so we stop asking.

Change my analytics choice

Our host, Vercel, processes the ordinary request metadata any web server sees (IP address, user agent) in order to deliver the page.

2. Your KubeGauge account

Sign-up asks for an e-mail address and a password, handled by Supabase Auth. If you sign in with GitHub or Google instead, that provider tells us the e-mail address on your account. We never see or store your password.

Our own database stores your user id, your membership in an organization, and the organization's name — which starts out as the part of your e-mail address before the @. Beyond billing identifiers, that is the whole of it: no name, no address, no phone number, no profile.

Account e-mails (confirm your address, reset your password) are sent through Resend from noreply@kubegauge.com. That mailbox does not receive replies.

3. What the agent sends from your cluster

The agent is open source (Apache-2.0) and outbound-only: it accepts no inbound connection and sends one kind of payload to one destination — a scan report to the API, over TLS, authenticated with your cluster's key. The payload is described field by field in what leaves your cluster and formalised by a JSON schema generated from the source. You can read both before installing anything.

What a report contains:

• The cluster name you chose in the Helm values, and the scan timestamp.
• Kubernetes version, a distribution guess (EKS, GKE, AKS, k3s…), and node and namespace counts.
• One result per check: its id, whether it passed or failed, the namespaces involved, and the objects involved as kind/namespace/name strings.
• Namespace posture (Pod Security Admission labels, whether a default-deny NetworkPolicy exists), workload posture (booleans such as runAsNonRoot or privileged), risky RBAC bindings by name, and the NetworkPolicy evaluation graph.
• For the image check: image references, CVE counts and the ids of the top findings. The scanner runs inside your cluster; no SBOM is uploaded.

What a report never contains:

• Secret values. They are never read into the report, and a test in the agent fails the build if a change ever makes one reachable.
• ConfigMap values. Only key names are used, for the check that looks for credentials stored in the wrong place.
• Pod environment variables, container command lines, volume contents and logs.
• Your manifests, and any application or customer data flowing through your cluster.
• Anything about the person who installed the agent.

Be aware of the flip side: object names do leave — namespaces, workloads, roles, bindings and image references. In some organisations names alone are sensitive. If that is you, read the schema first.

4. Remediation plans, and the AI step

Two things share this feature's name, and only one of them involves a model.

The plan you get by default is generated without any AI. Opening a finding's remediation asks our own service for a template plan: the steps come from deterministic, per-check templates held inside that service, no model is called, and no provider key is even needed for it to work. This path is on every plan, Free included. It does send the finding's data from our API to our remediation service — that service runs on our own private network inside Fly.io, with no public address and nothing else able to reach it, so this hop is our infrastructure and not a third party.

AI composition is the opt-in step on top of that. It runs only when you press the button, and only for organizations on the AI plan — the API checks the plan before the request leaves it, and caps it at 30 compositions per day per organization. This is the only path that sends anything to a third-party LLM provider.

What a composition sends, per finding (at most 20 in one request):

• The check id, category, title, status and severity.
• The affected namespaces and the affected objects, by name.
• The remediation text from our own catalogue.
• The free-text instruction you typed into the box, if you typed one.

Not sent: your cluster's name, Kubernetes version and distribution — the request format has an optional field for those, which the dashboard leaves empty and the service never places in a prompt — the catalogue's explanatory text, and everything else in the report. Even on this path the model does not write the commands: it picks which of our deterministic templates apply and writes the summary around them.

Our remediation service stores nothing. It has no database of any kind; the prompt and the answer exist only for the length of the request.

We are not naming the provider on this page yet. Which company processes a composition, and under which country's law, is settled by deployed configuration rather than by anything published in our source code — so naming one here would risk naming the wrong one, and a privacy policy that names the wrong processor is worse than one that admits the gap. It is listed as unresolved in the notice at the top of this page. If that matters to you, leave AI composition alone until it is named: every other part of KubeGauge, template plans included, works without it.

5. Billing

Payments run on Stripe. You enter card details on Stripe's own hosted checkout page and manage the subscription in Stripe's customer portal — card numbers never reach a KubeGauge server, and we could not store them if we wanted to.

We send Stripe an identifier for your organization; Stripe collects the billing details itself. We store back what we need to know which plan you are on: the Stripe customer and subscription ids, the price id, the subscription status and the current period end.

6. Where data lives, and for how long

Accounts and scan history are in a Postgres database hosted by Supabase in the United States (us-east-1). The API runs on Fly.io in Ashburn, Virginia. The remediation service runs on Fly.io too, on a private network with no public address. If you are in the EU or UK, using KubeGauge means your data is transferred to and processed in the United States.

Scan history is kept for as long as your plan allows:

• Free — 7 days.
• Pro and AI — 90 days.

The clean-up runs every time a cluster reports: anything older than your window is deleted then. One honest consequence — a cluster that stops reporting stops being pruned, so its last window sits there until you delete the cluster or ask us to remove the account. Deleting a cluster in the dashboard deletes its reports and score history with it.

Downgrading never deletes anything. Clusters beyond your new limit stop being scanned; what they already reported stays.

7. Keeping organizations apart

Separation is enforced in the database itself, with PostgreSQL row-level security. Every table holding customer data carries a policy scoped to the organization, and the API connects with a role that cannot bypass it — so a query that tries to read another organization's rows returns nothing rather than being politely filtered in application code.

8. Who else processes data

The agent's container image and Helm chart are distributed through the GitHub Container Registry. That is a download; no data of yours passes through it.

9. Logs

The API keeps no access log of who called what. IP addresses are held in memory to enforce rate limits and are discarded within minutes; they are never written to a table or a log line. Application logs carry internal identifiers, not e-mail addresses.

Our hosting providers keep their own edge and platform logs, which do include IP addresses and user agents. That is outside our control and governed by their policies.

10. Your choices, and how to ask

• Analytics on this site — accept or decline, and change it whenever you like using the button in section 1.
• Stop the agent — helm uninstall ends all collection immediately. Revoking the cluster key in the dashboard cuts it off just as fast.
• Delete a cluster — self-service in the dashboard; its reports and scores go with it.
• Access, correct, export or delete your account — there is no self-service button for this yet. It is a manual request today, which is why the contact address at the top of this page needs to be published before this policy is final.

11. Changes

If this changes, the date at the top changes with it. The page lives in a public Git repository, so its history is public too.