Security

How Kaer isolates each session, what happens to your data, and the controls a security review will ask about.

Security in Kaer is built around a simple idea: the operator does real work, so it needs a real machine to do it on, and that machine should not outlive the work. The rest follows from there. Each session is isolated, your data stays in your region and is never used to train models, everything moves over encrypted channels, and access to the workspace is controlled at the team level rather than left open.

Per-session VMs

Every operator session runs on its own machine. When a turn needs to execute code, the operator works inside a Linux VM that is booted clean for that session and no one else. There are no leftover files from a previous run and no shared state carried in from another workspace. When the session closes, the machine is destroyed, so nothing it held survives past the work it was created for.

This is what makes it safe to hand the operator a task that touches files, installs packages, or runs a build. The blast radius is one disposable machine, not a long-lived environment that accumulates risk over time.

Your data stays yours

Kaer does not train on your data. Your conversations, files, and code are used to do the work you asked for and nothing else. They are not fed back into model training, and they are not shared across workspaces.

Operator inference runs in the same region as your workspace, so your data stays where you expect it to. If your workspace is provisioned in a particular region, the work the operator does on your behalf is processed there as well, rather than being shipped somewhere else to be handled.

Encryption

Your data is encrypted both in transit and at rest. Connections between you, the product, and the services the operator reaches are protected with TLS 1.3. Data stored on our side is encrypted at rest with AES-256.

Credentials you connect through Connectors are stored encrypted and only used when the operator runs a turn that needs them. They are not printed back into logs or responses, so a connected token does not leak through the normal output of a session.

Access controls

Who can reach a workspace is a team decision, not an open door. Kaer supports single sign-on through SSO and SAML so access lines up with the identity provider your organization already runs. Inside the workspace, role-based access lets you decide who can administer settings, who can run work, and who can only view.

Integration tokens are scoped to the access a given service actually needs, and each one can be revoked individually without disturbing the others. Combined with per-session VMs, this keeps the practical footprint of any single session small and reviewable.

Reporting a vulnerability

If you find a security problem, we want to hear about it. Email [email protected] with the details and we will follow up. We run a responsible disclosure path for issues reported this way.

We are an early-stage company and are direct about where we are: we are happy to share our security overview and answer your security questionnaire on request, and we will tell you plainly what is in place today versus what is on the roadmap. For the formal data-handling statement, see Privacy and Safety.