Privacy by design: SG/Send, sgit, and the value of constraints

There is a category of file with nowhere good to live. A risk register with real system names in it. An analysis that is still being argued about. The working memory of an agent that has read your codebase for a month. Client material under NDA. If you have run anything in a regulated field, you know the shape: it wants history, branches, diffs and a link you can send to one person, and it is the reason people say "we can't put that in GitHub". So it ends up in a shared drive, or in a thread nobody can diff. A founder meets this on the first day, because the first customer's data is exactly this kind of file. The first edition had a whole part on security, and it was mostly bullets. This chapter is one of the ones I would have written.

Git for things you cannot put on GitHub

sgit is git for those files. Everything is encrypted before it leaves your machine, versioned like git, and stored on a server that holds ciphertext and nothing else: not your filenames, not your directory structure, not your commit messages. There is no key escrow, no admin override and no support engineer who can recover it for you, and that last part is a feature with a real cost, which I would rather say up front than have you find out.

Zero knowledge is a claim people make loosely, so here is what it looks like from the machine's side. One object in a published vault is 786 bytes of AES-256-GCM ciphertext, named by the SHA-256 of the encrypted bytes. Because the name is a hash of the ciphertext, the host can deduplicate it, cache it for a year and serve it from a CDN while remaining unable to tell you what it is. Underneath is a real version control system rather than a sync folder: multi-parent commits, a tree per directory, a merge-base computation and three-way merge, all working on content the server cannot interpret. Before I wrote the article this comes from, in August 2026, I cloned all nineteen published vaults from their published keys: 1,389 files, no failures. Status, plainly: sgit is beta and says so on every page; it is a pip install, pure Python, Apache-2.0. In 2018, in Backup your life, I wrote that the fewer secrets you have the easier it is to back up the rest, and that I pushed as much as I could to GitHub and trusted its backups over mine. The 2026 version of the same habit is to back up into a vault whose key you hold.

One string, and the key you can publish

What makes it work is a single string: a passphrase and a vault id. That is the vault key, and it is three things at once: the address of the vault, the authorisation to write to it, and the key that decrypts it. Lose it and the data is gone. Leak it and someone can rewrite your history.

From it you can derive, one way, a read key: same vault, read-only, safe to publish. That asymmetry is the whole sharing model. The read key is the entire credential, with no account, no login and no access request, and every vault linked from sgit.ai is published as one. No vault key has ever been published, a rule enforced by a tripwire in the release pipeline that scans every file before either remote is touched. The site this book is made on runs on the same rule: the public read key is the only key that belongs in its repository, and the build refuses the private prefix. In the browser the key sits after the # in the address, which browsers do not send to the server. Beside the vault key sit credentials made for one job each: a write key the server checks as a hash, an append token that writes one message to one lane and nothing else, and a key pair for sealing something that only its holder can open.

The part that surprises people is that a vault can contain an application, not only documents, and the application runs against the vault without ever being handed a credential. Its manifest declares permissions of nothing; the host reads the vault and passes results in; the app never sees a key. Capability without credential: you can run code you did not write against data you care about, with the blast radius set by a config file you can read in one screen. The same shape holds for a model. On a static site a chat box has nowhere to keep an API key, so the plan on sgit.ai is a bridge: the key lives below the permission floor, the host makes the call, and the app never sees it. The qualification travels with the claim, in the bridge's own words: it "protects your key; it is not yet a boundary that prevents all egress". It protects the credential you trusted it with. It does not yet stop a malicious app calling a provider with a credential of its own. Controlling your agent: RiskMandate is where that gap gets written down.

Protect the keys, not the data

The security benefit of all this is the one everyone expects, and it is real. When the server can read what it stores, all of it has to be protected: every copy, backup, log and replica, and every person and process with access. When the server holds ciphertext named by the hash of that ciphertext, the problem moves to protecting the keys, which is a much smaller problem.

The sovereignty benefit is less obvious. The line stops being where the data is stored and becomes who holds the keys. So the data can sit with a provider, or in a country, that has sovereignty gaps, and you remain sovereign over it and able to move it. The European Data Protection Board takes exactly this case, storage that does not need the data in the clear, and concludes that with strong encryption and keys "retained solely under the control of the data exporter", "the EDPB considers that the encryption performed provides an effective supplementary measure." For a founder selling into Europe that paragraph is worth more than a data centre.

The cost is that everything that matters is now in the key, so key management is where the effort goes. I use two homes. A password manager, for the keys I hold as a person; that is, and will stay, my preferred answer, even though the integration I want does not exist yet and today it is a careful paste into an entry of the right kind. And a registry, for everything the agents create: a private vault, run by its own isolated session with no other access, the vault of vaults, so a key is never lost and never has to live in a browser tab or a chat. Remembering keys under aliases on one machine is a convenience, not a management system. Once agents create vaults several times a day, as mine do, nothing less than a system works.

The weakest step is giving a key to another agent, because the agent platforms have no secrets per session. On the platform I use most, the documentation is direct: an environment variable is one that "any command Claude runs can read", and "Anyone who uses the environment can read the values". A network secret keeps a key outside the machine, but it cannot help with a vault key, because decryption happens inside the session. So today a key for another agent travels in the prompt, which puts it in a transcript; in an environment variable, which every session can read; or not at all, with the agent making its own vault and sending the key back, which is the pattern I use most. The next chapter has the handover.

Write-only lanes

The piece that makes "not at all" work, and that lets a site with no server take input, is the append lane. A lane is a write-only channel attached to a vault. A sender holds a token for one lane and the owner's public key, seals its message to that key, and sends it with a single POST. The owner decrypts with a private key that never leaves them. The server keeps only hashes and ciphertext, so compromising it yields hashes and ciphertext. One lane per sender, so one can be revoked without touching the others.

That shape turns out to be useful for far more than messages. I use lanes for key handover; for logs and observations from sessions that hold no vault key; for what a reader fills in on a web page, which is how the newsroom's sign-ups reach us from a site with no server; and for messages between agents on different platforms with different owners, where neither of us holds the other's key. It is a little like email. And the token is still a secret: it cannot read, but with the vault id it authorises writes, so I hand one out per sender and never publish it. For honesty's sake: the lane is the one part of the vault server that needs a small piece of server logic. Everything else would work over read-only files in a bucket.

Two corrections

Two things in this chapter I got wrong first, and the book should not repeat them.

The first is the order I told it in. When we describe sgit we start with the encryption, and I did too. But I do not think anyone will buy sgit because it is encrypted. Encryption is an important property, not a reason to choose a tool. If sgit succeeds, it will be because it has better features and better workflows, and what took me a while to see is where those came from: the constraint. Innovation needs constraints and the loop of trying, failing and shipping, and the encryption was the constraint that shaped sgit most. The usual reason for a server is to serve a client just the files it needs; sgit could not do that on the server, so it does it in version control, and a partial clone carries every folder you did not ask for by its id. With immutable encrypted objects, a read is a plain GET, so any static host can serve a vault. Each is a better engineering decision than the server-side one would have been. The research is more careful than the slogan: a review found "an inverted U-shaped effect of constraints on creativity and innovation", which is to say some constraint helps and too much hurts. The same applies to what you build for your customers. Take things away until it hurts, and stop there, because past that point it gets worse. The best product is not the one you use because you have to; it is the one that hurts when you stop. I have a stake here, sgit is mine, and the market will decide.

The second correction is about the law. My memo said that with the data encrypted you do not have to worry about GDPR. That is too strong. For whoever holds the keys, encrypted personal data is still personal data; the UK regulator says not to "think the encrypted data is not subject to the UK GDPR", and storing it is still processing. The controller's duties stay. What encryption does is reduce the exposure, and the law recognises it: Article 32 lists encryption as a security measure, and under Article 34(3)(a) a breach need not be communicated to the people affected if the data was made "unintelligible to any person who is not authorised to access it, such as encryption", provided the key was not lost with it. The Court of Justice held in September 2025 that pseudonymised data is not personal data "in all cases and for every person", which may help a store that never has the keys, though that store still processes data on someone's behalf, under a contract. None of this is legal advice. The 2018 outline on GDPR had one line, "Know your rights", and never got further; the line I would add now is that client-side encryption gives a founder much less to worry about, not nothing.