# Project Oak for Attested Enclave Applications

> Project Oak is a Rust-based platform for distributed systems that need evidence about the software and hardware identity of enclave applications. Its split architecture combines VM-based trusted execution, encrypted communication, remote attestation, and transparent release claims, with restrictions that are not suitable for every workload.

**project-oak/oak** — Meaningful control of data in distributed systems.

- Repository: https://github.com/project-oak/oak
- Stars: 1,515 · Forks: 150
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/project-oak-oak

## The split architecture keeps plaintext inside the enclave

Oak encourages a split architecture to reduce both the attack surface and the Trusted Computing Base. The Enclave Application is built reproducibly from open source code and runs inside the TEE. It receives encrypted requests, decrypts them, processes the data, encrypts responses, and sends them back through the communication channel. The README states that no other binary has access to incoming requests in plaintext.

The Host Application runs in the untrusted host environment and exposes a gRPC endpoint. Its documented responsibilities are creating and maintaining the enclave application instance and forwarding encrypted data in both directions. It may also contain proprietary logic for control-plane interaction or other service-provider systems. That logic is outside the enclave and should not be treated as part of the remotely attested application identity.

The split creates a clear trust boundary, but it is also a deployment constraint. The host remains responsible for transport, process management, and interaction with surrounding infrastructure, while the enclave owns the protected computation. A failure to preserve that boundary can change the security properties. Oak also says that replacing the enclave binary should be detectable, and that a backdoor would need to be signed and published through the Transparent Release process. The repository layout includes `enclave_apps/`, `demo/`, `codelab/`, and documentation assets, but the README does not provide a complete user installation guide.

The distinction between the two binaries matters when reviewing claims about Oak. A service operator can control the host process, but the enclave binary is the component associated with externally verifiable behavior. This is the reason Oak calls for reproducible builds and transparent release: observers need a way to connect the running enclave with the published identity rather than trusting a host-side assertion.

## Restricted Kernel and Oak Containers define the execution envelope

Oak supports two operating-system flavors inside the TEE. Oak Restricted Kernel is a small custom microkernel that supports one CPU and one application. It exposes a limited set of syscalls, placing severe restrictions on what an enclave application can do. The README positions this option for cases where review of the entire trusted code inside the TEE is important and where reduced features and performance are acceptable.

Oak Containers takes a different route. The README describes the enclave application as part of an OCI runtime bundle that includes a full Linux kernel and a Linux distribution. The README excerpt ends while describing that distribution, so the exact packaging details, supported distributions, and runtime interfaces cannot be confirmed from the README. Still, the architectural difference is clear. Oak Containers is intended to offer a larger operating-system environment than the restricted microkernel, while Oak Restricted Kernel prioritizes a smaller trusted code base.

That choice is a direct trade-off. The Restricted Kernel can make review more manageable, but applications must tolerate its limited feature set and performance profile. Containers may fit applications that need familiar Linux components, but the larger trusted code base is the security cost that Oak explicitly seeks to minimize. Oak does not claim that one flavor removes the need to review the application, configuration, dependencies, or host-side integration.

The repository also includes Bazel files, Rust configuration files, CI-related files, and `justfile` recipes. The `justfile` defines a default command that lists available recipes through `just --list`. This is repository tooling, not an end-user installation procedure.

The kernel choice also changes how teams should think about application boundaries. A one-application kernel makes accidental cross-application interaction less relevant, but it can force a monolithic application design. A full Linux environment may simplify packaging, yet every component inside that environment contributes to what must be reviewed and trusted. Oak does not document a universal recommendation in the README. The correct choice depends on which side of this trade-off dominates the application requirements.

## First use starts with the repository, not a packaged installer

The README does not document installation steps, a stable command-line installer, a downloadable SDK, or a supported package name. It does not provide a first-run command for an Oak application. Accordingly, there is no installation command to reproduce without inventing project details. The repository is the source of the implementation and documentation, including `README.md`, `docs/`, `enclave_apps/`, `demo/`, and `codelab/`.

The repository contains a `justfile` whose default recipe lists locally available recipes. The file describes `just` as a tool similar to a Makefile with a different syntax. A developer working from a checkout can use the repository's documented workflow entry point to inspect what recipes are available. This does not establish that the environment is ready to run an enclave application. The project also uses Bazel, Nix-related files, Rust configuration, and a Docker-based CI environment.

The Dockerfile describes an image used to run CI. It installs Debian packages including `ca-certificates`, `curl`, `git`, `xz-utils`, `unzip`, and `nix`, then enables experimental Nix features and installs Cachix. Its purpose is development and CI infrastructure, not a documented production deployment path. The pinned base image digest shows an attempt to make that environment deterministic.

For a first real use, the repository layout points contributors toward the `codelab/` and `demo/` directories. However, the README does not state which hardware platform, TEE configuration, build target, or runtime settings a reader should select. Those prerequisites must come from the full project documentation or a specific codelab before attempting an attested channel.

A practical first step is therefore to read the repository's codelab and deployment documentation, then confirm the required TEE hardware before building. The available repository files show how the project is developed, but they do not by themselves prove that a particular host can execute Oak.

## Oak Containers are the closer fit when Linux features are required

A real alternative approach is to use Oak Containers rather than Oak Restricted Kernel when an application needs a fuller Linux environment. Both approaches remain tied to enclave execution and Oak's evidence model, but they differ in the execution envelope. Restricted Kernel limits the application to one CPU, one application, and a very small syscall surface. Oak Containers includes a full Linux kernel and a Linux distribution in the OCI runtime bundle.

Another architectural alternative is to rely on a conventional encrypted channel without remote attestation. Such a design can protect data in transit, but it does not by itself give a remote party evidence that protected keys belong to a particular enclave binary and hardware identity. Oak's added component is therefore not merely encryption. It is the connection among protected keys, evidence, software measurements, and policy decisions made during channel establishment.

The choice is not free. Oak adds hardware dependencies, application packaging work, key handling, evidence validation, and a split between host and enclave code. It is a poor fit for a small internal service that only needs TLS or application-layer authorization, because the additional model may add deployment complexity without satisfying a real evidence requirement. The README does not provide a benchmark, a compatibility matrix, or a complete hardware requirements section, so those claims cannot be inferred.

The alternative should therefore be selected based on the property that matters most. If confidentiality and integrity on a channel are sufficient, conventional encryption may be simpler. If an outside node must verify which protected software identity performed a computation, Oak's attested model addresses a different requirement. The project is not a general-purpose replacement for every transport-security library.

## Maintenance and Apache-2.0 scope the adoption decision

The repository is not archived, and the last push was on 2026-10-15. That indicates recent repository activity for maintenance purposes, but the repository has no GitHub releases. There is therefore no documented release cadence or packaged upgrade path in the README. Changes may occur in the default branch and across the build system without a release note from which to infer compatibility guarantees.

The repository is licensed under `Apache-2.0`. The license file and repository metadata identify the licensing, but this review does not provide legal advice. Users should review the license and dependency notices for their own distribution model, especially because Oak combines Rust code, build infrastructure, documentation, examples, and container-related artifacts.

Upgrade cost is visible in the repository's workflow surface. The `justfile` has `presubmit` and `presubmit-full` recipes that invoke formatting, standard and bare-metal checks, WebAssembly checks, codelab tests, `cargo-audit`, private-memory checks, and `kokoro_verify_buildconfigs`. The exact commands are partly truncated, so this article does not reconstruct the full sequence. The existence of these checks indicates that changes can involve more than an application source edit. Hardware support, Rust toolchains, Bazel configuration, build outputs, and TEE-specific targets all need verification before an upgrade can be treated as routine.

The absence of GitHub releases means adopters should not assume that every `main` change has a stable version boundary. Recent repository activity is a maintenance fact, not a compatibility guarantee. Teams that need pinned releases should identify their own supported commit or build procedure before depending on Oak for production.

## Oak's security claims depend on deployment evidence

Oak is most compelling when a system must make a claim that an independent party can check: that a particular enclave application, running with particular measurements and configuration, processed data under keys unavailable to the host. The split architecture and attested encrypted channel provide a concrete basis for that claim. The README is especially clear that the Host Application handles encrypted data while the Enclave Application handles decryption and protected computation.

The central limitation is that this model is narrower than ordinary application security. It assumes that hardware-backed TEE roots, evidence verification, protected keys, reproducible application identity, and deployment transparency are available and correctly configured. The README does not document a complete policy language for deciding which measurements or evidence values to accept. It also does not describe how to recover from compromised evidence storage, host failure, unsupported hardware, or an application update. Those cases require project-specific decisions outside the README.

Oak Restricted Kernel further narrows what can run inside the TEE, while Oak Containers expands the operating-system surface. The former favors reviewability at the cost of features and performance. The latter may accommodate Linux-oriented applications, but requires a larger trusted code base. The repository's `falsify/`, `artifacts/`, and build configuration entries suggest support for evidence-related work and validation, but the README does not specify their operational procedures.

Another limitation is release transparency. Oak says a backdoor would need to be signed and published in a verifiable log through the Transparent Release process. That claim depends on external observers reviewing that log and on the deployment actually using the intended enclave binary. The project does not say that publishing an identity proves the implementation is safe. Verification establishes an identity and visibility claim, not correctness.

The absence of GitHub releases means adopters should not assume that every `main` change has a stable version boundary. The repository's current activity is a maintenance fact, not a compatibility guarantee.

## Conclusion

Adopt Oak when the system needs reproducible claims about enclave software identity and encrypted communication across heterogeneous nodes. Do not choose it for ordinary services that do not need attested execution, or for workloads that require unrestricted operating-system features without accepting a larger trusted computing base. Verify first whether the target hardware, application packaging, key handling, and transparent-release process match the deployment model documented by the project.

## FAQ

### What problem does Project Oak solve?

Project Oak is a software platform for building distributed systems whose Enclave Applications can provide remotely verifiable evidence about their software and hardware identity. It is aimed at applications that need isolated computation and encrypted, attested communication.

### What hardware roots of trust does Project Oak support?

The README identifies AMD SEV-SNP and Intel TDX as examples of VM-based TEEs used as hardware roots of trust. It states that enclave applications can produce attestation reports signed by keys ultimately rooted in the TEE manufacturer.

### Does the README provide installation steps for Project Oak?

No. The README does not document an end-user installer, package name, or first-run deployment command. The repository contains build and developer tooling, including Bazel files and a `justfile`, but those files do not replace a documented installation guide.

### What is the difference between Oak Restricted Kernel and Oak Containers?

Oak Restricted Kernel supports one CPU and one application with a limited syscall surface, while Oak Containers includes a full Linux kernel and a Linux distribution in an OCI runtime bundle. The trade-off is a smaller reviewable trusted code base versus a broader Linux environment.

### How does Oak protect data between nodes?

Oak describes an end-to-end encrypted channel in which nodes exchange evidence when available and may use it to decide whether to exchange data. The channel provides confidentiality, integrity, and authenticity for messages processed by an attested node.

## Sources

- [Issues](https://github.com/project-oak/oak/issues)
- [License: Apache-2.0](https://github.com/project-oak/oak/blob/main/LICENSE)
- [project-oak/oak on GitHub](https://github.com/project-oak/oak)
- [README](https://github.com/project-oak/oak/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/project-oak-oak