The challenge
A major cloud storage provider on Azure offered server-side extensibility — customers could deploy custom code that ran alongside their stored data, enabling transformations, indexing, and workflow automation without round-tripping data to client infrastructure. The problem was trust: every piece of customer code required manual security review before deployment, because it ran in the same trust boundary as the platform.
This review process took weeks, consumed expensive security engineering time, and scaled poorly as the customer base grew. Enterprise customers who needed custom server-side logic faced unpredictable deployment timelines. The platform team faced a growing backlog of review requests that diverted engineers from product work.
The underlying tension was clear: the platform needed to run untrusted code safely, without the cost and delay of treating every deployment as a security event.
Our approach
We designed an SDK architecture that sandboxes customer code inside Azure Confidential Computing enclaves, making manual review unnecessary by ensuring that custom logic cannot access anything beyond its explicit API contract — even if the code is malicious.
Enclave isolation model
Each customer workload runs inside a hardware-backed trusted execution environment using Azure's confidential computing infrastructure. The enclave boundary enforces that customer code can only interact with the platform through a narrow, well-defined SDK interface. It cannot read other customers' data, access platform internals, or exfiltrate information through side channels. The hardware attestation chain verifies enclave integrity before any workload runs.
This moves the security model from "review the code, then trust it" to "trust the boundary, regardless of the code." The platform no longer needs to understand what customer code does — only that it runs within enforced constraints.
Developer-facing SDK
The SDK presents a straightforward API surface designed for enterprise developers without cryptography expertise. Developers write ordinary application logic against storage, transformation, and event APIs. The SDK handles enclave lifecycle, key management, and attestation transparently. From the developer's perspective, they are writing a standard server-side plugin; the enclave mechanics are invisible.
Key management architecture
Encryption keys for customer data never leave the enclave boundary. The platform stores only encrypted data and encrypted keys — it cannot access plaintext under any circumstances. Key provisioning uses remote attestation to verify that keys are only released to genuine enclaves running approved SDK versions. This gives customers a zero-knowledge guarantee: even the storage provider cannot read their data.
Results
Customer deployments that previously required weeks of manual security review now deploy in minutes through automated enclave provisioning. The security team was freed from the review backlog, redirecting engineering effort to platform capabilities rather than gatekeeping.
Operational costs for managing server-side extensibility dropped significantly. The manual review process had required dedicated security engineers per deployment cycle; the enclave model replaced this with automated attestation that scales with the platform.
The zero-knowledge architecture opened the platform to regulated industries — healthcare and financial services customers who could not previously use server-side extensibility due to data handling requirements. The enclave guarantee satisfied compliance teams that had previously blocked adoption.