The Sovereign Data Plane
Customer data lives, moves, and dies inside the customer's environment, in cells that contain everything, protected by keys the customer owns.
Split your system at the account boundary. Everything that touches customer data (the orchestrator, the workloads, the volumes, the secrets, the network, the encryption keys) runs inside an account the customer owns. This is the data plane. Everything that decides what should happen (orchestration, scheduling, fleet management, metering) runs in your account. This is the control plane. The control plane holds desired state, status, and metering records; customer data, in every form it takes, belongs in the customer account.
This cut defines the trust model. Because the data plane lives in the customer's account, it is automatically subject to everything the customer already enforces: their IAM, their VPC controls, their CloudTrail audit logs, their KMS key policies, their budget alarms, their kill switch. Their compliance posture (HIPAA, PCI-DSS, GDPR data residency, sector regulation) extends over your software because your software runs where the data already lives.
Inside the account, organize the data plane as a cellular architecture, so sovereignty is enforced by structure. A deployment cell is a self-contained bundle: cluster, network, IAM roles, certificates, namespaces, and your agent, provisioned as a unit. Give every cell its own uniquely named roles, its own certificate identity, its own tunnel. Condition the federated trust of Commandment IV down to the cell: each role is assumable only by that cell's service account subject, such as system:serviceaccount:cell-a-namespace:agent. Treat any credential that spans cells as a lateral-movement path and remove it; where a shared component is unavoidable, scope its per-cell reach with verified identity. The same walls that contain compromise also contain distrust: a customer can audit, freeze, or offboard a single cell while its siblings keep running.
Mirror the partitioning inside the control plane, because the control plane is itself multi-tenant. Carry tenant identity in signed tokens and ignore any tenant identifier in the request body. Partition storage physically by tenant ID so an unscoped query is unwritable. Apply per-tenant rate limits so one tenant's traffic cannot starve another's. The cell is the unit of isolation in the data plane; the tenant partition is its mirror in the control plane.
Extend sovereignty to every derived form of the data, because backups are the most common place data-residency guarantees break. Keep continuous backup chains and their point-in-time restore points in the customer's account. Encrypt all of it with encryption keys the customer owns. The threat model for backups then collapses into the threat model for the account: one custody chain, one key owner, one place to verify.
Be strict about what crosses the boundary outward: health status, sync state, usage-metering events, and operational metrics, kept with short retention on the control-plane side. Application data, secret material, volume contents, backups, and database rows stay inside the account permanently. If your control plane is breached tomorrow, the attacker learns that a customer's database is healthy, and that is the full extent of the loss.