The problem
An application can encrypt information in storage and during transport, yet still need to expose it while performing useful work. The execution environment then becomes part of its security model. Who can inspect memory? Which code is running? What must a user trust about the operator?
TERNOA’s enclave infrastructure addresses this execution layer. Its public implementation connects Trusted Execution Environments (TEEs) with a blockchain context and peer communication. The result is a useful engineering case: protecting an operation requires attention to the machine, the software inside its boundary and the network around it.
Mickael’s contribution
As a founder and product builder at TERNOA, Mickael has worked at the intersection of decentralized infrastructure and usable security. His public work includes explaining the role of Intel SGX in decentralized key management and the path from infrastructure to applications such as digital legacy.
This is a systems perspective. The enclave is a primitive; the product must connect that primitive to identity, access rules, user actions and an operational lifecycle. The technical leadership challenge is to make those relationships coherent across the teams and components that deliver the system.
Inside the architecture
Intel Software Guard Extensions (SGX) provide application-level enclaves: hardware-backed boundaries for selected code and data. The public TERNOA enclave repository uses Rust and Gramine, alongside Intel’s SGX software. Gramine supports running applications inside an enclave environment.
Remote attestation provides evidence that another party can evaluate before relying on a protected operation. It concerns the platform and the identity of the executing software. The relying party still needs a policy that decides which measurements and platform states it accepts.
The repository also exposes chain-specific configuration and describes peer-to-peer synchronization. This places enclave execution within a larger coordination system. A local computation, a peer exchange and an on-chain authorization decision have different responsibilities, even when they support one user-facing action.
Engineering decisions that matter
Choose a deliberate trusted boundary. Deciding which work belongs inside an enclave is an architectural choice. A focused boundary can make the sensitive operation easier to reason about, while surrounding services handle the rest of the application. Interfaces crossing that boundary need the same attention as the code inside it.
Treat attestation as a decision input. Evidence has value when a verifier knows what to expect. A system needs a way to associate approved software with a measurement and to handle updates without silently accepting an unexpected implementation.
Plan for the operating lifecycle. The public repository calls out platform updates and attestation requirements. Hardware isolation depends on the actual deployed platform, not simply the name of a technology. Maintenance, recovery and the management of accepted software versions belong in the operating model.
Keep network assumptions explicit. Distribution adds coordination. Teams need to know what depends on another node, how unavailable peers affect a workflow and which actions can be retried. Hardware protection and network availability address different failure modes.
From primitives to products
Protected secret handling is one application of confidential computation. Digital legacy is another useful lens: an application may need to retain sensitive information and make it available only under a defined access policy. The user experiences a simple action while the infrastructure enforces several separate responsibilities.
The same architectural questions appear when an AI workflow needs sensitive inputs or tools. What may the computation access? What can another party verify about execution? Which information is allowed to leave the boundary? These are engineering questions that can be explored using confidential computing; they are not claims that every AI task already runs inside TERNOA enclaves.
Current maturity & further reading
TERNOA’s public enclave repository provides implementation and deployment material that engineers can inspect. Its existence demonstrates a concrete software surface; a repository alone does not establish the security or configuration of any particular deployment.
The sources below connect the implementation, the underlying Intel technology and Mickael’s public account of the work. They are a starting point for discussing how confidential computing fits the requirements of a specific system.