Insider threat in cloud storage: the trust topology problem

The conversation that doesn't happen

Most enterprise insider-threat conversations focus on the customer side: privileged-access management, separation of duties, audit logging of admin actions. These are necessary controls.

The conversation that rarely happens: what does the cloud provider's own admin staff see? When AWS, Azure, or GCP runs your workload, what does their operations team have access to? What does their support staff have access to? What happens if one of them — accidentally or maliciously — looks at your data?

The hyperscaler answer is some combination of "we have strict access controls," "we have HR vetting," and "we have customer-managed encryption." All three are real; none of them eliminates the topology problem.

The topology problem

In any cloud architecture where the provider's compute plane handles decryption, the provider's admin team has, in principle, access to the unwrap operation. They are not supposed to use it. They are policy-prevented, audit-tracked, and HR-vetted from using it. They could.

For most data, the residual risk is low enough to accept. For high-sensitivity data — defence, finance, government, legal — "could" is too much. The board wants "cannot."

What CMK doesn't solve

Customer-managed keys are often presented as the answer. They do not eliminate the topology problem; they reduce its surface. The key sits in the provider's KMS. The provider's KMS admin team can — in principle, with sufficient access — observe key usage. They can, with extreme effort and audit-visibility, observe key contents. They are not supposed to. They could.

HSM-backed KMS narrows the surface further. External key stores (AWS XKS, Azure Cloud HSM) narrow it further still. None of them changes the fundamental fact that the unwrapped key materialises within the provider's compute plane at read time.

The architectural fix: zero-knowledge by construction

The only way to remove provider-side insider exposure is to ensure the provider's operational team has no path to plaintext. This requires:

• The wrap key is derived on the customer device, never reaches the provider
• The provider's server holds only ciphertext and metadata
• The decryption operation happens on the client, not on the server

An insider at the provider — accidentally or maliciously, with any level of system access — sees only ciphertext. The capability to derive plaintext does not exist in the provider's environment.

This is SkyeConnex's architecture. Read the deeper explanation →

The topological compounder

Layer Reed-Solomon dispersion on top of zero-knowledge. Now even if an insider at one storage provider — Backblaze, AWS, OVH, whatever — gained illegitimate access to that provider's stored data, they would see only 2 of 7 shards per file. Mathematically, 2 of 7 shards reveals nothing about the original. The insider sees ciphertext fractions that cannot be combined into plaintext.

For an insider to obtain plaintext, they would need to simultaneously gain illegitimate access to 5 different cloud providers — typically in 5 different jurisdictions — and also defeat the AES-256-GCM + ML-KEM-1024 hybrid wrap. The required collusion is operationally infeasible.

Split-Authority Decryption for the highest-sensitivity scopes

For data whose sensitivity warrants more than zero-knowledge + topology, SkyeConnex offers Split-Authority Decryption using Shamir Secret Sharing. The decryption secret is split among M-of-N custodians; any single custodian cannot reconstruct the key. Even the customer organisation cannot decrypt unilaterally — defending against malicious insider on the customer side too.

This is the appropriate posture for defence-grade workloads and the most sensitive legal-privilege scopes.

Audit-log non-repudiation

Insider-threat investigations after the fact depend on credible audit logs. Most cloud audit logs depend on the platform itself for verification — "trust us, this log is accurate." That is awkward when the investigation is about the platform.

SkyeConnex's audit log is dual-signed with HMAC-SHA-256 (for online verify) and ML-DSA-87 (FIPS 204 post-quantum signature). The ML-DSA-87 issuer public key is published at /security. An investigator — internal or external — can verify any log entry offline against the published key, without trusting SkyeConnex's platform. Forgery requires compromising the issuer keypair, which never leaves a hardened key-management boundary.

What to ask vendors

• If your operations team had to access my data, what would they do? What's the procedure?
• Has it ever happened? Under what conditions?
• Do you publish your issuer key for offline audit-log verification?
• What does an investigator do if they suspect your platform itself was the source of an insider incident?

For most cloud providers, the honest answer to the last question involves "trust our internal investigations." For SkyeConnex, the answer is "verify the audit log offline against our published key; if it doesn't reconcile, the issue is forensically obvious."

For a sovereign-architecture briefing focused on insider-threat resilience, book 45 minutes. We will walk through the split-authority configuration option, live.

---

Published January 29, 2026 · Written by SkyeConnex Inc. · More from the SkyeConnex blog