The Sentient Secure Enclaves Framework is a Docker-like orchestration platform for AWS Nitro Enclaves providing complete lifecycle management, reproducible builds, and developer-friendly tooling for confidential computing workloads.
The Sentient Secure Enclaves Framework is a production-grade, Docker-inspired orchestration platform for AWS Nitro Enclaves (and potentially other TEEs). It provides a complete end-to-end solution for building, deploying, and managing confidential computing workloads with the same ease-of-use as containerization, but with hardware-backed cryptographic isolation.
The Sentient Secure Enclaves Framework transforms AWS Nitro Enclaves from low-level security primitives into practical, production-ready infrastructure. It provides:
- ✅ Docker-like UX - Familiar CLI and workflow patterns
- ✅ Complete Lifecycle Management - Build, deploy, run, monitor, teardown
- ✅ Reproducible Builds - Deterministic EIF generation with cryptographic verification
- ✅ Multi-threaded Runtime - High-performance async web API for attestation and provisioning
- ✅ Network Abstraction - 6 flexible proxy modes for enclave connectivity
- ✅ Custom Init System - Optimized Rust-based PID 1 for fast boot, in-enclave services and processes management
- ✅ Developer Tools - Shell access, commands execution, file/directory transfer, hot-reload, FS monitoring for changes and any new external data
- 🤖 Confidential AI Inference - Run ML models (and agents!) in hardware-isolated enclaves
- 🔐 Cryptographic Ops and Secret Management - encyrption/decryption/re-encryption, KMS/HSM operations, all in trusted execution environment
- 📊 Privacy-Preserving Analytics - Process sensitive data without exposure
- 🏦 Financial Transactions - Secure payment processing
- 🏥 Healthcare Data - HIPAA-compliant data processing
- Docker Engine equivalent: Future unified Enclave Engine daemon
- Docker CLI equivalent:
pipelineandinitctlcommand-line tools - Dockerfile equivalent: Reproducible build scripts (
rbuilds) - docker-compose.yml equivalent: YAML-based enclave configurations
- Container images equivalent: EIF (Enclave Image Format) images
- PID 1 init equivalent: Custom
init-rsRust implementation
Purpose: Custom PID 1 process for enclave initialization and lifecycle management
Key Features:
- Pure Rust implementation (migration from C/Go predecessors visible in codebase)
- Minimal bootstrap environment - Sets up
/proc,/sys,/dev, cgroups - Vsock heartbeat protocol - Signals enclave readiness to host (port 9000, CID 3)
- NSM driver initialization - Loads Nitro Secure Module for attestation
- chroot environment setup - Switches to
/rootfsfor application execution - Process reaping - Proper zombie process cleanup
- Signal handling - Graceful shutdown and process supervision
Technical Highlights:
// Heartbeat protocol on Vsock CID 3, Port 9000
const VSOCK_PORT: u32 = 9000;
const VSOCK_CID: u32 = 3;
const HEART_BEAT: u8 = 0xB7;Advantages:
- ✅ Security hardened - No systemd bloat, minimal attack surface
- ✅ Fast boot times - Optimized initialization path
- ✅ Predictable behavior - No hidden background services
- ✅ Memory safe - Rust guarantees prevent init crashes
Purpose: Bidirectional Vsock communication bridge for enclave management
Architecture: Client-server model with dual deployment:
- Host-side client: Commands sent to enclave
- In-enclave server: Executes commands in isolated environment
Core Operations:
run- Execute shell commands inside enclave with output capturesend-file- Transfer files from host to enclave (optimized buffer: 7MB, set in compile time, larger buffer depends on kernel setting)recv-file- Transfer files from enclave to hostsend-dir- Transfer nested directories recursively from host to enclave (optimized buffer: 7MB, set in compile time, larger buffer depends on kernel setting)recv-dir- Transfer nested directories recursively from enclave to hostlisten- Server mode for accepting Vsock connections
Protocol Design:
enum CmdId {
RunCmd = 0, // Execute and wait for output
RecvFile, // Receive file from enclave
SendFile, // Send file to enclave
RunCmdNoWait, // Fire-and-forget execution, without running command output waiting (good for residential apps)
SendDir, // Send directory into enclave
RecvDir, // Receive directory from enclave
}Performance Optimizations:
- 7MB file I/O buffer (
BUF_MAX_LEN_FILE_IO: 7340032) - Tuned for throughput, set in compile time, larger buffer depends on kernel setting - Connection retry logic - Up to 10 attempts with exponential backoff
- Progress tracking - Real-time transfer percentage display
- Backlog queue - 128 concurrent connections supported
Advantages:
- ✅ Shell-like experience - Execute commands as if SSH'd into enclave (or as
docker exec) - ✅ File transfer optimization - Large buffer sizes for bulk data
- ✅ Error recovery - Automatic reconnection on transient failures
- ✅ JSON-based output - Structured stdout/stderr/exit code handling
Purpose: Network abstraction layer for enclave connectivity
Proxy Modes (6 distinct implementations):
ip_to_vsock.rs- TCP → Vsock forwarding (host-to-enclave)vsock_to_ip.rs- Vsock → TCP forwarding (enclave-to-host)ip_to_vsock_transparent.rs- Transparent proxy mode (preserves source IP)vsock_to_ip_transparent.rs- Transparent reverse proxytransparent_port_to_vsock.rs- Port-based transparent routingaddr_info.rs- Address resolution and mapping utilities
Use Cases:
- Expose enclave services to external networks (e.g., web server in enclave)
- Connect enclave to databases without direct network access
- Service mesh integration - Route traffic between multiple enclaves
- Load balancing - Distribute requests across enclave instances
Advantages:
- ✅ Zero enclave code changes - Services work as if on normal network
- ✅ Transparent mode - Client IP preservation for logging/auth
- ✅ Bidirectional - Both inbound and outbound connections
- ✅ Multi-protocol - TCP, HTTP, HTTPS, gRPC support
Purpose: High-performance attestation API, for base running image, per file granular attestation, using hashes, wrapped into VRF proofs
Multi-Threaded Runtime Architecture:
Two Runtime Implementations:
mt-runtime.rs- uses Async Std Lib multi-threaded scheduler (manual worker pool)mt-runtime-tokio-tasks.rs- Tokio async runtime for async tasks (green threads), automatic worker pool, mapping async tasks to OS threads
Technology Stack:
- Web Framework: Axum 0.8.4 (high-performance async HTTP)
- Async Runtime: Tokio 1.47.1 (multi-threaded scheduler)
- TLS: OpenSSL 0.10.73 (mTLS support for client auth)
- Serialization: Serde JSON for REST API payloads
| Endpoint | Method | Description |
|---|---|---|
/generate |
POST | Start processing files/directories |
/hash/ |
GET | Get SHA3-512 hash for file |
/proof/ |
GET | Get VRF proof for file |
/doc/ |
GET | Get attestation document |
/pcrs/ |
GET | Get enclave PCR registers |
/verify_hash/ |
POST | Verify file hash |
/verify_proof/ |
POST | Verify VRF proof |
/verify_doc/ |
POST | Verify attestation document signature |
/verify_cert_bundle/ |
POST | Verify certificate chain |
/pubkeys/ |
GET | Get server public keys |
/nsm_desc |
GET | Get NSM device description |
/rng_seq |
GET | Get cryptographic random bytes |
/health, /hello, /echo |
GET | Health check, API testing and metrics |
TOML Configuration:
ra-web-srv/.config/
├── ra_web_srv.config.toml
└── certs/ (certificates, self-signed as an example configuration)
Advantages:
- ✅ High concurrency - 1000s of simultaneous attestation requests
- ✅ Production-ready - Battle-tested Tokio/Axum stack
- ✅ Flexible runtime - Tokio multi-threaded scheduler (work-stealing), mapping async tasks to OS threads
- ✅ Certificate-based auth - OpenSSL, mTLS support for secure API access and for client auth
- ✅ TOML format configuration - TOML-based declarative configuration
Purpose: Development-time hot-reload and change detection
Implementation:
- Notify 7.0 - Cross-platform filesystem event monitoring
- Debouncer (
notify-debouncer-full 0.5.0) - Aggregate rapid changes - SHA3-512 string hashing - Detect actual content changes vs. metadata updates
Hash Module:
fs-monitor/src/hash/
├── hasher.rs // SHA3-512 checksums
├── storage.rs // NATS KV bucket storage support
└── mod.rs // Unified hashing interface
Monitoring Strategy:
- Ignore patterns (
.fsignorefile) - Exclude build artifacts, logs - Recursive watching - Monitor entire directory trees
- Event filtering - Efficient events aggregation, only trigger on meaningful changes
Advantages:
- ✅ Rapid iteration - Instant rebuild on code changes
- ✅ Content-aware - Hash-based deduplication
- ✅ Configurable - Gitignore-style exclusion patterns, with globbing supoort
- ✅ CI/CD integration - Trigger pipelines on specific file changes
Purpose: Deterministic EIF image generation for supply chain security
Build Process:
rbuilds/
├── rbuilds.sh # Main orchestration script
└── eif/*.eif # Generated Enclave Image Format filesReproducibility Features:
- Locked dependencies - Pinned kernel versions, libraries, binaries
- Cryptographic verification - SHA256 checksums throughout build
- Version control integration - Git-tracked build specifications
- Audit trail - Complete provenance from source to EIF
Build Modes:
--init-rs | --init-rust # Include Rust init system
--init-go # Include Go init system (legacy)
--init-c # Include C init system (legacy)
--network # Bundle enclave's network with set of proxies (reverse/forward/transparent)Advantages:
- ✅ Supply chain security - Auditable, reproducible builds
- ✅ Deterministic hashing - Same input → same PCR values
- ✅ Multiple init options - Flexibility for different use cases
- ✅ Pre-packaged tools - Network utilities, debugging tools included
Included Applications:
X_Agent- X/Twitter agent based on AI agent framework for confidential inferenceinference_server- ML model serving in enclavefingerprinting_server- Secure OML injections processing, fingerprinting/watermarking models, AI LLM/SLM models DRM implementationllamacpp_bindings- Llama.cpp integration for LLMsmodel_converter- Convert models to runner (Llamacpp) compatible GGUF format
Purpose:
- Quickstart templates - Copy-paste starting points
- Best practices - Production-ready patterns
- Integration examples - Show how components work together
Advantages:
- ✅ Reduced time-to-production - Working code from day 1
- ✅ Educational - Learn by example
- ✅ Maintained - Integrated with framework recent changes
Unlike other enclave solutions that only provide a runtime:
- Build: Reproducible EIF generation (
rbuilds) - Provision, Deploy: YAML-driven provisioning (
enclave-engine) - Run: Init system + service lifecycle management and restarting policy (
init-rs) - Teardown: Graceful shutdown + cleanup
- Provisioning, Configuration, Debug: Shell access, run commands, file/directory transfer (
pipeline) - Attestation: Web API for enclave and FS attetsation (
ra-web-srv) - Monitor: FS hashing for granular attestation for any changes in run-time ramdisk FS (
fs-monitor) - Update: Rolling updates + version management
Before Sentient Enclaves Framework:
# Traditional enclave development
1. Write low-level C code
2. Manually configure NUMA
3. Debug via serial console logs
4. Rebuild entire image for changes
5. Hope attestation worksWith Sentient Enclaves Framework:
# Modern enclave development
1. Write normal Rust/Go/Python/Ruby/Node/Deno code
2. Write Dockerfile for your app
3. Edit YAML/TOML config files
4. Build, ship and run via `Reproducible Builds` (`rbuilds`) script
5. Interact with enclave via `pipeline` and/or `shell.sh` script for interactive REPL
6. Interact with enclave init system and services via `initctl` init protocol management CLI tool
7. Enclaves servces and processes managment via `enclave-init`
8. Enclaves provisioning via `enclave-engine`
9. Set of `proxies` for network enabled enclaves and confidential apps.
10. `Remote attestation web-server` (`ra-web-srv``) for enclave attestation and FS changes granular attestation
11. External data transferring with `pipeline` and via `proxies`, attest changes in ramdisk FS with `fs-monitor`
12. Attestation handled automatically via `fs-monitor`
13. NATS event bus, KV and object storage for enclaves services integration and event driven architecture for enclaves managment and data/events exchange in a distributed cloud native wayMulti-Threaded Web API:
- 1000+ concurrent requests/sec
- Async I/O throughout
- TLS/mTLS built-in
- Health monitoring
Resource Management:
- NUMA-aware memory allocation
- CPU pinning via GRUB configuration
- Nitro Enclaves allocator service integration
- Dynamic resource scaling
Observability:
- Structured logging (tracing crate)
- Distributed tracing support
- Logs aggregation support
- Error tracking with
anyhow+thiserror - Metrics export (Prometheus-ready)
Hardware Isolation:
- AWS Nitro Enclaves (other TEEs supportable)
- Memory encryption at runtime
- No kernel access from/to enclave
- Vsock-only communication (no network stack by default)
Attestation Integration:
- Remote attestation built-in
- PCR validation
- Certificate-based identity
- KMS integration for secrets
Supply Chain Security:
- Reproducible builds
- Cryptographic verification
- Dependency locking
- Audit trails
Supported Configurations:
- Single enclave on single host
- Multiple enclaves per host
- Fleet management (future)
- Kubernetes integration (future)
Network Topologies:
- Isolated (no network)
- Proxied (via
pf-proxy) - Service mesh (inter-enclave) (future with PRE + BLS based KMS)
- Hybrid (selective exposure)
Based on the architecture, the unified Enclave Engine will provide:
# Similar to dockerd
sudo enclave-engine daemon --config /etc/enclave-engine/config.yaml
# CLI interface (similar to docker CLI)
enclave-ctl ps # List running enclaves
enclave-ctl run my-enclave # Start enclave instance
enclave-ctl logs my-enclave # View logs
enclave-ctl exec my-enclave bash # Interactive shell
enclave-ctl build -f Enclavefile # Build EIF image- Service discovery - Automatic endpoint registration
- Load balancing - Traffic distribution across enclaves
- Auto-scaling - Resource-based instance scaling
- Health checks - Automatic restart on failure
- Rolling updates - Zero-downtime deployments
- Persistent volumes - Data survival across restarts
- Encrypted storage - At-rest encryption
- Snapshots - Point-in-time backups
- Volume plugins - S3, EBS, custom backends
- Virtual networks - Isolated enclave networks
- DNS integration - Name-based service discovery (done, done on UDP level)
- Firewall rules - eBPF-based traffic filtering (done, on netfilter level)
- Service mesh - Istio/Linkerd integration
- File transfer: 7MB buffers, ~2500-5000 MB/s over Vsock on provisioned AWS EBS
- Command execution: <100ms latency for simple commands
- API throughput: 1000+ requests/sec per core
- Concurrent connections: 128 backlog queue
- Memory: Configurable via NUMA (1GB-2048GB)
- CPU: 1-1024 vCPUs (Nitro Enclaves allocator)
- Storage: EIF images (~100MB-1000GB for LLMs)
- Network: Vsock only (no direct network), or
pf-proxyfor TCP port forwarding and transparent traffic proxying
- Enclaves per host: Limited by memory allocation and enclaves per EC2 instance (no limits for KVM/QEMU CVMs)
- Vsock connections: OS-dependent (typically 1000s/thousands)
- File transfer size: No hard limit (chunked transfer)
- API request size: 10MB buffer for JSON payloads
The Sentient Secure Enclaves Framework represents a paradigm shift in confidential computing by bringing the ease-of-use of Docker to the security of hardware enclaves.
- ✨ First Docker-like experience for AWS Nitro Enclaves
- 🔒 Complete lifecycle management (not just runtime)
- ⚡ Production-grade multi-threaded runtime
- 🛡️ Reproducible builds for supply chain security
- 🎯 Developer-friendly abstractions (YAML/TOML configs, CLI tools)
- 🚀 Modern Rust implementation (safety + performance)
- 🌐 Flexible networking (6 proxy modes)
- 📦 Modular architecture (mix and match components)
| Feature | Sentient Framework | AWS Nitro CLI | Azure Confidential Computing | Google Confidential VMs |
|---|---|---|---|---|
| Lifecycle Management | ✅ Complete | |||
| Reproducible Builds | ✅ Yes | ❌ No | ❌ No | ❌ No |
| Multi-threaded Runtime | ✅ Yes | ❌ No | ||
| Docker-like UX | ✅ Yes | ❌ No | ❌ No | ❌ No |
| Network Abstraction | ✅ 6 modes | |||
| Developer Tools | ✅ Extensive | |||
| Open Source | ✅ Apache 2.0 | ✅ Apache 2.0 |
This framework lowers the barrier to confidential computing adoption while maintaining the highest security standards - a rare combination in the TEE ecosystem. It transforms enclaves from esoteric security primitives into practical infrastructure that developers actually want to use.