By Luffy Bao, CTO at Ankayma · 27 June 2026 · ← All writing
When a provider tells you "our infrastructure is technically unable to read your data," a good security engineer doesn't relax. The right next question is: then what is the code I'm running, and who decides what it does the moment I use my key?
That is the right question, and it's the one I want to answer here. In a previous post I argued that holding your own key — the provider being technically unable to decrypt — is a stronger guarantee than keeping data in-country. I stand by that. But holding the only key closes exactly one door: the provider silently decrypting your data at rest. It leaves a second door standing, and most "zero-knowledge" pitches walk you straight past it without pointing.
Trust in a provider has two surfaces, not one. The first is can they read my data. That's the one everyone argues about, and capability-bound sovereignty answers it: no, not without the key, and the key is yours. The second surface is can they change the code that touches my key. Your key only protects you while the software using it behaves. If I can ship you a client update — signed, legitimate, auto-installed — that copies the key out the moment you decrypt, then the cryptography was never the weak point. The weak point was who controls the next release.
What hold-your-own-key actually guarantees — and what it doesn't. It guarantees that data sitting on my infrastructure is opaque to me. It does not guarantee that the software running on your side is the software you reviewed. Those are different promises, and the gap between them is where a serious adversary — or a serious legal order — goes. The honest framing: capability-bound sovereignty moves the trust from "the data at rest" to "the integrity of the client and the keys used to sign its updates." It moves; it does not vanish. Anyone who sells you the first guarantee while staying silent on the second is selling you half a system.
The attack, said plainly. By default, any end-to-end system that also distributes its own client software exposes one path: the provider is compelled to push a targeted update signed with its own legitimate update-signing key — a build that looks identical to everyone else's, but for one target exfiltrates the key or the plaintext at the moment of use, and the order can arrive with a gag attached, so the victim is never told. This is not exotic; it is the standard, well-understood limit. The problem isn't the cryptography — it's who controls the next release, and whether they can do it silently. If the conversation about sovereignty stops at "we can't decrypt your data at rest," it has stopped one step too early.
Where this lives, in our case — concretely. At ankayma, the client — the mobile app and the UI — is public source; the control plane is not. That puts the attack surface in exactly one place: the signed build of the client, not the control plane. The control plane only ever sees encrypted data, so compelling or breaching it reaches no key and no plaintext; the key lives on the client side, so the only path to it is a client update carrying malicious code. Public client source is necessary for you to inspect — but not sufficient, because what runs on your device is the build, not the source. The question that decides everything: is that build actually compiled from the public source you can read? To be straight about where we are today: the client source is public; the part that lets you verify a build matches the source — reproducible builds and a transparency log — we are still building, not yet fully running. I'd rather say so than let you assume it's already there.
What actually constrains it — don't skip this. The defense is not a cleverer cipher. It is making code verifiable by someone other than the provider, so a malicious build can't be both signed and silent. Each mechanism below helps, and each has a real cost — if a provider names the mechanism but hides the cost, be skeptical.
And let me be precise, so this doesn't read as confessing a hole: this architecture closes the silent, unilateral path — once those mechanisms are in place, no provider, me included, can push a malicious build and hide it. What it does not remove is coercion; none of this makes you immune to legal process. But coercion now has to pass through a public log or several independent custodians, so it becomes visible and multi-party instead of invisible and one-sided. Put plainly: pushing malicious code silently — the architecture removes it; being coerced — the architecture can't prevent it, but it can't hide it either. Crucially, the entity who can confirm a build is honest is no longer the provider — it's the transparency log and whoever independently verifies it. That is also why this only works if someone outside the provider is actually watching.
Let me state my bias. I build toward verifiable client integrity, so discount my framing accordingly — you should. But my claim here is narrow: don't accept "we can't read your data" as the end of the security conversation. It's the middle. The end is "and here is how you, or a third party, can check that the code using your key is the code you approved." If a provider can't answer the second question, the first answer is doing less than it sounds like.
So what should you actually ask? Read past the cryptography slide to the release process. One diagnostic question separates the providers who have thought about this from the ones who haven't: when you push an update, can I independently verify the running binary matches your published source — or am I just trusting your signature? If the honest answer is "trust the signature," then whoever controls signing controls everything the key was supposed to protect.
I write about this because it's the harder half of the problem I'm building at ankayma — the half that doesn't fit on a sovereignty slide. If you're evaluating a zero-knowledge or hold-your-own-key provider for a regulated workload, ask them the release-process question, and tell me what they say. I'd like to hear it — especially if it pokes a hole in mine.
Luffy Bao is CTO at Ankayma, building zero-trust mesh infrastructure for regulated organizations in Southeast Asia and the Gulf. Questions or counterarguments? hello@ankayma.com