Are you looking for a new adventure
We’re looking for a co-founder
Join us!
Reimagining the Process Space
For 50 years, we blindly trusted every executable in the process space…
Applied Enclaves introduces a new architecture where executables, libraries, and data operate inside hardware-enforced secure boundaries.
We call it sub-process isolation.
Hi, I’m Mark Nelson
I’m the founder of Applied Enclaves. After a career at HP, I’m dedicating the next chapter of my life to strengthening cybersecurity and developing the next generation of security professionals. I began that journey by joining the Navy Reserve as a Cryptologic Technician, pursuing a Ph.D. in Computer Science at the University of Hawaiʻi at Mānoa, and entering the federal cybersecurity workforce.
While working on my doctoral research, I had an epiphany: What would happen if each executable in a process ran in its own enclave? It is the simplest idea, but the implications are enormous. That insight became the inspiration for Applied Enclaves.
Stop Letting Strangers Into Your Home
Today’s executables run in one giant shared space — like living in a house with no interior doors. One library vulnerability exposes everything. Applied Enclaves restructures user-mode processes so each executable and library loads into its own SGX-backed enclave, creating real, enforceable boundaries inside a process. Programs finally get “rooms,” “safes,” and real privacy.
Enclaves = Executables
Sub-process Isolation That Makes Sense
Unlike virtualization, containerization or library-OSs, Applied Enclaves uses TEEs (Trusted Execution Environments) at the executable boundary — the natural granularity of published software and the trust that goes with that. The result: Dramatic reductions in attack surface without the overhead of VMs or containerization. We believe this is the generally correct granularity for trust.
Stop relying on the oS — Move trust into silicon
Hardware Enforced Supply Chain Integrity
Executable authenticity is enforced at load-time using a hardware-rooted digital signature model. We extend SGX’s code-signing with a certificate hierarchy (similar to HTTPS) so no unsigned or tampered executable is ever allowed into a process.
Protection from above
Even the OS doesn’t Get To Peek
In traditional systems, the OS, hypervisors and cloud providers see everything — including your secrets. Data inside the enclave is only visible to threads running inside the enclave. The OS can schedule execution, but it can’t read or tamper with protected memory.
Inspired By biology
Surviving a Compromised OS
If malware owns your OS, your secrets are gone — today. Our model isolates enclave data from the OS entirely. Even with root access, attackers can’t read enclave memory, can’t probe the stack, and can’t hijack calls between library modules.
One of our core research questions is: If we can’t eliminate malware, can we find ways to safely coexist? The model is biological: Humans live with dangerous pathogens because infections are isolated. A single cell may die, but it doesn’t kill the organism. Our enclave model applies this same principle to software.
We’ve Been Doing It All Wrong
Let’s Fix It
Encrypted Parameters Secure Dispatch
We invented “notes”: An encrypted, tamper-resistant message exchange system that enclaves use to call functions, pass arguments, return values, and metadata. Notes utilize one of several levels of encryption… A note’s level of encryption depends on what users or system administrators set based on policy, response requirements or security requirements: fast-mode, secure-mode, or ultra-secure function calls with re-authentication per invocation.
Break the Supply Chain Attack Cycle
Programs today blindly accept whatever libraries the loader gives them. Our Provenance-Based Execution Model lets executables evaluate the authorship, signature chain, version, and integrity of each dependency before running. Your software can finally say: “I don’t trust that — find another.”
Practical Defense Against Code Injection & ROP
Enclaves have a controlled entry point and the code sections are measured, verified, and then isolated. Libraries can’t introspect each other’s .text sections and can’t arbitrarily jump into another library’s text sections. Attackers lose access to entire classes of ROP chains and arbitrary write primitives.
Fine-Grained, Cryptographically Enforced Least Privilege
Today’s “least privilege” ends at process boundaries. We introduce meaningful boundaries within the process: per-executable TEEs, scoped private variables, per-function calling modes, and key-derived call channels. Every library gets only what it needs — and nothing more.
Current Status
- Pre-seed – Now’s the perfect time to get in early
- Technology Readiness Levels (TRLs) 3 – Validated in the lab
- We have a working proof-of-concept
- We have an LLC ready for diligence
- We are actively working on building an enclave-aware toolchain (compiler, linker, loader and runtime)
How Does This Work?
A New Kind of ABI: The Enclave Binary Interface (eABI)
Our eABI redesigns how functions call across libraries. It adds integrity metadata, encrypted parameters, dispatcher routing, and explicit calling policies chosen at compile-time. The C toolchain finally understands enclaves.
Keep your code — Update the architecture
Your existing C programmers don’t need to become SGX gurus. Our compiler, loader, and runtime transparently generate enclave-aware executables, preserving familiar language semantics while offering enclave-grade security. Recompile, don’t rewrite.
Safe Multithreading & Private Stacks & Private Heaps
We introduce private local/global storage classes, private stacks inside enclaves, private globals and private heaps. There’s no magic, however, private heaps will require using a private, enclave-aware malloc.
What about System Calls
Good question! System calls can’t execute inside of enclaves. Applied Enclaves routes system calls through pseudo-enclaves or kernel-enclaves that utilize the same eABI as enclaves. Pseudo-enclaves are in normal userspace and represent a minimal attackable feature. Kernel-enclaves are enclaves running in the Kernel that allow usermode-based enclaves to securely share data with the kernel, in support of a system call.
Zero-Knowledge Library Calls: Call a function without revealing what function you’re calling
Notes hide the target function from the non-enclave dispatcher, preventing OS-level snooping of your execution flow. This provides a meaningful step toward confidential computing inside a single process.
Shift from Share-by-Default to Share-by-Choice
Would you hand your wallet to a complete stranger and then go for a swim? That’s what your computer programs are doing today. It’s no wonder cybersecurity is in the state it’s in.
Your program’s secrets shouldn’t be accessible to every shared library. Applied Enclaves introduces a compiler-supported memory models where private and shared data are explicit choices, not accidents. Variables stored in enclave memory remain invisible to everything else.
Looking for the Next Big Thing
You’re looking at it