A security assumption that everyone has accepted without thinking about it
Modern software runs on an outdated assumption — that everything loaded into a process should fully trust everything else. For forty years, executables and libraries have shared one giant memory space with no enforceable internal boundaries. The concept of a private variable or out-of-scope variable is a fiction — an illusion of the programming language.
It is not reality.
There is no hardware-based enforcement. A single vulnerability in a dependent library — that was loaded without verifying the digital signature — can compromise the entire process.
…and if an attacker compromises the operating system, all bets are off.
Trust Requires Boundaries
Sub-Process Isolation Delivers Them
We integrate hardware-backed enclaves directly into the toolchain — the compiler, linker, loader, and runtime environment — so that every executable, every library and every dependency runs in its own protected memory region — all inside a single process. This is sub-process isolation, implemented at an architectural level, enforced in silicon, transparent to programmers, and delivered to users.
Redefining Trust: Explicit, Measurable, Enforceable
Today, programs blindly accept whatever libraries the operating system loads into memory. They can’t verify who wrote them, whether they were tampered with, or whether they should be trusted. This blind trust and lack of a mechanism to give programs a choice is the root cause of modern supply-chain attacks, privilege escalations, and cross-library exploits.
Applied Enclaves introduces a Trust-by-Choice model. Programs can finally authenticate their dependencies, inspect their provenance, evaluate their digital signatures, and decide — at load-time — whether to accept or reject them.
Trust becomes explicit, programmable, and enforceable.
What We Do
Applied Enclaves brings confidential computing into everyday software development.
We extend the C toolchain with new compiler modes, new loader capabilities, and a new Application Binary Interface (the eABI) designed for enclave-aware execution. Developers continue writing ordinary, backward-compatible C code; our toolchain transforms their programs into verifiably trustworthy, enclave-partitioned executables.
This architecture enables:
- Hardware-enforced protection (sub-process isolation) between executables within a process
- Secure, encrypted function calls between enclaves — the “Wild west” days of arbitrary jumps into library code are over
- Compiler-supported memory models:
- Share-by-Default, Private-by-Choice — Best for backward compatibility
- Private-by-Default, Share-by-Choice — The most secure and ideal for new development
- Per-library trust decisions at runtime
- Resilience even if the OS is compromised
We don’t ask developers to rewrite their software. We change the ground they code on.
Core Innovations
- Sub-Process Isolation in Hardware
Every executable and library runs inside its own SGX-backed enclave — the first scalable, performance-viable model of internal sub-process isolation. Our technology creates enforceable trust boundaries at an ideal granularity: A software publisher’s executable. - Private-by-Default, Share-by-Choice Memory Model
Compilers know what data the programmer intends to share… they don’t need explicit declarations. But compilers are complex, so nobody has tried. Applied Enclaves brings two new compilation modes for memory protection to C. Developers can choose to:- Share-by-Default — Maximum backward compatibility. Local and global variables begin in common memory unless explicitly marked as private and stored in an enclave.
- Private-by-Default — Maximum security. Local and global variables begin in protected enclave memory and must be explicitly marked if they are intended to be shared.
Private-by-Default enforces intentional, controlled sharing between executables — and maximizes the preservation of privacy.
- The Enclave Binary Interface (eABI)
A modern ABI designed for enclave-aware execution. The eABI enforces secure calling conventions, encrypted parameter passing, structured return pathways, and explicit trust boundaries between executables and libraries. It also prevents control flow from invoking functions that the programmer never intended to — eliminating unauthorized calls such as system() unless explicitly permitted in the original source.
Our novel eABI also prevents the Operating System from inspecting data as it passes between enclaves. - Provenance-Based Execution
Programs evaluate the provenance, integrity, signature chain, and version of every dependency before running. Trust becomes a programmable decision point rather than an assumption. Libraries are no longer implicitly accepted — trust can be assessed. - Enclave Aware Compilers
Developers continue writing standard C. Our toolchain (compiler and linker) emits enclave-aware binaries, generates linkage metadata, manages protected storage regions, and integrates enclave semantics without requiring complex SGX SDK, OCALL/ECALL frameworks, or auto-generated edge code. - Notes: A Secure Inter-Enclave Messaging System
Notes are encrypted, structured messages that carry function requests, parameters, metadata, and return values between enclaves. They support fast, tamper-resistant, secure, and ultra-secure modes of operation. The toolchain interprets data passed through Notes as intentional sharing and ensures that data in transit remains confidential and integrity-protected against OS-level observation or tampering. - Trusted Computation: Resilience Against a Compromised OS
Even if the operating system, kernel, or hypervisor is compromised, attackers cannot inspect enclave memory, tamper with function dispatch, manipulate protected data, or access private thread stacks. This provides confidentiality and integrity guarantees unattainable in traditional user-mode processes. - Backward Compatibility
Existing C software can be recompiled without modification to gain immediate enclave-based protection. Additional security features — such as share-by-choice, private storage classes, and provenance checks — can be incrementally enabled using optional pragmas and toolchain directives. - Production Mode
Developers need access to powerful debugging tools that provide critical insight into processes. These same tools, however, are a goldmine for hackers. We introduce “Production Mode” that disables access to these powerful internal tools, which drives a policy-based, higher level of security for everyday computing. - Resilience to Compromise
We can’t promise that there’s no vulnerable code in your process space; however, our ABI is specifically designed to minimize lateral movement within a process, prevent library functions from being called that were never intended to be called at compile time. No more arbitrary calls to system().
Why Now?
For decades, OS and process isolation has been the primary defense against malicious code. But modern attacks don’t respect these boundaries. Supply-chain compromises, malicious libraries, dependency confusion, kernel-level rootkits, and cloud-scale privilege escalations overwhelm traditional defenses.
Three converging trends make Applied Enclaves possible — and necessary:
- Hardware-based Trusted Execution Environments (TEEs) are finally mature and are primed for mass deployment. Intel SGX, AMD SEV-SNP, and ARM CCA make enclave-based execution mainstream.
- The attack surface is expanding faster than organizations can secure it. Cross-library vulnerabilities and supply-chain attacks have become a serious and hard-to-mitigate risk.
- Enterprises and governments are demanding verifiable trust. Zero trust architectures must extend inside the process, — and not simply provide perimeter defense
The industry is ready for a reimagining of what an executable should be.
The Founder’s Story
Applied Enclaves is rooted in 40 years of real engineering experience across Intel, HP, and the NSA.
In his mid-40s, after a divorce and layoff, Mark decided to dedicate the second half of his life to helping his country navigate the nascent field of Cybersecurity. He set out on three simultaneous journeys:
- Re-enlist in the Navy Reserve as a Cryptologic Technician — to provide deckplate leadership and chart a course for Cybersecurity in National Defense
- Get a Masters degree followed by a Doctorate in Cybersecurity
- Work for the best Cybersecurity outfit on the planet: The National Security Agency
The semester after Mark finished his Masters Degree, he was preparing to write a paper to thoroughly characterize Intel’s SGX enclave technology. His research brought him to Victor Costan’s seminal paper Intel SGX Explained. After reading the paper, he was crestfallen as Victor had written just the paper Mark was planning. Mark was simultaneously elated as Victor’s paper was an outstanding body of work and much better than anything Mark could have written. After lunch, Mark was returning to his office mulling over how to make lemonade from lemons when it struck him: “What would happen if I put each executable into its own enclave?” Frozen in place, the implications racing through his mind, Mark realized this one thing could change everything.
His epiphany sparked a six-year research effort across universities, national security environments, and government labs. This work led to a prototype, multiple patents, academic publication at IEEE CSR, and a new executable architecture with the potential to reshape how trust is enforced in user-mode software.
Applied Enclaves was created to commercialize this breakthrough and deliver it to the organizations that need it most.
Who We Serve
We work with organizations who need verifiable trust inside their software:
Operating system vendors
Compiler and toolchain maintainers
Cloud service providers
Government and defense agencies
Critical infrastructure
Financial services
Security product vendors
High-assurance computing environments
Any system that depends on untrusted libraries — which is every modern system — benefits from our architecture.
Our Mission
To fundamentally strengthen global software security by rebuilding the internal trust model of executables.
We believe that:
- Execution should require validated trust, not assume it
- Libraries should earn the privilege to run
- Secrets should stay secret, even from the OS
- Developers should not need to become cryptographers or enclave developers
- Security must be enforced in hardware, not hope — not in the fictional scope of variables
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.
Get Involved
Applied Enclaves is actively partnering with OS vendors, compiler teams, and organizations deploying confidential computing.
If you’d like to collaborate, evaluate the architecture, or explore integration, we’d love to talk.
→ Contact us: [email protected]
→ Learn more about our research
→ Request a technical briefing