Security

You are installing an agent in your own cluster.

That is a bigger ask than signing up for a hosted platform, so this page states exactly what Kaja connects to, what the agent is allowed to do, what data crosses the boundary, and what we do not have. Some of it is unflattering. It is all checkable.

How Kaja reaches your cluster

One outbound connection, opened by your side, and nothing else.

No inbound ports: The agent dials out to Kaja over TLS and keeps that connection open. Work travels back down it. You open no ports, publish no API server, and need no public IP.
No kubeconfig leaves your cluster: We never receive credentials for your Kubernetes API. Kaja cannot reach your cluster on its own — if the agent stops dialling out, our access ends with it.
We store the agent token as a hash: The install command carries a token that is shown to you exactly once, because only its hash is kept. There is no API that can read it back. Lose it and you regenerate, which invalidates the copy you lost.
You can cut it off: Uninstall the agent's Helm release and the connection is gone. Your apps keep running, because they are ordinary Kubernetes objects that do not depend on us.

What the agent can do

This is the part to read carefully before you install anything.

It runs with full cluster privileges: The agent's ClusterRole grants all verbs on all resources. It creates namespaces, workloads, secrets, storage and operators across the cluster, which is what makes one-click databases and managed ingress possible — and it means the agent can do anything in that cluster.
Treat it as an administrator: Install it in a cluster where that is acceptable. If you are evaluating Kaja, use a cluster that is not also running something you cannot afford to have touched.
It only acts on Kaja's own resources: In practice it reconciles the namespaces Kaja creates, which are labelled and owned by the project controller. The terminal feature independently re-checks those labels on the agent side before it will open a session — the privilege is broad, the behaviour is scoped.
It updates itself: You approve agent upgrades from the console. We publish what changed; a fleet does not silently drift onto a version you did not choose.

What leaves your infrastructure

Resource state: The configuration you enter in the console and the status the agent reports back: apps, projects, domains, revisions, health. This is the state Kaja exists to hold.
Logs and metrics, only while you look at them: They are collected and stored inside your own cluster. Opening a log tail or a metrics panel streams that window to your browser through Kaja. Close it and nothing further is sent; we do not warehouse your logs.
Application traffic, only if you use the gateway: A cluster with its own public address serves traffic directly and we never see it. A cluster with no public IP is published through our gateway, which terminates HTTPS and therefore does see that traffic in the clear. That is the price of the feature, and it is opt-in per cluster.
Builds stay put: Source is cloned and images are built by your cluster, on your hardware. Build output is not shipped to us.

What we store, and how

Secrets are encrypted at rest: Values inside a project secret are encrypted with AES-256-GCM before they are written to the database, under a key ID that allows rotation without re-encrypting everything. Plaintext exists only in memory and on the TLS connection to your agent.
The threat model is storage: The goal of that encryption is specific: a database dump or a volume snapshot should not hand someone every customer's credentials. It is not a claim that Kaja staff can never see a decrypted value.
Secret values are not shown by default: The console lists secret names. Revealing a value is a separate permission, and it is recorded.

Access control in your organization

Roles and per-resource permissions: Admin, editor and viewer, refined per resource. Every delete path checks permission before it does anything.
Terminal access is its own permission: A shell into a running container defeats most other restrictions, so it is granted separately. You can restrict it to admins, or switch it off for the whole organization — which also kills every session already open.
Audit log: Every change is recorded with the account that made it. Entries are retained for 30 days.
Accounts: Authentication is handled by Auth0. Email verification is required before an account can do anything.

What we don't have

If any of these rules Kaja out for you, it should.

No compliance certification: No SOC 2, no ISO 27001, no HIPAA. We are not going to imply otherwise with a badge.
No third-party audit: Kaja has not had an external penetration test, and there is no bug bounty programme yet.
No SLA: Kaja is in beta. There is no uptime commitment, and none is implied by this page.

Reporting a vulnerability

If you have found a security issue, tell us before you tell anyone else and we will work it with you. Use the contact form and say it is a security report — it gets read first.