Artifacts: Entry 046 noted the user’s low-probability corner that a LEO desktop, being outside any single country’s jurisdiction, might host data that customers want “above cloud.” Entry 050 added that a storage-centric pod topology would be the natural hardware shape for such a service. This wandering asks what security and access-control model would be required.

The settled assumption

The pod is a single-owner system. The operator controls all cells, all storage, and all workloads. Security, if any, is about protecting the pod from external tampering, not about isolating users from each other.

The low-probability corners

Corner 1: encrypted storage at rest, operator cannot read

The simplest multi-tenant model is that customer data is encrypted on the customer side before it reaches the pod. The operator provides storage and compute cycles; the keys never leave the customer’s ground systems. This is the model used by terrestrial cloud storage with client-side encryption.

The attraction is that the operator avoids most legal and liability questions: they cannot decrypt, so they cannot be compelled to produce plaintext. The weakness is that the customer must manage keys, and a lost key means lost data. For an orbital service with intermittent ground contact, key recovery and backup become harder.

Corner 2: encrypted storage with orbital key management

What if the pod itself runs a key-management service? Customer data is encrypted, but keys are stored in a hardware security module (HSM) or trusted execution environment on orbit. The customer can rotate keys, revoke access, and audit usage through the same ground link used for spacecraft operations.

This is more convenient but introduces a high-value target. If an attacker compromises the orbital HSM, they gain access to all customer data. The pod’s radiation and physical security environment is also harsher than a terrestrial data center, which makes HSM reliability a real concern.

Corner 3: jurisdictional arbitrage as a feature

The user’s original corner: the pod is not in any single country, so it may appeal to customers who want data outside terrestrial legal reach. This is the “data haven” model. It could attract whistleblowers, activists, cryptocurrency projects, or simply businesses seeking regulatory neutrality.

I do not know whether this market exists at the price point of an orbital desktop. The technical obstacles — launch cost, radiation, intermittent connectivity, limited bandwidth — are enormous compared to a terrestrial data center. The legal obstacles are also enormous: the operator’s ground segment, corporate domicile, and customer contracts are all still subject to terrestrial law. Orbit does not make regulation disappear; it only displaces it.

Corner 4: workload isolation rather than data hosting

A less fraught multi-tenant model is to host workloads, not data. Customers upload container images or jobs; the pod runs them and returns results. Customer data passes through, but persistent storage remains on the ground. This avoids the long-term custody problem but also avoids the “above cloud” selling point.

Workload isolation requires the same primitives as data hosting — strong identity, encrypted communication, resource quotas — but the blast radius of a breach is smaller because the pod does not hold long-lived customer datasets.

New dimensions of the solution space

  • Identity and attestation. Any multi-tenant model needs a way for customers to verify that they are talking to the real pod and not a ground-based impersonator. This is harder in space because the ground link is indirect and the pod may be out of contact.
  • Audit and non-repudiation. Customers will want logs showing who accessed their data and when. In orbit, logs themselves are data that must be stored, protected, and downlinked.
  • Key recovery under fault. If a cell with an HSM fails, can the pod reconstruct the security state? This is the orbital version of disaster recovery for a key vault.

What I internalized

Multi-tenancy on orbit is technically possible but economically and legally uncertain. The simplest defensible model is client-side encryption with the pod providing only storage and compute cycles. Anything more sophisticated — orbital HSMs, key management, jurisdictional marketing — is a product for a later phase, after the pod has proven it can keep its own bits alive.

The security model is also constrained by the weak-federation architecture. Distributed storage across cells complicates encryption because data may be encoded across multiple nodes. A storage-centric topology simplifies some things but creates a single high-value target.

Recalled

  • Cryptonomicon (Neal Stephenson, 1999). The novel weaves together World War II codebreaking and a modern attempt to build a data haven in Southeast Asia, with cryptography as the central tool for keeping secrets across jurisdictions. Where the novel is wrong for my case is the terrestrial setting; orbit is a much more expensive and hostile place to host bits. But the underlying puzzle is the same: how do you keep data controlled by the owner when the physical infrastructure is somewhere else and shared with others?

What this changes

  • Nothing changes for the first pod. It is a single-owner system and has no multi-tenant requirement.
  • A “client-side encryption by default” rule is added to the long-term data-hosting checklist. It is the simplest security model that preserves operator distance from customer data.
  • Orbital HSMs and key management are noted as future research, not requirements. They become interesting only if a customer base emerges that needs them.
  • The data-haven economic hypothesis remains unproven. It is tracked as a speculative product direction, not a technical justification for orbit.