← kygit.com

Source code, US hosts, and the encrypted-transfer pattern

A draft position paper for European teams. Worst case first, mechanism second, no adjectives.

Status — draft, September 2026

This paper was written by the people who build KyGit. It is not legal advice, and it has not yet been reviewed by counsel. Every legal statement below carries its date and its source, because several of them are moving. Read it as a map to hand to your own lawyer, not as a substitute for one. Corrections and disagreements are welcome at info@kychee.com.

Kychee is a US company. KyGit's storage is Amazon S3, in the United States. If you came here looking for a European host, we are not one, and we would rather say so in the first paragraph than in the fine print. What we are is a code-hosting arrangement in which the US host cannot read what it holds — and that property is the one European transfer guidance singles out as sufficient on its own.

your side, their side

The short version

Five sentences
  1. No law forbids a European company from keeping private source code with a US provider. There is no deadline, and nobody is out of compliance today for using GitHub.
  2. The GDPR reaches personal data, and most source code is not personal data. Commit author identities, test fixtures, datasets, notebooks, and logs can be.
  3. Transfers of that personal data currently rest on the EU–US Data Privacy Framework. It was upheld at first instance in September 2025; the appeal is pending with no hearing date. If it falls, transfers fall back to standard contractual clauses plus supplementary measures.
  4. The European Data Protection Board names one hosting pattern as effective on its own: data encrypted before it leaves you, under keys the host never holds. That is what KyGit is. Encryption at rest at a host that holds the keys is not that pattern.
  5. This helps only where KyGit is where the code lives. An encrypted copy beside a readable origin changes your durability posture, not your confidentiality posture.

What the law requires today (September 2026)

The honest map first, because a product page that starts with the product is a product page that is hiding something. None of what follows is a reason to buy anything. It is what we found when we asked whether European teams are required to move, and the answer is that they are not.

The GDPR, and what in a repository it reaches

The GDPR applies to personal data. A repository of source code is mostly not personal data. What can be: commit author names and email addresses (your employees' and contributors' data, on every commit, forever), test fixtures and seed data copied from production, datasets and notebooks, log files checked in by mistake. If your repositories are clean of all of that, the transfer rules may not touch them at all, and the rest of this paper matters for trade secrets and contracts rather than data protection. If they are not clean, the transfer rules apply to the whole repository, because you cannot transfer half a git object.

The transfer mechanism, and how stable it is

Transfers of personal data to the United States currently rest on the European Commission's July 2023 adequacy decision for the EU–US Data Privacy Framework. The first direct challenge, Latombe v Commission (T-553/23), was dismissed by the General Court on 3 September 2025. That judgment was appealed to the Court of Justice on 31 October 2025 (C-703/25 P); as of this writing no hearing date has been announced, and commentators do not expect a ruling before late 2026 or 2027. Separately, on 29 June 2026 the US Supreme Court held in Trump v. Slaughter that the President may remove Federal Trade Commission commissioners without cause; privacy advocates argue this weakens the independent-oversight structure the adequacy decision cites.

We do not predict the outcome. We note two facts. The Court of Justice struck down both previous frameworks, Safe Harbor in 2015 and Privacy Shield in 2020. And the fallback is already written: standard contractual clauses plus supplementary measures, per the EDPB's Recommendations 01/2020. That document is the subject of the next section.

The “no AI training” clause

Since 2025 a clause forbidding the vendor from training models on customer data has become standard in enterprise contracts. It is worth being precise about what it reaches. It covers customer data, which lives in your database, not in your repository. It does not reach your own source code unless the code is itself the deliverable (agencies and contractors), the repository contains customer data (see above), or your customer simply asks. Where it reaches a platform that stores its users' code, it bites directly, because the platform is the AI company. We say this plainly because we would rather you not buy KyGit for a reason that does not apply to you.

GitHub's own terms, as published

Dated facts, not accusations. GitHub states that private repository content at rest is not used to train its models. From 24 April 2026, interaction data from Copilot Free, Pro, and Pro+ — prompts, suggestions, and surrounding context, including while working in private repositories — is used for training unless the user opts out; Copilot Business and Enterprise are excluded. An organisation on Business or Enterprise seats is contractually covered today. The point is structural rather than about any one host: a policy is something a host can change, and this one changed once this year. A key the host never received is not a policy.

The rest of the alphabet

the outside is all they get

The EDPB pattern: use case 1

The EDPB's Recommendations 01/2020 on measures that supplement transfer tools (final version adopted 18 June 2021) describe, in Annex 2, a handful of situations in which a technical measure makes a transfer acceptable even where the destination country's law would otherwise be a problem. The first is titled “Data storage for backup and other purposes that do not require access to data in the clear.” Paraphrased below; read the original before you rely on any of it.

The exporter uses a hosting provider in a third country to store data, and the provider does not need to see the data in the clear. The EDPB considers the encryption an effective measure when, in short:

  1. the data is encrypted with strong encryption before transmission;
  2. the algorithm and its parameters are state of the art and robust against cryptanalysis by the public authorities of the destination country, taking their resources into account;
  3. the strength and key length reflect how long confidentiality must be preserved;
  4. the algorithm is flawlessly implemented by properly maintained software whose conformity to the specification has been verified, for example by certification;
  5. the keys are reliably managed — generated, administered, stored, tied to the intended recipients where relevant, and revoked — by the exporter, or by an entity the exporter trusts, in the EEA or an adequate country;
  6. the keys are retained solely under the control of the exporter or that trusted entity.

The reasoning is short. When all six hold, the importer holds ciphertext and no way to open it, so there is nothing for its authorities to compel from the importer. The transfer is of bytes, not of readable data.

generated on your machine

How KyGit maps onto it

Condition by condition, with the place to verify each one without taking our word for it. The fourth row is the one we meet least well today, and it says so.

ConditionKyGitWhere to check
1. Encrypted before transmission Encryption happens on your machine, inside a plain git push, before a byte leaves it. Your repository ciphertext moves directly between your machine and storage — our servers never handle it. What happens on push; the protocol specification.
2. State-of-the-art algorithm Published standards only, in mainstream open-source implementations: Ed25519, HPKE (RFC 9180), XChaCha20-Poly1305, HKDF-SHA-256, SHA-256/HMAC. What is ours is the protocol that composes them. The suite and the security FAQ.
3. Key strength vs. confidentiality period 256-bit symmetric keys, one HKDF-derived key per object, forward-only epoch rotation when a recipient is removed. No date after which the ciphertext is expected to weaken within the horizon a trade secret needs. Keys, envelopes, and what losing them means.
4. Verified implementation Not independently reviewed yet. What exists today: two independently built open-source implementations (a TypeScript client and a Rust verifier that shares no code with it), a frozen test-vector set both must pass, and a recorded adversarial review. An independent cryptographic review is the next gate, and until it is done the vocabulary on this page is the ceiling on what we will claim. Two implementations, the vectors, the review.
5. Keys managed by the exporter Keys are generated on your machine and live in your keystore. Teammates receive sealed envelopes; a removed teammate is cut off by epoch rotation. Run402 holds zero vault keys, so there is no key-management duty on our side to audit. Keys and envelopes; removing a teammate.
6. Keys solely under the exporter's control Run402 cannot decrypt your gitvault or repository history. The confidentiality claim is scoped to the vault: source payload and repository-history content are ciphertext-only; the substrate retains only enumerated plaintext metadata and holds zero vault keys. Who sees what; the threat model.

What the importer can see, stated in full

This is not zero-knowledge hosting, and an assessment that says otherwise will not survive review. The control plane sees that a vault exists and whose it is, principal identities and access times, object counts, ciphertext sizes and ids, generations and cadence. That list is closed and enumerated in the threat model; anything beyond it is a protocol violation. It is also exactly what a subpoena or government order served on us would yield — the legal-process answer states the worst case first and does not claim the metadata is harmless.

Policy versus incapacity

An assessment that relies on a host's policy has to be redone every time the policy, or the host's owner, changes. An assessment that relies on the host's incapacity does not. We hold no key to change our minds with, and that holds against a future us too, including a future us, after an acquisition. That is the sentence we would put in front of a regulator, and it is the reason this page exists.

The copy in your own bucket

Your ciphertext replicates to a bucket you own. We can't decrypt your repository history — and we can't hold it either. If that bucket is in Frankfurt or Dublin, the ciphertext copy stays in the EU, and the exit strategy DORA asks you to write is one paragraph long: if we disappeared tomorrow, your repository is recoverable from a bucket listing and your keys, with an open-source tool. No server required. Provable, not promised.

a mirror is not an origin

Where this does not help

Read this section twice. It is the one your assessor will read first.

For your transfer impact assessment or vendor file

What to cite, in the order an assessor will ask for it:

  1. The observer table in the threat model — the enumerated answer to “what can the importer access.”
  2. The protocol specification and the independent Rust verifier — the answer to “how do we check without trusting the vendor.”
  3. The legal-process answer — the worst case, in the vendor's own words.
  4. This page, for the mapping to Recommendations 01/2020, with its date.

On request we will provide, in writing, a data processing agreement, the sub-processor list (Amazon Web Services), and the same worst-case statement above signed by the company. Ask at info@kychee.com.

Sentences you may quote verbatim from this site: “Run402 cannot decrypt your gitvault or repository history.” “Your ciphertext replicates to a bucket you own.” “We hold no key to change our minds with.” Please do not paraphrase them into something stronger; the exact wording is what we can stand behind.

twenty minutes, honestly

Talk to us

We are talking to European teams now, before we build anything more around this, to learn whether the question above is one you actually get asked. If you are a data-protection officer, a security lead, or an engineering lead at a European company and can spare twenty minutes, we would like to hear where source-code custody sits on your list — including “nowhere.” That answer is as useful to us as the other one.

info@kychee.com, subject “KyGit in Europe.” We are in Amsterdam; a coffee works too.

Sources

one thread, unbroken
By Kychee  ·  Built on run402 Home  ·  How it works  ·  vs GitHub  ·  About  ·  Terms  ·  Privacy  ·  Status

Made with ❤️ in Amsterdam