While the Encrypted Zone (EZ) provides robust, hardware-backed privacy enforcement, it is explicitly designed to minimize the migration burden for existing proprietary workloads. Requiring development teams to completely architect their applications for TEEs or manually manage low-level secure networking would hinder adoption. Instead, EZ achieves seamless migration capabilities through a coordinated architecture involving three distinct layers: an abstraction SDK, declarative routing manifests, and host-side platform adapters.
The EZ SDK: compile-time proxying
To facilitate rapid adoption, EZ provides a robust SDK that acts as a transparent abstraction layer for migrating existing gRPC services. Developers can transition their standard protobuf-based workloads into secure EZ isolates with minimal code modifications. Rather than requiring developers to manually manage Unix Domain Sockets (UDS) or zero-copy shared memory mappings, the EZ SDK intercepts standard RPC calls and automatically routes all traffic over the enforcer's secure IPC bridge.
For proprietary, closed-source workloads, the SDK uses custom protocol buffer plugins to generate substitute gRPC headers at compile time. By making minimal changes to the server initialization process, the workload's core business logic remains entirely untouched. We currently provide native SDKs for C++ and Rust, though an isolate can theoretically be defined in any language that supports reproducible builds.
The EZ manifest: declarative routing
The manifest acts as the definitive privacy policy for the node, using
directives like services_to_intercept to transparently reroute standard
backend calls without modifying the underlying application.
Consider a concrete example: A developer has an existing, proprietary ML
microservice. In their standard code, they simply write a naive gRPC call:
client.GetUserDetails(request). They do not need to import privacy libraries
or handle encryption keys. Instead, the infrastructure operator configures the
ez_manifest.json to intercept that specific call. The enforcer seamlessly
intercepts the GetUserDetails request and reroutes it through a
trusted_ingress_validator (an open-source ratified isolate) to strip PII
before it ever reaches the proprietary ML model.
Because this routing is defined declaratively in the manifest and enforced entirely by the enforcer, the opaque isolate remains blissfully unaware of the interception. Developers write code exactly as they always have, while the manifest enforces verifiable, cryptographic privacy.
Platform adaptation: proxy service and launcher
To integrate securely with the outside world, EZ relies on a host-side platform adapter (proxy service) and a launcher. These components sit outside the strict trust boundary of the TEE and act as the bridge between the highly restricted namespaces of the enclave and the host environment's standard networking.
The platform adapter handles standard cluster orchestration, external load balancing, and the ingress of encrypted client traffic, routing it securely to the EZ enforcer. By decoupling the cloud infrastructure's networking layer from the enclave's secure execution environment, the opaque workload never needs to be refactored to handle specialized TEE networking topologies.
While the EZ SDK ensures developers can easily migrate their workloads into the enclave, operating those workloads in production requires robust visibility. However, traditional monitoring introduces severe exfiltration risks.