Security & Data Flow

Designed to SOC 2 trust principles.

Your source code never leaves the machine in readable form.

Last reviewed: April 2026

Data flow at a glance

Encrypted diffs if you're using an IDE, and project meta-data if you're using Claude Code.

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

What crosses the wire

Every category of data, audited.

Data Encrypted client-side? Stored where
Source code, diffs Zero-knowledge ✓ AES-256-GCM Google Cloud Storage
encrypted blob
Intent code blocks Zero-knowledge
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 — TLS in transit Stripe
we never see card numbers
LLM calls (Translation add-on) — TLS in transit Not retained after response
never seen if you BYOK
Local cache
~/.kawa-code/.storage.caw		 ✓ locally generated key 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 data we work with

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.

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.

GitHub Authorization — in depth

How we confirm team access with the least GitHub can grant — and never your code.

Metadata-only permission

Team membership in Kawa Code follows your repository's GitHub collaborators. We read that list through a GitHub App that holds a single permission — Metadata, read-only — the smallest permission GitHub allows an App to have. It cannot read a file.

Terminology

  • Kawa Code Desktop the desktop application installed on each developer's machine.
  • Editor extension our plugin for VSCode, JetBrains, Emacs, and Vim.
  • Kawa API the hosted backend service.
  • Kawa Code AI GitHub App the App a repository admin installs on your GitHub organization, with Metadata: read-only as its only permission.

How access is established and revoked

  1. Alice, Bob, and Charlie are collaborators on a private GitHub repository.
  2. A repository admin installs the Kawa Code AI GitHub App on the organization and selects the repository. The App is granted Metadata: read-only and nothing else — no Contents, no Issues, no Pull requests. GitHub itself will not let it read a single file.
  3. Each teammate links their GitHub account in Kawa Code, or signs in with GitHub. The link requests no OAuth scope at all; Kawa keeps only the GitHub account id and login.
  4. Once a day the Kawa API reads the repository's collaborator list through the App — logins and permission levels, nothing else — and sets the team to the collaborators who have linked a Kawa Code account.
  5. Kawa Code computes encrypted code diffs locally and sends them to the API, which shares them only with that team.
  6. If Charlie leaves the company and loses repository access on GitHub, he disappears from the collaborator list and the API removes him from the team at the next daily refresh. Uninstalling the App withdraws our read of the list entirely.
  7. Code diffs are purged on a regular cycle.

What we hold is an App installation token that can list collaborators and repository metadata, and nothing that can read code: no Contents permission, no clone, no OAuth scope on any developer's account. What the API learns about an installed repository is its collaborators' GitHub logins and permission levels — and that is all.

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

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.

GitHub authorization

Team membership follows your repository's GitHub collaborators, read through a GitHub App with a single Metadata: read-only permission — the App cannot read code.

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.

Yes — and it's the same exposure as any AI coding assistant. When AI conflict resolution runs, your changes plus the overlapping peer changes (reconstructed locally on your machine from the encrypted peer diffs) are sent to the model provider — Anthropic by default — so it can judge and merge them. This does not weaken our zero-knowledge guarantee: the Kawa Code server still never holds your key and never sees code. Teams that require code to never leave the machine can run the resolver against a local model via Ollama.

No. The desktop app reads your local working tree only. Our GitHub App holds Metadata: read-only, which cannot read repository contents, and the server never clones anything.

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)