Security & Data Flow

Your source code never leaves the machine in readable form.
Here's exactly what does.

This page is a plain-language audit of every byte that crosses the wire. Where there's a trade-off, we say so.

Last reviewed: April 2026


Data flow at a glance

Four stages. Each arrow is labeled with what crosses it.

Client-side encryption boundary (zero-knowledge) · TLS in transit


What crosses the wire

Every category of data, audited.

Data Encrypted client-side? API can read? Stored where
Source code, diffs AES-256-GCM Google Cloud Storage
encrypted blob
Intent code blocks
snippet, code content
AES-256-GCM MongoDB Atlas
encrypted field
Intent & decision management information
titles, descriptions, scope, constraints, rationale
TLS in transit MongoDB Atlas
Account info
email, profile, billing metadata
TLS in transit MongoDB Atlas
Payment details Stripe
we never see card numbers
LLM calls (Translation add-on) unless you BYOK Not retained after response
Local cache
~/.kawa-code/.storage.caw
locally generated key never uploaded Your machine only

What is never stored, anywhere on our servers

  • Your raw working-tree files
  • Source code or diffs in readable form
  • Your encryption keys
  • LLM prompts when you bring your own API key
  • Credit card numbers (handled by Stripe)
  • Repository contents — Kawa Code never clones your repo

What we're honest about

Intent and decision management information — titles, descriptions, scope, constraints, rationale — is shared with your team via our secure API.

What our API enables for your team:

  • Cross-repo decision search would be impossible if every query had to re-derive a per-repo key.
  • Conflict detection across teammates needs the API to compare scopes.
  • Decision evolution (supersedes / contradicts / specializes) runs server-side on metadata only.

For teams that need every byte to stay on their own infrastructure, the self-managed deployment is available.


Threat model

What we protect against, and what we don't.

Protected against

  • A compromised Kawa API server — encrypted blobs are unreadable without keys that never reach the server.
  • A compromised storage backend — same.
  • A malicious or curious Kawa employee — we cannot decrypt your code.
  • Network interception — TLS 1.2+ on every connection.
  • Subpoenas for source code — we cannot produce plaintext we don't have.

Not protected against

  • A compromised developer machine — if your machine is owned, your working tree is exposed regardless of us.
  • A malicious editor extension running alongside ours.
  • Legal process for intent and decision management information — we comply with valid legal process for the records we hold.

Cryptography — for the engineers

Specifics of the client-side encryption boundary.

Cipher

AES-256-GCM

Authenticated encryption with a 128-bit auth tag.

Key derivation

PBKDF2-HMAC-SHA256

600,000 iterations, 32-byte output.

IV / Nonce

12 random bytes per message

Generated fresh from the OS CSPRNG on each encryption.

In transit

TLS 1.2+

All API and storage connections.

Local cache

Locally generated key

Encrypts ~/.kawa-code/.storage.caw at rest. Stays on your machine.


Swarm authentication, in depth

How we confirm team access without ever touching your repository.

For teams that don't require zero-delay response to membership changes, our non-intrusive security model lets us share work alongside your team without requesting access to your code repository.

Terminology

  • Kawa Code Desktopthe desktop application installed on each developer's machine.
  • Editor extensionour plugin for VSCode, JetBrains, Emacs, and Vim.
  • Kawa APIthe hosted backend service.

How access is established and revoked

  1. Alice, Bob, and Charlie are teammates with access to a private GitHub repository.
  2. Each has Kawa Code installed. When they open the repository in their editor, Kawa Code reads the latest branch, commit SHA, and commit date locally from the working tree — never by calling your git provider's network APIs.
  3. Kawa Code sends the latest SHA to the Kawa API.
  4. The API confirms access by comparing the SHA against SHAs posted by other teammates, applying a freshness threshold relative to the commit date.
  5. Once confirmed, the API responds with a common ancestor SHA shared across teammates. Kawa Code uses that SHA to compute encrypted code diffs locally, then sends them to the API to be shared only with teammates who passed the same swarm check.
  6. If Charlie leaves the company and loses repository access, he can no longer pull new commits. The SHA he posts falls behind the freshness threshold, and the API stops sharing diffs with him automatically.
  7. Code diffs are purged on a regular cycle.

This means we route diffs between teammates for private repositories without ever holding repo access tokens, OAuth credentials, or read permissions on your git provider.

Note: Teams that need direct access control through their existing identity provider (SSO / AuthNZ) should use the Enterprise plan, which adds strict B2B authentication on top of swarm.


Infrastructure & compliance

Hosting

Google Cloud Platform, dual-region in the United States. Cloudflare for DNS and edge.

Database

MongoDB Atlas, hosted in a private VPC with no public internet exposure. Encryption at rest, automated backups, and IP allowlisting on the operator path. Intent code blocks are encrypted client-side before they ever reach the database — even with full DB access, our team cannot read them.

Blob storage

Google Cloud Storage. Encrypted blobs only — we cannot decrypt them.

SOC 2

Our internal processes are designed around SOC 2 controls. We have not yet completed a third-party audit; the report is on the roadmap. We will update this page when certification is in hand.

Swarm authentication

Team membership is established by continuously confirmed commit SHA matches — not by granting Kawa Code access to your repository.

Self-managed option

For teams that need every byte to stay on-prem, the self-managed deployment removes the hosted API entirely.


Security FAQ

No. The encryption keys for diffs and code blocks are derived on your machine from inputs we never receive. Even with full database and storage access, our team cannot reconstruct your code.

No. The desktop app reads your local working tree only. The server never has repository access — that's what swarm authentication exists to avoid.

Yes. The Translation add-on uses our hosted LLM service by default for convenience, but you can configure your own OpenAI or Anthropic API key. With BYOK, prompts go directly from your machine to the LLM provider — our API is not in the loop.

All hosted infrastructure is in the United States. EU and Japan data residency is on the roadmap; reach out if you need it sooner.

Yes. Deleting your account purges your account record, intent and decision management information, and the encrypted blobs associated with your repositories. See the Privacy Policy for retention details.


Responsible disclosure

Found something? We want to know.

Email [email protected]

security.txt (RFC 9116)