korvu
Security

Boundaries you can verify, not badges.

Korvu’s security posture is architectural: the engine is open source and runs inside your network, fixes are verified in ephemeral sandboxes, and the evidence attaches to your commits. This page describes what the system does — not certificates we don’t yet hold.

Korvu Core — open source, auditableKorvu Cloud — waitlist, pre-GA
01The self-host boundary

Security properties you can check yourself.

Each row below is a verifiable property of the architecture, not a promise. The source is public — don’t take our word for any of it.

Your code stays put

by architecture

On self-hosted Core, diffs are read from your Git, fixes are drafted and verified on your machines, and results post back over your network. There is no Korvu-side copy of your source, because there is no Korvu side.

Your LLM, your keys

read from env · never stored by us

The engine calls whichever endpoint you configure — a provider key you hold, or a self-hosted model behind your gateway. On self-host, keys live in your environment; we never see them.

Auditable engine

agpl-3.0 · one engine, one license

The whole loop is open source. Your security team can read what the engine does with a diff before granting it one — and the AGPL keeps the version we run honest with the version you can read.

Evidence attached

receipts on every verified fix

Every proposed fix carries its verification receipt — the commands that ran, what passed, where it ran. The proof lands in your Git history, the audit surface you already trust.

02The sandbox

Untrusted code runs like untrusted code.

A candidate fix is untrusted by definition — that’s why it’s verified. The sandbox that runs your build and tests against it is built to contain it.

verification sandbox · propertieskorvu core
Ephemeralcreated per run, torn down after. nothing persists between fixes.
No networkthe patch runs against your repo’s toolchain with outbound access cut.
Repo-scopedsees one checkout at one commit — not your other repos, not your secrets.
03Korvu Cloud · waitlist

What the managed layer is designed to see.

Cloud is pre-GA, so this section describes design intent — labeled as such. The boundary rule it’s built around: the managed layer runs the fleet; it doesn’t read your code.

a.Metadata, not source. The control plane manages tenants, credentials, billing, and dashboards. Run metadata flows up; diffs and source are processed by the engine.
b.Same engine, same receipts. Cloud operates the open-source loop — verification behavior and evidence are identical to self-host.
c.Posture published at GA. Data handling, retention, and sub-processor details will be documented here when Cloud ships — written down, not implied.
control plane · data surface (design intent)
sees tenants · run metadata · billing events
manages credentials (encrypted) · access · delivery
never your diffs · your source · your repo secrets
pre-GA · design intent — full data-handling docs publish with Cloud GA
04Reporting a vulnerability

Found something? Tell us directly.

Coordinated disclosure, a human on the other end, and credit if you want it. Engine issues can also be filed privately through GitHub security advisories.

a.Email first. [email protected] reaches the people who can fix it — not a ticket queue.
b.We acknowledge, then keep you posted.You’ll hear from us when we’ve reproduced it and when a fix lands.
c.Disclosure is coordinated. We publish advisories once a fix is available, and credit reporters who want credit.
security.txt
Preferred: coordinated disclosure
Languages: en, de, pt
05On the roadmap

What this page doesn’t claim yet.

No certification logos, no “in progress” badges standing in for results. When these ship, they move up the page with evidence attached.

Independent security review

Third-party review of the engine and (post-GA) the Cloud control plane. We’ll publish the artifacts when they exist — not the engagement letter.

◷ on the roadmap

Signed releases & SBOM

Signed container images and a software bill of materials for every Core release, so your supply-chain tooling can verify what you deploy.

◷ on the roadmap

Audit-log export

Streaming engine and control-plane events to your existing log pipeline, in a format your security tooling can ingest.

◷ on the roadmap